Open jrapin opened 3 years ago
Do you mean some libraries use numpy.random.seed
and reseed the random number generator?
numpy.random.seed
is a legacy function anyway?inspect.getouterframes
in the numpy.random.seed
function to locate the problem?Do you mean some libraries use
numpy.random.seed
and reseed the random number generator?
- Why not sharing a single random generator in Nevergrad, since
numpy.random.seed
is a legacy function anyway?- How about injecting
inspect.getouterframes
in thenumpy.random.seed
function to locate the problem?
possibly, but that should not have any impact.
I have tracked the code leading to #965. Luckily, not many places use np.random.*
functions.
The key question is which classes should be allowed to create a random_state
? For example,
nevergrad/utils/Transform.py
, should we assign a random_state
?_noisy_call
in nevergrad/functions/functionlib.py
looks problematic. As it calls np.random.normal
for every evaluation. ArtificialVariable.process
in nevergrad/functions/functionlib.py
, the random state is saved and then restored. My observation is it is not allowed in general.To solve the problems, we should set some rules on random_state management. I think that the random_state
management for Parameter
class has been carefully written.
Short answer is ArtificialVariable (and all of ArtificialFunction) predates by far the parametrization system, it's a huge hack to for backward compatibility but we should refactor it one day :s (which is hard given the whole range of options :D)
The key question is which classes should be allowed to create a random_state
That's a hard one. I have no exact answer to this. I tend to prefer that functions use the parametrization's random state, that way experiments share a unique source of randomness. In many cases though, functions take a seed to make them "determinitic" of some sort, with their own random state. It's not required for getting reproducibility, but it does depend on how users want their testbeds to behave, so not sure I should fight against it :s
In any case I prefer that they do not tap into numpy's default random state, so that they remain somehow isolated from outside.
965 fixes tests that have started being flaky recently (Dec 2020) without any related change.
This is probably a dependency update having a wide impact on random states, but not sure.
In 17 December 2020, running this on master was flaky: pytest nevergrad/benchmark/test_xpbase.py::test_noisy_artificial_function_loss --count=100 --exitfirst However this was stable before (never had any failure for months/years on this test. Still, using branches dating back to June 2020, I could see the same error. This is why I expect a dependency update has been at play.
From a recent, seemingly stable build in December:
On a PR where the issue appeared: