t_complexity rotations

[mpharrigan]

CZPowGate and ZPowGate t_complexity and/or _t_complexity_() disagree. ZPowGate is a RotationBloq and uses a formula to return t counts for the bloq, but only when using the Bloq t_complexity method (unknown what happens if you use the cirq t_complexity protocol). CZPowGate returns a rotation=1 count.

This shows up in the test qualtran.bloqs.rotations.phase_gradient_test.test_phase_gradient_state

which seemingly expects everything to be kept as a "rotation".

[mpharrigan]

More info: you'll get a different t complexity depending on whether you use the t_complexity protocol vs using t_complexity method. The protocol will use _is_clifford_or_t to report any 1-qubit gate that isn't a clifford as a rotation even though the ZPowGate t_complexity method returns a number of t gates

[mpharrigan]

I'll turn everything to rotations and add a method to TComplexity if you're interested in converting to total-t

[tanujkhattar]

@mpharrigan The right thing to do here would be to modify the TComplexity dataclass to store rotations as a Tuple[Tuple[Union[float, sympy.Expr], int], ...] which corresponds to storing a tuple of (eps, num_rotations_of_precision_eps) . Or rather have a new data structure that keeps track of these tuples for rotations and provide operators to add / multiply etc.

This might turn into a bigger migration than what the issue is about but I think it's worth doing it now. Doing x rotations is not sufficient information for resource analysis. It's important to know what precision do you wish to perform the x rotations with.

[mpharrigan]

I mean we're going to scrap the TComplexity object entirely in favor of bloq counts so you can actually have some iota of control over these things