Re: Mixing reproducible and non-reproducible code
On Dec 3 2012, John Pryce wrote:
Nick makes valid points about determinism being (un)related to
correctness, etc., but I think he is not quite fair. If a bug is
identified, it is much easier to locate relevant faults if running in
reproducible mode. And it is much easier to prove a block of code
correct, formally or informally, if only one thread is involved. I would
value optional reproducibility, as a debugging aid.
Grrk. I did agree that it helps a great deal with that, but the proposal
was for universal reproducibility, which isn't critical for that and has
two VERY serious downsides:
Demanding cross-system reproducibility is an intolerable burden for
any non-simple function.
Demanding reproducibility across versions prevents any algorithmic
improvements.
But studying PURE in Metcalf & Reid "Fortran 90/95 explained", it seemed
that PURE is intended to prevent a procedure *affecting* the outside
environment during its execution. Whereas we want to prevent a block
*being affected* by the outside environment during its execution. E.g.,
cannot a pure procedure P access COMMON, or module variables, that can be
accessed during its execution by code Q executing in parallel? It seems P
is forbidden to change such variables, but Q could change them and thus
make P's execution non-reproducible? Fortran experts please clarify.
No, that's not allowed. To a good first approximation, PURE does what
you want, though the wording is somewhat scattered.
Regards,
Nick Maclaren.