Use rotation eps in GateCounts

[anurudhp]

fixes #1250

• Maintain a frequency table of epsilons for rotation bloqs.
• Epsilon is converted to a string (the dictionary key) using np.format_float_scientific, with a default precision of 10 digits.
• T-costs:
  • Direct synthesis: 1.149 * log2(1.0 / eps) + 9.2 from https://arxiv.org/abs/1404.5320
  • Beverland et. al. model: passes the number of rotations, ignoring their epsilons.

[mpharrigan]

we had discussed binning by ceil(log(eps)) -- can you comment on that

[anurudhp]

@tanujkhattar's comment:

It's better to store frequency of eps by assuming we can represent float eps as a fraction x / 2^{precision} and store frequencies of x; with precision as a configurable parameter in the constructor of QECGateCount class. It's also fine to store frequency of eps directly for now and make this change as a future improvement. I'd advice against storing frequency of ceil(log2(1/eps)) since it's a very aggressive approximation.

Binning by the above integer approximation can be implemented.

My bigger concern is the various epsilons floating around:

• bloq.eps for rotation bloqs
• error_budget in the surface code costing functions

Should we remove this error_budget and only use bloq.eps? I am not familiar enough with the surface_code implementation to decide if this is correct.

[mpharrigan]

Certain physical cost functions make certain assumptions, and we've tried to implement them as described in the literature. The coupling between the logical costs and the physical cost models is done -- in this case -- via the methods on GateCounts. So, since the beverland physical cost model just counts "rotations" and gives one third of the total error budget to synthesizing them, the get_beverland_counts method should just return the number of rotations in the appropriate field. The gidney-fowler models consume get_total_t_and_ccz_counts, which can use the per-gate epsilon values to turn it into t and ccz counts

[mpharrigan]

should we support "unknown precision" rotations. I guess in the rotation bloqs we have a default eps; but it's not hard to imagine a situation where a researcher has a bunch of rotations and they haven't computed an epsilon for each of them

[anurudhp]

I'm using error_budget / rotations here

[anurudhp]

@mpharrigan ptal!

[mpharrigan]

taking a look now. Can you update the original PR description with a summary of changes in this pr

[mpharrigan]

some comments and questions, but I think this is generally the correct approach

[mpharrigan]

please update the docstring with a thorough description of the representation of rotations.

Is it possible for someone to construct this class with inconsistent binned values vs the eps_bin_prec? What if someone puts in the epsilons as floats instead of 2**20*floats

document that the eps_bin_prec behavior during addition.

eps_bin_prec -> epsilon_precision? and then document that precision is measured by number of binary digits.

[anurudhp]

Used np.format_scientific_float to avoid such issues.

[mpharrigan]

What if you're adding one carefully-crafted rotation-containing GateCounts with a low eps_precision to a GateCounts that doesn't contain any rotations (it's just e.g. Ts and Toffolis) so it has the default eps_precision of 20

[anurudhp]

Used np.format_scientific_float to avoid such issues.

[anurudhp]

The code snippet I was trying to use (which works with this PR):

import sympy
from qualtran.bloqs.basic_gates import ZPowGate
from qualtran.resource_counting import get_cost_value, QECGatesCost

t, eps = sympy.symbols(r"t \epsilon")
bloq = ZPowGate(exponent=t, eps=eps)
costs = get_cost_value(bloq, QECGatesCost())
costs.total_t_count()

[mpharrigan]

I don't think this representation is particularly intuitive, so it needs solid documentation

[mpharrigan]

this still desperately needs a description of the data contained within the GateCounts dataclass in the class docstring.

[mpharrigan]

so how does it work when adding or multiplying when there are values that differ only in precision

[anurudhp]

the __mul__ is to multiply with some int other, right? which just multilpies the frequencies, not affecting the epsilons.

For add, it just combines the two counters together, and equal keys will get merged. (handled by Counter.__add__). The precision of representing epsilon is only used when converting it to a string key in from_rotation_with_eps, but not stored in the GateCounts object itself.

[mpharrigan]

why unique=False?

[anurudhp]

This was to ensure that the representation was more stable. from the docs:

... If precision is given fewer digits than necessary can be printed. ...

[anurudhp]

Actually, I'm not sure what the best way is to check if two rotation frequency tables are the same, as the epsilons could have been stored with different precisions, or be approximate.

[mpharrigan]

Thinking more about this, I think we'll need a special data container for the binned rotations that enforces the invariants we want to enforce. It's too dangerous to have our public data member be a dictionary whose keys are supposed to be strings crafted in a very particular way. (There's a secondary issue that a dictionary is mutable and therefore not compatible with the frozen GateCounts class)