Re: Mixing reproducible and non-reproducible code
On 2012-12-06 16:08:05 -0500, Ian McIntosh wrote:
> If we allow non-IEEE 754-2008 implementations, then exact reproducibility
> is impractical.
But an implementation could contain the necessary information to
allow anyone to write a new implementation with the same behavior,
as long as the user doesn't write code that depends on
implementation-defined / unspecified / undefined behavior. This
has other advantages: the user could write accuracy-related proofs
concerning the implementation (the "accurate" accuracy mode could
be sufficient for that, though). In short, this means:
* make all operations fully implementation-defined;
* specify the bindings allowing one to use these operations.
> Even implementations fully conforming to IEEE 754-2008 cannot always
> produce identical results.
Of course, but the user could still write code that doesn't depend
on implementation-defined behavior (things about the NaN payload,
alternate exception handling, etc.).
> One example I've read about is how one handles numbers very close to zero.
> 754 doesn't specify exactly when rounding takes place, because different
> architectures implement it differently. If the result is between zero and
> the smallest nonzero positive number, some implementations make it zero
> before rounding, while others round first and depending on the exact value
> and the rounding mode may make it zero or may make it the smallest nonzero
> positive number.
I don't think this is correct. What you say is true concerning whether
an underflow exception is generated or not, but AFAIK, IEEE 754
requires the results to be correctly rounded, even in the subnormal
range. In particular, §7.5 says: "The method for detecting tininess
does not affect the rounded result delivered". Of course, there may
be a difference under an alternate exception handling (§8), but this
is *not* the default behavior.
I now see 4 levels of reproducibility (with the usual constraints,
like not using ID/unspecified behavior out of the scope of P1788):
0. No reproducibility guaranteed.
1. Reproducibility after translation (= compilation), e.g. once
the user has compiled his program, the results will always be
reproducible. What a translation is is implementation-defined.
2. Reproducibility by documentation by the implementation (see
above).
3. Reproducibility by specification by the standard (like IEEE 754).
This may be considered for 754-compatible implementations.
The bindings are affected by reproducibility levels 0, 1 and 2 (for
instance, how a parallel sum reduction is bound to the P1788 addition
of two intervals, and how expressions are evaluated).
Using implementation-defined or undefined behavior must not be
necessary to use P1788 except for a translation or initialization step
(e.g. in case of a library, due to a #include to use the library).
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)