Initialize DefaultQubit2 local rng from global rng if no seed provided

[albi3ro]

Previously, users made workflows repeatable by specifying a global seed via np.random.seed. Now that DefaultQubit2 has a local random number generator, it is not influenced by the global seed. This is a breaking change in behaviour.

We want each device to be using a local rng so other calls to the global rng will not affect device samples, and so the device can be seeded on initialization. We don't want to change the use of a local rng.

But, we can still make the local rng coupled to any seed set globally. We can simply seed the rng from the global state if no seed is provided.

>>> tape = qml.tape.QuantumScript([qml.Hadamard(0)], [qml.sample(wires=0)], shots=5)
>>> np.random.seed(42)
>>> DefaultQubit2().execute(tape)
array([ True,  True, False, False,  True])
>>> np.random.seed(42)
>>> DefaultQubit2().execute(tape)
array([ True,  True, False, False,  True])
>>> np.random.seed(42)
>>> DefaultQubit2(seed=1234).execute(tape)
array([ True, False,  True, False, False])

Alternative option:

Add an additional option for seed that will allow us to distinguish between:

1. seed rng with None
2. seed rng from np.random.randint

Maybe a default value of "global_rng_seed" or something like that different from None.

[frederikwilde]

I'd vote for the alternative option you propose. I think obtaining a seed from the global NumPy random state is something one should be very careful about, and in general probably try to avoid. Using a dedicated value like "global_rng_seed" or "global_numpy_seed" will ensure that no user will make this choice accidentally.

[timmysilv]

maybe I'm playing devil's advocate a bit, but would users care? I would guess that 9 times out of 10, receiving seed=None means the user didn't set it because they don't care what the seed is. In which case, the global state seems fine. If you think this introduces some other danger, then I'm fine with adding a different default from None. But again, I think it will just work like None would.

I made a similar call in my recent change to drawing stuff, which is like the proposed global_numpy_seed value, except that the default is still None. Here, this allows users to say "keep using the global numpy seed" if it's important to them, but otherwise just use some default seed like we are doing today. I'd rather the inverse (a custom option like "no_global_seed") so the default (None) uses the global seed (because again, it would usually be fine), but allow a user to ask not to use the global seed if it causes problems for them.

[frederikwilde]

@timmysilv I agree that 9 times out of 10 when the user goes with the default (seed=None) they won't encounter any problems if the random state is derived from the global NumPy random state. The way I see this becoming a problem at the 10th time, is that the user sets the global NumPy random state somewhere else in their code and then is surprised later on that the global seed they set for a different part of their computation affects the outcomes of the circuit simulations. Or even worse, they don't notice it and publish data with unintended correlations.

Obviously this would be a user mistake to begin with, since they should specify a seed and also not use the global random state. And the alternative (seed=None using OS entropy) is also far from ideal, since it makes everything non-reproducible, but at least it won't introduce unintended correlations.

[codecov]

Codecov Report

Merging #4394 (8fa7648) into master (f186064) will increase coverage by 0.00%.
Report is 1 commits behind head on master.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           master    #4394    +/-   ##
========================================
  Coverage   99.76%   99.76%            
========================================
  Files         351      351            
  Lines       32535    32661   +126     
========================================
+ Hits        32458    32584   +126     
  Misses         77       77            

Files Changed	Coverage Δ
pennylane/devices/experimental/default_qubit_2.py	100.00% <100.00%> (ø)
pennylane/devices/qubit/__init__.py	100.00% <100.00%> (ø)
pennylane/devices/qubit/adjoint_jacobian.py	100.00% <100.00%> (ø)
pennylane/devices/qubit/simulate.py	100.00% <100.00%> (ø)
pennylane/qnode.py	100.00% <100.00%> (ø)

[timmysilv]

I'm not sure how much I'm worried about that. From where I stand, the RNG seed is a nice thing to have for reproducibility, but is otherwise unimportant. It's not like a physical quantum computer has np.random.seed. Your results won't be "wrong" because you used a seed you didn't mean to use, but they might be harder to share/reproduce exactly. Anyway, I'm not sure where this leaves us

[frederikwilde]

I agree. But isn't this even more of an argument for making seed=None lead to "true" randomness? What I am most concerned about is people having unintended correlations in their numerical simulations, since this can be tricky to detect sometimes.

[frederikwilde]

Looks great to me! 💯