Re: Mixing reproducible and non-reproducible code

[Ian McIntosh <ianm@xxxxxxxxxx>]

I would like all implementations to have a mode in which they provide as much reproducibility as possible. I would also like reasonable efficiency. In some cases, where the dragons live, those conflict.

If we allow non-IEEE 754-2008 implementations, then exact reproducibility is impractical. Even implementations fully conforming to IEEE 754-2008 cannot always produce identical results.

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.

To guarantee exact reproducibility, 1788 would have to specify which of the two 754 options must be followed, and those who don't follow it would have to check after every arithmetic operation whether they need to correct the answer. You may not care if a lower bound becomes such a tiny amount lower or if an upper bound becomes slightly higher, but if it's the other way around it might be more important. In any case it is impractical for all 754 systems to be fully reproducible for these values.

This is separate from systems with a "flush subnormals to zero" approach or option, which is not 754-compliant.


I wouldn't support requiring "exact reproducibility" because in some cases it's impractical.

I would support requiring languages and implementations to be able to (ie, either always or under an option or pragma or mode) provide as much reproducibility as the underlying floating point system (hardware + microcode + software) is capable of. I would even allow result variance caused by different kinds of intervals (eg Kaucher or not) or by different representations (lower and upper bounds versus mean and radius).

I don't object to optional modes that are either more precise or faster or both (or even slower and less precise), as long as there is a way of getting "essentially reproducible" results. That might include writing the code in a particular way, suppressing all optimizations and using special options and it needn't be the default, but should be available to claim compliance. Of course one could implement an almost-1788 IA or non-1788 IA, just as some implement almost-754 FP or non-754 FP.

Some languages do specify partial reproducibility; eg, Fortran requires evaluating partial expressions inside parentheses before combining them with what's outside - A+(B+C) must be evaluated as B+C before adding A, and C has a pragma to control whether expressions can be combined. These or similar approaches plus avoiding optimization should support 1788 "essentially reproducible" execution.

- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development


"N.M. Maclaren" ---12/06/2012 10:00:59 AM---On Dec 6 2012, Vincent Lefevre wrote: I started to respond to each point, but don't think that it wo

From:	"N.M. Maclaren" <nmm1@xxxxxxxxx>
To:	Ian McIntosh/Toronto/IBM@IBMCA
Date:	12/06/2012 10:00 AM
Subject:	Re: Mixing reproducible and non-reproducible code

---

On Dec 6 2012, Vincent Lefevre wrote:

I started to respond to each point, but don't think that it would help,
so I am responding just to the fundamental confusion.

>> We are clearly at cross-purposes.

We are still clearly at cross-purposes.  The situation is that 1788 (and,
in particular, this section) has the following properties:

    a) 1788 imposes constraints on the language definition - it does
not and cannot impose constraints on implementations
    b) The language definition imposes constraints on implementations
    c) The implementations impose constraints on programs

In all cases, reproducibility MUST be optional, in the following sense:

    a) 1788 must not require the language to have a reproducible mode,
though it may require a specific set of reproducible operations, specified
as some sort of library procedures

    b) The language must not be required to require implementations to
support a reproducibility mode, even if it specifies one - if it chooses
to do so, that is OK

    c) The program must not be required to use reproducibility, even if
the implementation supports it

>> If you want reproducibility as an option that consenting languages
>> can specify, fine.  Only Java and a few others will adopt it.
>
>If a language standard doesn't have anything about reproducibility,
>it isn't major a problem. Implementations can still provide
>reproducibility as an option.

They cannot provide it across implementations, and my point was and is
that P1788 talks about reproducibility in absolute terms.

Providing it for a single version of a single compiler on a single
platform is one thing.  Beyond that, there be dragons.

>> Making it mandatory as an option is a sure way of getting 1788 rejected
>> or grossly abused by most of the important ones.
>
>I wonder what you mean by "mandatory as an option". There should be
>nothing mandatory for the implementer and for the user.

Requiring language standards to specify it as something an implementor
may choose to support.  That is a complete non-no.  Many language
standards will not want anything to do with it, except perhaps as a
set of library procedures for a small range of near-trivial operations
(say, up to an including the trigonometric functions).

>But reproducibility can be specified as an option, and if an
>implementation claims to support it (e.g. via a special mode),
>then it shall not lie. That's all.

If, by "can be", you mean "may be, at the choice of the language
definition", then I agree.  Otherwise, I strongly disagree.


Regards,
Nick Maclaren.