Re: Mixing reproducible and non-reproducible code
On Dec 2 2012, Dan Zuras Intervals wrote:
From: Michel Hack <mhack@xxxxxxx>
There may be more at stake than representation issues. Reproducible mode
may affect global properties, such as forcing single-threaded execution.
So what do we expect to happen when modes are mixed?
(1) The interface module could force single-threaded execution while the
reproducible-mode component is running. Is that generally feasible?
(2) The reproducibility properties of the reproducible-mode component
could be voided, as basic assumptions of that mode don't pertain.
Gug. Oops. Yes, that needs resolving. I can see how it would be
handled in practice, but specifying it is trickier. Essentially, as
I am sure you were thinking, the two codes would be compiled separately.
Perhaps I'm missing something here.
Just what IS "non-reproducible code"?
And why are we considering it?
Much less defining it?
And, CAN one define it?
Just curious... :-)
Yes, easily. The wording may not be perfect, but look at 1.8:
... The unit of mapping and transformation can be individual
operations and built-in functions, expressions, statements,
complete procedures, or other. ...
Specifically, if the data before and after the unit of
transformation is regarded as a set of mathematical intervals, the
transformed form of all combinations of the elements (the real
values) represented by the prior set shall be a member of the
posterior set.
Actually, I now notice that should say "ARE regarded as SETS". Mea
culpa! John - could you take that on board? Thanks.
The point is that one can require the interval constraints to be met,
while leaving the tightness of an interval to be a QoI detail - and,
yes, it might vary between executions of the same code on identical
data! It still means that you can rely on the result being truthful
(if possibly unhelpful).
Regards,
Nick Maclaren.