Skip to content

Missing an Adaptive Profile notion of results with static, non-measurement values #65

Description

@swernli

Problem

In the Adaptive Profile, there is no way to represent a result identier that should start or be set to a constant/static value outside of measurement. While some providers or tooling treat results that have never been measured into as false/zero by default, it does not appear to be explicitly specified in the spec, and there is nothing that would allow representing a result that defaults to true/one. This can be problematic when the higher level language includes patterns like initializing a result array to default values or even having a single result that is only conditionally measured into and starts with a default one value.

As an example, consider the following Q# code:

operation Main() : Result {
    use q = Qubit();
    H(q);
    mutable r = One;
    if MResetZ(q) == One {
        r = MResetX(q);
    }
    r
}

The final value of r may be the result id corresponding to the second measurement or the constant One depending on the behavior of the first measurement. Currently there is no way to compile this code into QIR because of the missing support for constant result values.

Proposed fix

One approach to fixing this could be introducing a new QIR runtime function in the Adaptive Profile:

void @__quantum__rt__write_result(i1, ptr)

This would be a parallel to i1 @__quantum__rt__read_result(ptr) that writes the provided Boolean constant value into the result register with the given identifier. This would overwrite any existing value at that id, such that later calls to read or record the result would see the written value. This would allow patterns like initializing result identifiers to specific values before measurement or use of specific, compiler chosen result ids to represent the true/one and false/zero values throughout the program when they are needed for intializing allocated variables that hold result identifiers. For runtimes, this could have the potential benefit of differentiating between an uninitialized result value (which could trigger an error or a wait) and a value that should be treated as static/classical for control flow purposes.

@idavis @bettinaheim @billti

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions