Fix #45: Parameterized measurement patterns #158

thierry-martinez · 2024-05-30T09:35:00Z

This commit is yet another tentative to implement parameterized measurement patterns, to fulfill issue #45 (previous tentative: #68).

This commit adds two methods to the class Pattern:

is_parameterized() returns True if there is at least one measurement angle that is not just an instance of numbers.Number: indeed, a parameterized pattern is a pattern where at least one measurement angle is an expression that is not a number, typically an instance of sympy.Expr (but we don't force to choose sympy here).
subs(variable, substitute) returns a copy of the pattern where occurrences of the given variable in measurement angles are substituted by the given value. Substitution is performed by calling the method subs on measurement angles, if the method exists, which is the case in particular for sympy.Expr. If the substitution returns a number, this number is coerced to float, to get numbers that implement the full number protocol (in particular, sympy numbers don't implement cos).

codecov · 2024-05-30T09:39:24Z

Codecov Report

Attention: Patch coverage is 81.87050% with 126 lines in your changes missing coverage. Please review.

Project coverage is 72.95%. Comparing base (ec4c582) to head (5feac05).
Report is 5 commits behind head on master.

Files	Patch %	Lines
graphix/parameter.py	80.54%	122 Missing ⚠️
graphix/transpiler.py	80.95%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #158      +/-   ##
==========================================
+ Coverage   71.82%   72.95%   +1.13%     
==========================================
  Files          30       31       +1     
  Lines        5359     6038     +679     
==========================================
+ Hits         3849     4405     +556     
- Misses       1510     1633     +123

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

shinich1 · 2024-05-31T06:40:22Z

@thierry-martinez great, is the intention to merge @pafloxy's #68-equivalent code first (when it's ready), before merging this?

thierry-martinez · 2024-05-31T15:21:28Z

@thierry-martinez great, is the intention to merge @pafloxy's #68-equivalent code first (when it's ready), before merging this?

I adapted #68 code for Parameter class in the commit 81bbeb7 I just pushed. #68 was incorrect because arithmetic operators changed parameters in place (computing alpha + 1 did change the value of alpha to alpha + 1!). In this PR, we distinguish between Parameter (alpha) and ParameterExpression (alpha + 1), and a Parameter is a particular case of ParameterExpression.

The test test_parameter_simulation is illustrative: we can either substitute a parameter by a value in a pattern then simulate, or simulate symbolically (given that the pattern is deterministic!) then substitute in the (symbolic) state vector or the density matrix, and we get the same result.

pafloxy

I think as for now this is all that I was looking for, If @shinich1 thinks its alright maybe we should go for the merge. :)

shinich1 · 2024-06-01T09:45:34Z

@thierry-martinez @pafloxy great! give us a few days to look through. A few quick comments:

is TN backend working with parameters, or should we throw error in TN backend if pattern is parametrised?
~~2. could you add sympy to requirements.txt?~~
will circuit.simulate_statevector, pattern.perform_pauli_measurements, as well as visualization tool, work with parameters?

EarlMilktea · 2024-06-01T14:42:44Z

Let me review it later.

Anyway, is it absolutely necessary to use sympy?
I'm concerned with...

performance: Personally I feel sympy is far from performant.
type stability: sympy has no type annotations, and it seems that not even planned.
developer experience: Sometimes sympy makes linter (ex. flake8, Ruff) extremely slow.

Additionally, let me point out that @masa10-f is planning to completely eliminate sympy from the source.

EarlMilktea · 2024-06-01T14:48:25Z

If sympy is absolutely necessary, it's OK, but we may need to verify that we're using it wisely.

EarlMilktea · 2024-06-03T05:23:01Z

graphix/parameter.py

+    expected by the simulator back-ends.
+    """
+
+    def __init__(self, expression: sp.Expr):


Please do not omit -> None.

EarlMilktea · 2024-06-03T05:24:10Z

graphix/parameter.py

+    def __repr__(self) -> str:
+        return str(self._expression)
+
+    def subs(self, variable, value) -> ParameterExpression | numbers.Number:


Please use complex instead of abstract numbers.Number .

Numbers from numpy (or sympy...) are not necessarily instances of complex, for instance:

isinstance(np.array([1])[0], complex) == False isinstance(np.array([1])[0], numbers.Number) == True isinstance(sp.parse_expr(1), complex) == False isinstance(sp.parse_expr(1), numbers.Number) == True

So do you mean this block can sometimes return non-complex value?

if isinstance(result, numbers.Number): return complex(result)

If you're sure that complex(result) is always complex type, please use ParameterExpression | complex.

I personally believe that return type annotation should be as concrete as possible, or we need extra type narrowings.

Oops, sorry, I answered without thinking enough: you are right, and after the coercion, the result is complex indeed.

EarlMilktea · 2024-06-03T05:24:32Z

graphix/parameter.py

+        assert np.allclose(sv.psi, sv2.subs(alpha, 0.5).psi)
+    """
+
+    def __init__(self, name):


Add -> None .

EarlMilktea · 2024-06-03T05:25:00Z

graphix/parameter.py

+        name : str
+            name of the parameter, used for binding values.
+        """
+        assert isinstance(name, str)


Please do not use assert if you're planning to expose this class.

EarlMilktea · 2024-06-03T05:25:14Z

graphix/parameter.py

+        super().__init__(sp.Symbol(name=name))
+
+    @property
+    def name(self):


Please explicitly specify the return type.

EarlMilktea · 2024-06-03T05:26:14Z

graphix/sim/base_backend.py

        op_mat = op_mat_from_result(vec, result)
    state.evolve_single(op_mat, qubit)
    return result


 class Backend:
-    def __init__(self, pr_calc: bool = True):
+    def __init__(self, pr_calc: bool = True, rng: np.random.Generator = None):


Please use np.random.Generator | None.

EarlMilktea · 2024-06-03T05:26:47Z

graphix/sim/density_matrix.py


 class DensityMatrixBackend(graphix.sim.base_backend.Backend):
    """MBQC simulator with density matrix method."""

-    def __init__(self, pattern, max_qubit_num=12, pr_calc=True):
+    def __init__(self, pattern, max_qubit_num=12, pr_calc=True, rng: np.random.Generator = None):


Use | None .

pafloxy · 2024-06-06T09:08:30Z

@thierry-martinez @pafloxy great! give us a few days to look through. A few quick comments:

is TN backend working with parameters, or should we throw error in TN backend if pattern is parametrised?
~~2. could you add sympy to requirements.txt?~~

will circuit.simulate_statevector, pattern.perform_pauli_measurements, as well as visualization tool, work with parameters?

@shinich1 @thierry-martinez
Maybe you guys figured it already but I think we need to make some small modification to the visualization.py module as well. There are some checks to determine if a measurement angle is Pauli in some of the class methods for GraphVisualizer of the form

elif (
                show_pauli_measurement
                and self.meas_angles is not None
                and (
                    2 * self.meas_angles[node] == int(2 * self.meas_angles[node])
                )  # measurement angle is integer or half-integer
            ):

where we might need to add another line or so to exclude the case where the measurement angles is an instance of Parameter/ParameterExpression.

shinich1 · 2024-06-11T17:48:07Z

Hi @pafloxy @thierry-martinez

I think the best way is to move parameter implementation with sympy out of main graphix repository, for example a separate repo (wrapper/module) dedicated to parameterized patterns and their executions (it seems possible, given the relatively small changes required to implement?). I am happy to initiate a creation of such repository in teamgraphix organization, if that makes sense to you? for example, that can be part of extra pip installation.

The reason mostly follows @EarlMilktea 's. Sustaining maintainability is going to help a lot in the long run for everyone contributing to this repo and will help a lot those maintaining.

sympy has quite a performance issue. Looking at their github repo, it seems like a recurring issue in qiskit (which has sympy incorporated) and quite a bit of effort can be saved by deciding to move it out at this point (nb as @EarlMilktea mentioned sympy will be removed from requirements.txt when gflow is refactored for performance soon.)
typing, linter compatibility, as in @EarlMilktea's comment

thierry-martinez · 2024-06-12T13:10:35Z

I propose in my last commits a version which does not require mypy.

The module parameter.py implements symbolic expressions so as to support parameters, but without all the symbolic. machinery of mypy (computations with known values are done numerically, not symbolically).
The rest of the code does not depend on parameter.py: in particular, the code for simulators is generic. If we still need the sympy version of parameters, we can implement it separately, and simulators should work without any specific modification in the code of graphix.
Tests for parameters are done in a specific test_parameter.py module, and the tests include circuit simulation.

shinich1 · 2024-06-20T03:11:11Z

I propose in my last commits a version which does not require mypy.

The module parameter.py implements symbolic expressions so as to support parameters, but without all the symbolic. machinery of mypy (computations with known values are done numerically, not symbolically).

The rest of the code does not depend on parameter.py: in particular, the code for simulators is generic. If we still need the sympy version of parameters, we can implement it separately, and simulators should work without any specific modification in the code of graphix.

Tests for parameters are done in a specific test_parameter.py module, and the tests include circuit simulation.

Thank you! I believe you mean sympy instead of mypy above? Let me take a detailed look at the code soon.

shinich1 · 2024-06-23T07:57:14Z

@thierry-martinez the implementation looks good to me! we need to:

fix visualization which seems to throw error in the presence of parameter in pattern
test more situations, so we can catch more errors (currently rz only with no arithmetic of param covered?)
do we intend to cover simulations without subs? if so we should throw error if parameterized and being simulated?
update QAOA, VQE and QNN examples.
add appropriate page to docs (just autodoc, not much to write - see existing pages)
device interface - may need care. easy solution is to ask subs before PatternRunner initialization.

EarlMilktea · 2024-06-24T07:08:31Z

graphix/parameter.py

+        else:
+            return NotImplemented
+
+    def __rsub__(self, other) -> Expression | complex | type(NotImplemented):


Duplicated.

EarlMilktea · 2024-06-24T07:09:47Z

graphix/parameter.py

+class Expression:
+    """Expression with parameters."""
+
+    def __mul__(self, other) -> Expression | complex | type(NotImplemented):


Please do not specify NotImplemented type, as this value itself is never returned from __mul__.

It's just a marker for internals.

EarlMilktea · 2024-06-24T07:10:22Z

graphix/parameter.py

+class Expression:
+    """Expression with parameters."""
+
+    def __mul__(self, other) -> Expression | complex | type(NotImplemented):


Please annotate other.

EarlMilktea · 2024-06-24T07:13:19Z

graphix/parameter.py

+    def subs(self, variable: Parameter, value: Expression | numbers.Number) -> Expression | complex:
+        if self == variable:
+            if isinstance(value, numbers.Number):
+                return complex(value)


Type checker complains that Number cannot be converted to complex. Could you check it?

EarlMilktea · 2024-06-24T07:15:37Z

graphix/parameter.py

+    def type(self) -> type:
+        return self.__type
+
+    def subs(self, variable: Parameter, value: Expression | numbers.Number) -> Expression | complex:


I once here that numbers.XXX does not work efficiently with modern typing systems (see Fluent Python 2nd ed.).

Do you come up with alternatives to that?

EarlMilktea · 2024-06-24T07:17:02Z

graphix/parameter.py

+
+
+class Compound(Expression):
+    def __init__(self, children: typing.Iterable[Expression | complex]) -> None:


typing is not imported at all.

Please import from collections.abc.

EarlMilktea · 2024-06-24T07:20:33Z

graphix/parameter.py

+        return simplify_product(simpl)
+
+    def is_float(self) -> bool:
+        return lhs.is_float() and rhs.is_float()


lhs undefined.

EarlMilktea · 2024-06-24T07:21:26Z

graphix/parameter.py

+        terms[expr] = terms.get(expr, 0) + coef
+
+
+def syntactic_order_key(key: Expression | complex | None) -> Any:


Please import typing. Additionally, please do not use Any if possible as it ruins type annotations.

EarlMilktea · 2024-06-24T07:27:28Z

I'm a little bit concerned about...

complexity: Is it possible to maintain parameter.py ? It's already really huge.
performance: I feel that current impl. cannot be faster than sympy as it's doing almost the same things.

shinich1 · 2024-07-03T16:39:34Z

We suggest the following:

implement 'placeholder' parameter implementation in graphix
move symbolic stuff outside, in https://github.com/TeamGraphix/graphix-symbolic/tree/master.

This commit implements TeamGraphix#158 (comment) Sympy plugin is implemented in https://github.com/thierry-martinez/graphix-symbolic/tree/sympy

thierry-martinez · 2024-07-10T08:59:41Z

As @shinich1 suggested in the above message, this PR now only provides abstract base classes for parameters, and a minimal concrete class for placeholders (symbolic angles that can solely be substituted, and that cannot appear in computation). The sympy part is implemented as a plugin in the graphix-symbolic repo: TeamGraphix/graphix-symbolic#1 .

This commit implements TeamGraphix#158 (comment) Sympy plugin is implemented in https://github.com/thierry-martinez/graphix-symbolic/tree/sympy

graphix/parameter.py

tests/test_parameter.py

This commit is yet another tentative to implement parameterized measurement patterns, to fulfill issue TeamGraphix#45 (previous tentative: TeamGraphix#68). This commit adds two methods to the class `Pattern`: - `is_parameterized()` returns True if there is at least one measurement angle that is not just an instance of numbers.Number: indeed, a parameterized pattern is a pattern where at least one measurement angle is an expression that is not a number, typically an instance of `sympy.Expr` (but we don't force to choose sympy here). - `subs(variable, substitute)` returns a copy of the pattern where occurrences of the given variable in measurement angles are substituted by the given value. Substitution is performed by calling the method `subs` on measurement angles, if the method exists, which is the case in particular for `sympy.Expr`. If the substitution returns a number, this number is coerced to `float`, to get numbers that implement the full number protocol (in particular, sympy numbers don't implement `cos`).

`parameter.py` is inspired by TeamGraphix#68 but is split in Parameter and ParameterExpression.

shinich1 · 2024-08-20T13:16:40Z

@thierry-martinez the implementation looks good to me! we need to:

fix visualization which seems to throw error in the presence of parameter in pattern

test more situations, so we can catch more errors (currently rz only with no arithmetic of param covered?)

do we intend to cover simulations without subs? if so we should throw error if parameterized and being simulated?

update QAOA, VQE and QNN examples.

add appropriate page to docs (just autodoc, not much to write - see existing pages)

device interface - may need care. easy solution is to ask subs before PatternRunner initialization.

bump above list posted some time ago

Shinichi's comment: TeamGraphix#158 (comment)

thierry-martinez · 2024-08-20T21:57:15Z

Thank you, @shinich1, for the list!

fix visualization which seems to throw error in the presence of parameter in pattern

Fixed in 34c16ed, with a dedicated test.

test more situations, so we can catch more errors (currently rz only with no arithmetic of param covered?)

Should have been fixed with test on random circuits (05c05a0).

do we intend to cover simulations without subs? if so we should throw error if parameterized and being simulated?

Simulations without subs are handled with graphix-symbolic. In 3a6e38d, I added a test to check that there is an exception PlaceholderOperationError if a simulation is run on a circuit with a non-substituted Placeholder.

update QAOA, VQE and QNN examples.

I am not sure what to do with QAOA since there is only one pattern in qaoa.py.
I added a placeholder version in VQE (with performance comparison) in 4cb326b.
I added placeholders for QNN in b337abe.

add appropriate page to docs (just autodoc, not much to write - see existing pages)

Placeholders and affine expressions are documented in 149b089.

device interface - may need care. easy solution is to ask subs before PatternRunner initialization.

I added a test to check that there is an exception CircuitError if a PatternRunner is initialized on non-substituted parameterized patterns in 1e2f3c1.

EarlMilktea · 2024-08-21T15:06:19Z

@thierry-martinez

Is it impossible to move symbolic-related ABCs/subs functions to graphix-symbolic ?
Additionally, please do not define unnecessary mathematical/arithmetic abstract methods in AffineExpression, as they're not implemented or even used in graphix: consider extending it in the separate package.
I understand graphix should be updated so that non-float can pass through functions, but the impact should be minimal.

thierry-martinez · 2024-08-23T00:12:42Z

@EarlMilktea I believe that all the functions (subs, xreplace, and the trigonometric functions) are used in graphix. Simple and parallel substitutions apply to both Placeholder and AffineExpression. All trigonometric functions are potentially called during simulation; in these cases, AffineExpression raises an Exception, as expected, since simulation is not supported. The purpose of the parameter module is to define a common interface, which is why an abstract base class is defined.

EarlMilktea · 2024-08-23T01:04:59Z

@thierry-martinez
OK, I trust you.
Let me do final checks...

examples/MBQCvqe.py

Suggested by EarlMilktea: TeamGraphix#158 (comment)

thierry-martinez · 2024-08-23T16:19:05Z

I added missing xreplace in Circuit, Statevec and DensityMatrix, and I replace some uses of numbers.Number with typing.SupportsComplex.

EarlMilktea · 2024-08-23T18:31:52Z

I re-reviewed you code and felt that the whole logic of graphix (inclding simulator) is affected.
Could you request reviews from @masa10-f , as I'm not sure your idea is compatible with ZX calculus?
Additionally, please wait until his changes are merged and update your code accordingly.
Meantime, let me carefully examine your code in terms of type stability, performance, and maintainability.

EarlMilktea

WIP: May be updated later.

EarlMilktea · 2024-08-23T18:46:39Z

graphix/instruction.py

@@ -59,7 +60,9 @@ class RotationInstruction(OneQubitInstruction):
    Rotation instruction base class model.
    """

-    angle: float
+    model_config = ConfigDict(arbitrary_types_allowed=True)


This is introducing an "escape-hatch" to BaseModel.
If this is really necessary, let's remove validation itself completely.

Setting arbitrary_types_allowed=True does not eliminate validation. For types that do not implement their own validation (such as Expression in this case), the validation defaults to using isinstance, which is appropriate. Previously, I implemented validation in Expression specifically using isinstance (as discussed here: #158 (comment)). Both approaches are equivalent: we can either specify the use of isinstance for validation within the Expression implementation, or we can specify it when using Expression within the model.

I see. Sorry for my misunderstanding...
By the way, why BaseModel is introduced here in the first place?

graphix/parameter.py

EarlMilktea · 2024-08-23T18:57:04Z

graphix/parameter.py

+    """Expression with parameters."""
+
+    @abstractmethod
+    def __mul__(self, other) -> ExpressionOrFloat: ...


Please do not omit annotations as I'm planning to enable Ruff rule ANN (enforce type annotation) for easier code reviews.
(Any would be acceptable here though)

Fixed in b720e48.

Ah sorry, I made you confused.
My true implication here is that, Any with @abstractmethod is acceptable (as we cannot call them at all and the concrete argument types can be overridden), but as usual, not allowed for implementation.

Memo: mypy check results for this file:

graphix/parameter.py:185: error: Argument 1 to "float" has incompatible type "Expression | SupportsFloat"; expected "str | Buffer | SupportsFloat | SupportsIndex" [arg-type] graphix/parameter.py:282: error: Argument 2 to "subs" of "Expression" has incompatible type "Expression | SupportsFloat"; expected "Expression | float" [arg-type] graphix/parameter.py:285: error: Incompatible return value type (got "Expression", expected "T | complex") [return-value] graphix/parameter.py:302: error: Argument 1 to "xreplace" of "Expression" has incompatible type "Mapping[Parameter, Expression | SupportsFloat]"; expected "Mapping[Parameter, Expression | float]" [arg-type] graphix/parameter.py:305: error: Incompatible return value type (got "Expression", expected "T | complex") [return-value]

graphix/parameter.py

EarlMilktea · 2024-08-23T19:02:18Z

graphix/sim/base_backend.py

+        op_mat = np.eye(2, dtype=np.complex128) / 2
+    else:
+        # At least one value is symbolic (i.e., parameterized).
+        op_mat = np.eye(2, dtype="O") / 2


dtype="O" needs extra care as it can impact the performance of simulators.

We know that symbolic simulations are extra-costly!

Then I suggest completely isolating the logic to different functions: numpy is notorious for unpredictable automatic type conversion, so I don't want it close to numerical simulator that should be as lightweight as possible.
Current approach (e.g., add conditional branches to existing functions) is very vulnerable to accidental contamination.

Suggested by EarlMilktea: TeamGraphix#158 (comment)

This partially reverts commit 9f97fda.

thierry-martinez force-pushed the parameterized branch 2 times, most recently from 3093bdd to a5e16de Compare May 30, 2024 09:38

pafloxy approved these changes Jun 1, 2024

View reviewed changes

shinich1 requested a review from EarlMilktea June 1, 2024 09:45

EarlMilktea requested changes Jun 3, 2024

View reviewed changes

EarlMilktea requested changes Jun 24, 2024

View reviewed changes

thierry-martinez mentioned this pull request Jul 10, 2024

Symbolic computation with sympy TeamGraphix/graphix-symbolic#1

Open

thierry-martinez force-pushed the parameterized branch from b74c594 to 784dd34 Compare July 10, 2024 13:20

shinich1 reviewed Jul 22, 2024

View reviewed changes

graphix/parameter.py Outdated Show resolved Hide resolved

shinich1 reviewed Jul 22, 2024

View reviewed changes

tests/test_parameter.py Outdated Show resolved Hide resolved

thierry-martinez added 4 commits July 25, 2024 22:52

Add parameter class and support for symbolic simulations

aa6d11a

`parameter.py` is inspired by TeamGraphix#68 but is split in Parameter and ParameterExpression.

Use the same seed for both simulations

1d34455

Add missing type annotations

ecc102a

thierry-martinez added 8 commits August 20, 2024 16:26

Use SupportsFloat instead of Number in pattern.py

8bbe950

Fix visualization in the presence of parameter in pattern

34c16ed

Shinichi's comment: TeamGraphix#158 (comment)

Test exception on simulation with placeholders

3a6e38d

Add xreplace for parallel substitution

55ff7f5

Update VQE example

4cb326b

Update QNN example

b337abe

Update documentation and changelog

149b089

Test device interface

1e2f3c1

EarlMilktea assigned thierry-martinez Aug 22, 2024

EarlMilktea requested changes Aug 23, 2024

View reviewed changes

examples/MBQCvqe.py Outdated Show resolved Hide resolved

thierry-martinez added 4 commits August 23, 2024 11:45

Merge remote-tracking branch 'origin/master' into parameterized

3ad2de7

Rename MBQCVQEWithPlaceholders (PEP8-compliance)

8e9fb19

Suggested by EarlMilktea: TeamGraphix#158 (comment)

Add some tests for xreplace

a7378ed

Better typing and xreplace for Circuit, Statevec and DensityMatrix

f200a28

EarlMilktea requested a review from masa10-f August 23, 2024 18:39

EarlMilktea requested changes Aug 23, 2024

View reviewed changes

thierry-martinez added 6 commits August 23, 2024 22:41

Remove references to graphix-symbolic

d9dcef5

Suggested by EarlMilktea: TeamGraphix#158 (comment)

Replace (:=) is not None by = followed by is not None

7189dba

Suggested by EarlMilktea: TeamGraphix#158 (comment)

Add type annotation Any

b720e48

Suggested by EarlMilktea: TeamGraphix#158 (comment)

Do not use getattr

d554a7c

Suggested by EarlMilktea: TeamGraphix#158 (comment)

Remove pow, rpow, tan, arcsin, arccos, arctan and log

9f97fda

Suggested by EarlMilktea: TeamGraphix#158 (comment)

Restore sin and cos in Placeholder

09a965c

This partially reverts commit 9f97fda.

thierry-martinez mentioned this pull request Aug 24, 2024

[WIP] Refactor new features #201

Closed



		class Compound(Expression):
		def __init__(self, children: typing.Iterable[Expression \| complex]) -> None:

		terms[expr] = terms.get(expr, 0) + coef


		def syntactic_order_key(key: Expression \| complex \| None) -> Any:

Fix #45: Parameterized measurement patterns #158

Are you sure you want to change the base?

Fix #45: Parameterized measurement patterns #158

Conversation

thierry-martinez commented May 30, 2024

codecov bot commented May 30, 2024 • edited Loading

Codecov Report

shinich1 commented May 31, 2024

thierry-martinez commented May 31, 2024

pafloxy left a comment

Choose a reason for hiding this comment

shinich1 commented Jun 1, 2024 • edited Loading

EarlMilktea commented Jun 1, 2024

EarlMilktea commented Jun 1, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

EarlMilktea Jun 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pafloxy commented Jun 6, 2024

shinich1 commented Jun 11, 2024

thierry-martinez commented Jun 12, 2024

shinich1 commented Jun 20, 2024 • edited Loading

shinich1 commented Jun 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

EarlMilktea commented Jun 24, 2024

shinich1 commented Jul 3, 2024

thierry-martinez commented Jul 10, 2024

shinich1 commented Aug 20, 2024 • edited Loading

thierry-martinez commented Aug 20, 2024

EarlMilktea commented Aug 21, 2024

thierry-martinez commented Aug 23, 2024

EarlMilktea commented Aug 23, 2024

thierry-martinez commented Aug 23, 2024

EarlMilktea commented Aug 23, 2024 • edited Loading

EarlMilktea left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

EarlMilktea Aug 24, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov bot commented May 30, 2024 •

edited

Loading

shinich1 commented Jun 1, 2024 •

edited

Loading

EarlMilktea Jun 3, 2024 •

edited

Loading

shinich1 commented Jun 20, 2024 •

edited

Loading

shinich1 commented Jun 23, 2024 •

edited

Loading

shinich1 commented Aug 20, 2024 •

edited

Loading

EarlMilktea commented Aug 23, 2024 •

edited

Loading

EarlMilktea Aug 24, 2024 •

edited

Loading