feat: result appending post-processing

[ss2165]

To enable e.g. all the elements of an array to be collated in to the same bitstrings, see tests

Flattens lists so can be used once entire arrays can be printed too.

So some guppy that looks like for a given shot:

vals = (1, 0, 1, 0)
for v in vals:
    result("c", v)

results in post-processed output, over 100 shots

Counter({(("c", 1010"),): 100})

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.83%. Comparing base (647ad3d) to head (54c2582).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #713      +/-   ##
==========================================
+ Coverage   92.81%   92.83%   +0.01%     
==========================================
  Files          71       71              
  Lines        8159     8178      +19     
==========================================
+ Hits         7573     7592      +19     
  Misses        586      586              

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

[cqc-alec]

In this counter, are we losing information about the correlation between different tags across shots?

[ss2165]

yes, but it is still preserved in the full results object. The conversion to pytket preserves it for example.

[cqc-alec]

I see. I think those correlations would be important in most cases. No harm in offering this format, but I think we should also offer a counter-like result format that doesn't lose any information except for the shot ordering. I guess this would have to be something like Counter({(("c", "111"), ("d", "10")): 1, ...})?

[ss2165]

yeah maybe that makes more sense as a default

[cqc-alec]

Hmm, although even that format isn't sufficient to capture the order of results within a shot (e.g. whether the "d" came between the first and second "c" or not), representing different control-flow paths. For that, we may need a format like Counter({("c", 1), ("c", 1), ("d", 1), ("c", 1), ("d", 0)) : 1, ...}).

[ss2165]

that's too noisy to be useful in this context I think

[cqc-alec]

We may need to offer several different "views" into results to serve different use cases.

[ss2165]

yep, we already have register_counts for serving the traditional "classical register" style use, this RFC is effectively view number 2

[cqc-alec]

Sounds good to me.

[ss2165]

representing different control-flow paths

I think Counter(shots.results) where shots is an instance of HShots already gets you this

[tatiana-s]

Looks good to me