Re: pitfalls of verifying floating-point computations

[Nick Maclaren <nmm1@xxxxxxxxxxxxx>]

Michel Hack (1-914-784-7648) <hack@xxxxxxxxxxxxxx> wrote:
> (Well, there is always probabilistic tie-breaking, which I believe is
> Nick Maclaren's favourite usually-unavailable feature, but in that case,
> who can tell?  It won't be reproducible anyway.  Perhaps the distribution
> of rounding errors would be affected, but probably not measurably.)

Right.  The only reason that I claim it is superior is that it makes
the unpredictability an "in your face" feature, and so naive people
won't be fooled.  I should hate to have to support it in any current
mainstream language :-)  But it WOULD make a fantastically useful
validation feature.

I do stand up for it when people claim that nearest rounding is
uniformly the most accurate, but I would never claim that it is more
accurate than nearest rounding overall.

With all respect to the authors of that paper (who are very good),
they are completely deluded in this respect.  Even if we ignore all
of the double rounding, association and similar issues, there is a
fundamental, mathematically unavoidable problem that any program
that involves true asynchronicity (including BOTH serial real-time
programs with unserialised event streams and parallel code) will
NECESSARILY produce non-reproducible floating-point results.

And most large, important programs involve one or the other!


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1@xxxxxxxxx
Tel.:  +44 1223 334761    Fax:  +44 1223 334679