You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 the RepeatableRandom seed provided in the crate and supplied to the Environment 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 to random(), 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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: