RE: Mixing reproducible and non-reproducible code
Thanks for clarifying. I think this needs to be explicitly explained in the standard:
* that we allow results to be different from one computations to another as long as they enclose the corresponding interval, and
* that we allow the possibility of a _reproducible mode_, when the results are uniquely determined by the inputs
Reproducibility is a typical problem in parallel computations, maybe we can borrow some words from their standards?
________________________________________
From: stds-1788@xxxxxxxx [stds-1788@xxxxxxxx] On Behalf Of N.M. Maclaren [nmm1@xxxxxxxxx]
Sent: Sunday, December 02, 2012 4:55 AM
To: stds-1788@xxxxxxxxxxxxxxxxx
Subject: 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.