[BUG] Operations in has_unitary_generator do not really have unitary generators

[dwierichs]

Expected behavior

The name of an object in qml.ops.qubit.attributes can be understood easily without causing confusion and uses standard terminology.

Actual behavior

The attribute has_unitary_generator is confusing and does not adhere to the standard notion of "unitary" in physics/math.
It contains the following two sets of operations:

• RX, RY, RZ, MultiRZ, PauliRot, IsingXX, IsingYY, IsingZZ, SingleExcitationMinus, SingleExcitationPlus, DoubleExcitationMinus, DoubleExcitationPlus, PauliRot. These operations have a generator $G$ that satisfies the equation $(-2G) (-2G^\dagger)=4GG^\dagger=\mathbb{I}$, i.e. the generator is unitary up to a prefactor $2$ (or some other complex number with magnitude $2$, that's not noticeable). For this group of operations it is somewhat sensible to call them unitarily generated.
• IsingXY, SingleExcitation, DoubleExcitation, OrbitalRotation, FermionicSWAP do not satisfy the above equation. Indeed, all these operations have a generator that has the eigenvalue $0$, a rather non-unitary property.

Additional information

The cause of this mismatch likely is in the discrepancy between the naming of the attribute collection and its use case in the codebase. However, the docstring is very clear about considering PhaseShift as non-unitarily generated operation because of the $0$ eigenvalue of its generator, which means that the second set of operations mentioned above definitely should not be in there, or both the docstring and the naming need to be changed.

has_unitary_generator is used in the following two places:

• qml.transforms.expand_nonunitary_gen, which in turn is only used by metric_tensor with the kwarg allow_nonunitary=False . However, the criterion by which metric_tensor should decompose in its preprocessing is the question of whether qml.transforms.metric_tensor._get_gen_op has a hard-coded support for the respective operation. This means that the flawed registration of non-unitarily generated operations affects metric_tensor with allow_nonunitary=False but the logic anyways is flawed for this decomposition. Removing operations of the second group above from has_unitary_generator will actually unlock the metric tensor with allow_unitary=False
• qml.ops.op_math.exp, where unitarity does not play a significant role, but we likely should rather be using something along the lines of an attribute has_generator_types.

Source code

No response

Tracebacks

No response

System information

pl dev

Existing GitHub issues

• I have searched existing GitHub issues to make sure the issue does not already exist.

[trbromley]

This bug should be fixed by carrying out the following changes:

• Update has_unitary_generator in qml.ops.qubit.attributes to exclude operations whose generator is not a unitary, i.e., IsingXY, SingleExcitation, DoubleExcitation, OrbitalRotation, FermionicSWAP (second set of operations mentioned above)
• Fix the usage in qml.ops.op_math.exp. We should instead iterate over all operations and filter out those which do not have a generator, e.g., by doing something like for op_name in qml.ops.qubit.__all__, using op = getattr(qml.ops.qubit, op_name) and postselecting on op.has_generator.

[ejthomas]

Hi, I'd like to work on this issue please 🙂

[trbromley]

Hi @ejthomas! That's awesome, you can check out our development guide or just post here if you have any questions. Good luck!

[ejthomas]

Hi all, I've opened a PR for this fix here (#4183). Interested to hear your thoughts - I hope I've understood correctly what was intended but happy to make any changes needed. Thanks!

[ejthomas]

Hi, thanks for assigning me on this issue. I noticed that the issue has been reopened - is there anything else I need to do? It seems that to be counted on UnitaryHack before today's deadline the issue needs to be closed.

[trbromley]

Hi @ejthomas! Congrats on getting this merged and thank you for being a contributor to PennyLane! 🚀

As part of our 0.31 release, we're planning to promote UnitaryHack contributions to PennyLane on social media. This is completely optional, but would you like to be mentioned in our social media posts? Specifically, we'd need either your Twitter profile, your LinkedIn profile, or your name.

[ejthomas]

Thanks! That's great, I'm totally happy to be mentioned - my LinkedIn is https://www.linkedin.com/in/edward-thomas-902b17a4 (Edward Thomas)