Add seeded execution to the Catalyst runtime

[paul0403]

Context:
The test test_dynamic_one_shot_several_mcms in frontend/test/pytest/test_mid_circuit_measurement.py was marked as skipped because it was flaky: #842

After some investigation, it was found out that the test involves a measurement, which gives random results. The qjit run of the test is random, but the reference default.qubit run is seeded, so sometimes the results fall outside the acceptable range of np.allclose.

To resolve this, we add a seeding mechanism for qjit.

Description of the Change:
Implemented a random seeding infrastructure for qjit.

The top-level qjit decorator can now take in a string argument seed="some_string". The default value is empty string, which means an unseeded run.

The string will be propagated to the runtime ExecutionContext, which then initializes a PRNG (the c++ std::mt19937 pseudo random number generator) in the context.
The seed and the PRNG is then sent to individual devices.
When performing measurements, the devices draw according to this PRNG.

A proper seed is found and set, to deterministically resolve the flaky test test_dynamic_one_shot_several_mcms.

Benefits:

• test_dynamic_one_shot_several_mcms now reliably passes
• User can seed a qjit run

Possible Drawbacks:

Related GitHub Issues: closes #839

[sc-66696]

[codecov]

Codecov Report

Attention: Patch coverage is 98.11321% with 2 lines in your changes missing coverage. Please review.

Project coverage is 97.90%. Comparing base (897630c) to head (276761e).

Files	Patch %	Lines
runtime/include/QuantumDevice.hpp	0.00%	1 Missing ⚠️
runtime/lib/capi/ExecutionContext.hpp	75.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #936   +/-   ##
=======================================
  Coverage   97.90%   97.90%           
=======================================
  Files          72       73    +1     
  Lines       10341    10371   +30     
  Branches     1180     1185    +5     
=======================================
+ Hits        10124    10154   +30     
- Misses        171      172    +1     
+ Partials       46       45    -1     

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

[paul0403]

Confirming that this is what we want (using "draw" as a name for the internal "random state" in lightning simulator runtime) when we set a seed:

• Each execution of a qjit-compiled function should not return the same results, as the user would expect repeated executions of things like catalyst.measure to be random
• However, when a seed is set, the evolution history of repeated executions of a qjit-compiled function should stay the same.

i.e.

# in file test.py

dev = qml.device("lightning.qubit", wires=1, shots=None)
@qjit(seed="qwerty")
@qml.qnode(dev)
def circuit():
    qml.Hadamard(0)
    m = measure(0)
    @cond(m)
    def cfun0():
        qml.Hadamard(0)
    cfun0()
    return qml.probs()

print(circuit(), circuit(), circuit(), circuit())

If we run python test.py, the 4 executions should give "random" results from each other; however, running python test.py again should produce the same 4 results:

$ python3 test.py
[0.5 0.5] [0.5 0.5] [1. 0.] [0.5 0.5]
draw is 0.73658 draw is 0.797645 draw is 0.267068 draw is 0.793337 
$ python3 test.py
[0.5 0.5] [0.5 0.5] [1. 0.] [0.5 0.5]
draw is 0.73658 draw is 0.797645 draw is 0.267068 draw is 0.793337

The above is exact (shots=None). If we use a high number of shots (e,g, shots=10000) the probabilities will have small fluctuations:

$ python3 flaky_mcm.py
[0.5013 0.4987] [1. 0.] [1. 0.] [1. 0.]
draw is 0.838864 draw is 0.289431 draw is 0.405051 draw is 0.0953809 

$ python3 flaky_mcm.py
[0.5021 0.4979] [1. 0.] [1. 0.] [1. 0.]
draw is 0.838864 draw is 0.289431 draw is 0.405051 draw is 0.0953809

$ python3 flaky_mcm.py
[0.5019 0.4981] [1. 0.] [1. 0.] [1. 0.]
draw is 0.838864 draw is 0.289431 draw is 0.405051 draw is 0.0953809

$ python3 flaky_mcm.py
[0.4899 0.5101] [1. 0.] [1. 0.] [1. 0.]
draw is 0.838864 draw is 0.289431 draw is 0.405051 draw is 0.0953809

@dime10 @mudit2812

[dime10]

@paul0403 No, I would say each execution of the qjit function should produce the same results, since it is seeded.

However, if you were to invoke the same QNode multiple times within a single execution of the qjit function, they should produce different results.

[paul0403]

@dime10 Ah, so

dev = qml.device("lightning.qubit", wires=1, shots=None)

@qjit(seed="qwerty")
def workflow():
    @qml.qnode(dev)
    def circuit():
        qml.Hadamard(0)
        m = measure(0)
        @cond(m)
        def cfun0():
            qml.Hadamard(0)
        cfun0()
        return qml.probs()

    return circuit(), circuit(), circuit(), circuit()

print(workflow())
print("#######")
print(workflow())

(Array([0.4975, 0.5025], dtype=float64), Array([1., 0.], dtype=float64), Array([1., 0.], dtype=float64), Array([1., 0.], dtype=float64))
#######
(Array([0.4975, 0.5025], dtype=float64), Array([1., 0.], dtype=float64), Array([1., 0.], dtype=float64), Array([1., 0.], dtype=float64))

i.e. the history of both workflow (which is the QJIT) calls are the same, but within each QJIT call the qnode results are different?

[dime10]

@dime10 Ah, so the history of both workflow (which is the QJIT) calls are the same, but within each QJIT call the qnode results are different?

Exactly :)

[mudit2812]

@dime10 @paul0403 When we talked yesterday the behaviour I had in mind was more consistent with the first implementation. This is really more of a product question though.

[paul0403]

@dime10 @paul0403 When we talked yesterday the behaviour I had in mind was more consistent with the first implementation. This is really more of a product question though.

@josh146

[dime10]

@dime10 @paul0403 When we talked yesterday the behaviour I had in mind was more consistent with the first implementation. This is really more of a product question though.

That would be harder to realize because there is no persistent state in the runtime across qjit invocations. (and also unnecessary imo)

[paul0403]

TODO: add frontend tests for seeded qjit; changelog done

[paul0403]

Question: right now only measurements are seeded. Should sampling (aka shots) be seeded as well?

[dime10]

Nice work @paul0403 !

I think there a few simplifications we can make, and the other question is whether we want to make the other update in the lightning device to use the same randomness for sampling (have you looked at whether this can easily be done?).

[paul0403]

@erick-xanadu @dime10 Thanks for the suggestions! Yes, the root of the complexity is C not allowing overloading.

If we are fine with changing the signature to __catalyst__rt__initilize(char *) everywhere (and modifying all the necessary tests to reflect this), then this is by far the cleanest approach imo. The complex blocks in the conversion pass also become unnecessary.

I have done this in the most recent commit (without going over the tests right now).

[dime10]

Thanks @paul0403 :)