search

QuTech-Delft / OpenQL

OpenQL: A Portable Quantum Programming Framework for Quantum Accelerators. https://dl.acm.org/doi/10.1145/3474222
https://openql.readthedocs.io
Other
101 stars 45 forks source link

Revise measure instruction wrt location of (optional) result #441

Open jvansomeren opened 2 years ago

jvansomeren commented 2 years ago

Many things are 'wrong' with the way "measure" is currently defined. First of all, the implicit result bit, which was in the original language spec, also see https://libqasm.readthedocs.io/en/latest/cq1-instructions.html#default-instruction-set. On the one hand it does not properly allow assigning to some explicit bit (one would like to be able to write b[23] = measure(q[0]), on the other hand it does not allow qubits (that are part of the qubit register) to be measured without storing the bit result. Then there is the assumption that a measurement produces binary data, and not e.g. 1 of 3 possibilities. And then we have calibration, where measurements are performed that produce (e.g.) raw IQ values.

Related are the available qubit operand access modes, used in de-graph construction, specifically "M", which states: M for a measurement of the qubit for which the result is written to its implicitly associated bit register (DDG W for the qubit and its bit, liveness use for the qubit, and liveness kill for the bit). Equivalent access modes that allow explicit specifications for a qubit and a bit separately do not seem to exist

The implicit association of measured qubit and classical result bit is also a problem from the retargetability point of view. Requiring implementing this for each target is wrong. Ok, there is some backward compatibility here and also cQASM compatibility stuff. But those latter can be get rid off. Let us take a step back here and investigate without taking care of those backward and cQASM compatibility issues.

wvlothuizen commented 2 years ago

For some context, see https://github.com/QuTech-Delft/OpenQL/pull/433