🚀 go-pugleaf

In article <45022fc8.0310021010.4aaf0e5e@posting.google.com>,
Iain McClatchie <iain-3@truecircuits.com> wrote:
>
>Nick> Apparently it [true probabilistic rounding] is starting to be
>Nick> adopted in graphics.
>
>Whoa!
>
>The graphics guys at SGI soured on MADDs when they found out
>that fused multiply-add instructions round differently than two
>separate operations.  It turns out that you have to calculate the
>exact same screen position twice for a vertex which is part of two
>different triangles.  The bug they found was that the vertex went
>down two different code paths, and the two paths rounded
>differently, in this case because one path used multiply and then
>add, and the other used a fused multiply-add.
>
>Graphics guys are really into repeatability.  They'll get their
>performance by chucking precision or accuracy first.

If they code like that, they will also be sacrificing performance!

The first point is that you don't get repeatability in combination
with significant optimisation - even without that problem.  The
second one is, when calculating a vertex's coordinates and consistency
is critical, do it once and save it.  This can be essential for things
like Dirichlet tesselation, which are seriously numerically unstable.

I was actually referring to the use in dithering, which is somewhere
that true probabilistic rounding is much superior to any deterministic
rounding.

What is probably the case is that anyone who relies on absolutely
consistent floating-point results is living dangerously, and may be
deluding himself.  I know of at least half a dozen ways where the
assumption will fail, even on consistent IEEE-like architectures.
And considerably more on older ones.

That is part of the basis for my assertion that probabilistic rounding
is good because it forces programmers to realise that floating-point 
arithmetic does not give precisely predictable results.


Regards,
Nick Maclaren.