Fix #181 and #188: Better pauli nodes recognition

[thierry-martinez]

This commit introduces a new method is_pauli on M commands, which returns a pair (axis, sign) if the measure is Pauli, and None otherwise.

This method takes an optional parameter precision ($\rho$, default: 1e-6): a measure is considered to be Pauli if the angle is in an interval $[- \rho + k \cdot \frac \pi 2; \rho + k \cdot \frac \pi 2]$, addressing the precision problem raised in #181.

axis is computed by using the cos and sin definitions of pauli.py, solving the inconsistency bug reported in #188.

This commit introduces a new Sign class to make code manipulating Plus and Minus to be more readable than when using bool.

[EarlMilktea]

@thierry-martinez

@shinich1 is now planning to provide a new class or enum variant for Pauli measurements.

[thierry-martinez]

This PR uses tuple[Axis, Sign] as the type for Pauli measurements. I am open to declaring a dataclass instead of a tuple if preferred, but I believe that any choice will be isomorphic to this tuple type. If the plan is to have a dedicated Command subclass for Pauli measurements (either a child class or a sister class of M), I think the approach of this PR—having a general M class and a partial coercion method is_pauli—is the right choice. I don't see any good way to prevent the M class from being instantiated with Pauli angles, so the Command class level does not seem to be the right place to distinguish between general and Pauli measurements.

[EarlMilktea]

@thierry-martinez

I see. I'm almost agree with your approach, but have some opinions for the API.

• The name is_pauli is not good: we can only say that it is close to Pauli.
• If you still want to use the name is_pauli, we should not make precision optional.
• Implicit casting to Pauli should be strictly banned.

[EarlMilktea]

I don't see any good way to prevent the M class from being instantiated with Pauli angles

So do I, but at the same time I don't want it to be treated as special Pauli measurements unless explicitly specified by users.

[thierry-martinez]

is_close_to_pauli is a better name indeed, and I just committed a change to use math.isclose, which is preferable to reinventing the wheel for comparing floats! I use now a proper class Pauli rather than a mere tuple.

So do I, but at the same time I don't want it to be treated as special Pauli measurements unless explicitly specified by users.

I am not sure about this. It seems quite natural to write pattern.add(M(..., angle=angle)) in a code, where angle is a variable which can be Pauli or not (for instance, a parameter), and to expect Pauli preprocessing to handle this measurement if angle is (close to) Pauli.

I tend to think that if we have computations where we should not consider equal pairs of values that satisfy math.isclose, then these computations are ill-conditioned and we are going to have troubles anyway.

[EarlMilktea]

expect Pauli preprocessing to handle this measurement if angle is (close to) Pauli

I feel this approach is a bit confusing. For example, Pauli flow requires measurement angles to be exactly equal to $0$, $\pi / 2$, $\pi$, or $3\pi / 2$. It would be better to require users to cast to dedicated classes/variants explicitly when infinite precision is required, or only do it when angle is given as Fracion.

[thierry-martinez]

I feel this approach is a bit confusing. For example, Pauli flow requires measurement angles to be exactly equal to 0 , π / 2 , π , or 3 π / 2 . It would be better to require users to cast to dedicated classes/variants explicitly when infinite precision is required, or only do it when angle is given as Fracion.

There is no Fraction equal to π / 2! ;-) In numerical simulations, it’s often unavoidable to rely on comparisons with a tolerance of ±ε due to the limitations of floating-point arithmetic. This approach is not unique to Pauli flow but is a general necessity whenever exact matches to theoretical results in the complex field aren’t feasible: Graphix simulation back-ends do that all the time!

[EarlMilktea]

There is no Fraction equal to π / 2!

We're now excluding $\pi$ from the angles, aren't we?

simulation back-ends do that all the time

Then we should gradually fix it...

Anyway, as long as conversion to Pauli is explicit, this PR looks good to me.

[thierry-martinez]

We're now excluding π from the angles, aren't we?

You're correct, but since Pauli angles have exact float representations (e.g., $0.5 = 2^{-1}$), we could argue that it's safe to use == for comparisons with 0, 0.5, 1, and 1.5. Would you prefer to revert to using float equality in this case?

[EarlMilktea]

How about discussing later, together with the angle convention mentioned in #191 ?

[thierry-martinez]

I propose closing this PR to continue the discussion on #181. I will open a new PR specifically for #188.