Open rbilgil opened 8 months ago
Yes, thread scheduling could be one of explanations: insertion evaluation process is sensible to result comparison order, if results are the same, it will pick the one passed as "right" to comparison operator.
However, I wouldn't ignore possibility of the bugs. My way to tackle such problems would be to disable parallelism and check whether output is deterministic. If not, dive deeper into app state during multiple executions and compare it.
Hello! We're using the
vrp_core
crate directly in our codebase to solve VRP problems and are very interested in deterministic output. Our expectation is that theRepeatableRandom
seed provided in the crate and supplied to theEnvironment
should mean subsequent runs when run on the same input should result in exactly the same solution. However, in practice we haven't been able to achieve this: the solution never appears to be repeatable between runs.Wondering if either our expectations of what
RepeatableRandom
does is wrong, or whether we're encountering a bug. From examining some of the calls torandom()
, we did suspect that thread scheduling could be adding its own entropy to the RNG access, but not completely sure if that could explain the problem.