feat!: add measure_leaked and bool/uint future results

[jake-arkinstall]

This reflects a change to the helios QIS, as well as the interface to the runtime and error model interfaces.

Code changes

measure_leaked should produce a future value that can be fetched as a u64, rather than as a bool that we currently have in place.

I was torn between keeping read_result as deprecated, as now encoding the type in the name is more appropriate. I have decided against that, that we do not provide API stability guarantees yet, and keeping it around might be confusing, so I have discarded the old interface.

This does, however, include a bump to the error model and runtime API versions, so old versions should be detected and rejected rather than causing UB.

Implementation

• The user program calls ___measure_leaked.
• This is defined on the helios selene interface as a call to selene_qubit_lazy_measure_leaked.
• This increments the measure_leaked_request_count metric in the user_program category
• It is sent to the runtime using a measure_leaked call.
• The runtime provides a future reference as a u64, just as with measure.
• When it is ready to flush, the runtime provides MeasureLeaked instructions in a Batch.
• This increments the measure_leaked_batch_count and measure_leaked_individual_count metrics appropriately.
• MeasureLeaked is then provided to the error model.
• In the Selene methodology, the error model should be responsible for tracking leakage, this PR does not make any changes to the Simulator interface.
• In example code, futures are internally stored as u64s, and converted when the user requests a bool or u64 result.
  • Requesting an incompatible future is implementation-specific behaviour, but in our example code any u64 is simply cast to a boolean via a > 0 comparison, and from a boolean by a if bool { 1 } else { 0 } expression.

Wait to merge

Depends on:

• feat: add qsystem op for measure leaked guppylang#1057
• adding tests to verify that the behaviour is as required.

[narmlu]

Should we use the naming LazyMeasurement instead of future here and everywhere below, to stay consistent with tket2 & eldarion?

[jake-arkinstall]

I decided to move away from tying futures specifically to measurements in case we have other uses of futures, as the abstraction seems general enough for it.

In the Helios sense I think measurements are a good description, but Selene is aiming for a more general concept of devices/runtimes so I want to make it applicable for a wider range.

An example may be an extension to guppy/tket/etc that targets some other ecosystem and expects a runtime that can provide the current timestamp. This would be a u64 future (presumably one that flushes everything such that the timestamp corresponds to the same point in the guppy code), and could directly use the existing future type in a meaningful way.

[narmlu]

Ah yes, Selene is supposed to try to be "platform agnostic" to some extent that's right.

[narmlu]

In guppy/tket2, measure_leaked actually returns a future value. Shouldn't we specify FutureResult here too?

(also apologies / thanks for your patience in advance -- much of my review is probably going to be me just asking clarifying questions)

[jake-arkinstall]

This is over the FFI boundary, so the underlying is a u64 value that provides a reference to an ID to poll. I should indeed add a u64Future type, typedef'd to a u64, to make this clearer.

[narmlu]

This looks mostly fine to me. How tightly are you trying to tie the interface to the guppy semantics? I only ask because guppy measure_leaked returns a MaybeLeaked object (just a wrapper around the integer value). Actually, as I write this I realize it may not even be relevant. That is only at the guppy level. Everything below that just deals with the FutureResult (or Result), which is what this PR is doing if I'm understanding.

Just left a few sporadic questions and small nits about .into() instead of if bool {1} else {0} (I may have overlooked a few).

[akhil-quantum]

If Selene is supposed to be hardware agnostic, is there a reason we are specifying MeasureLeaked as its own operation? especially if we are not modeling leakage? A more abstract alternative could be to have MeasureBool and MeasureUint if we care about return type.

I thought leakage heralding measurement was something specific to trapped ion computers that use a sympathetic coolant?

[jake-arkinstall]

I was apprehensive about adding this for the exact reason you have given. If it were kept internal I might have been able to justify adding measure_leaked through a plugin, or broken the measurement API to provide it with appropriate tweaks.

However, that gets very involved, and would require inelegant workarounds for the missing u64 future handling. It feels as this is now a standard feature of QIS that I've decided to live with it and maybe reconsider when Selene needs to make a break (e.g. expanding the gateset to beyond rxy, rzz, rz)