Dennis Clarke <dcl### [at] blastwaveorg> wrote:
> I have a strict belief that code like POV-Ray could perform the exact same
> sort of test if we exclude all noise components and random signal
> components. I was thinking ( brace yourself ) of a sphere hangng over a
> checkerboard with no anti-aliasing and nothing that would create expected
> differences in output data.

  It's not even a question of randomness or noise. (In fact, if POV-Ray
uses the its own randomness algorithm, its result will be the same in all
systems.)

  The problem with floating point numbers is that it depends a lot on how
they are calculated whether two different systems will give identical
results.
  For instance, Intel CPUs (and compatibles) use actually 10 bytes long
floating point numbers internally even though the program stores them
as 8 bytes long in memory. Some operations might, just might give a
different result due to the increased accuracy. Some other processors
might use 8 bytes long floating point numbers internally, others might
use even 16 bytes long ones.
  Some numbers (such as 0.1) cannot be represented accurately with
(binary) floating point and the error grows if such inaccurate numbers
are calculated together (for instance, if you sum 0.1 with itself ten
times you will find out that the result is not *exactly* 1.0 but there's
a difference in the least significant bits of the result).

  Also compiler optimizations may affect the accuracy of the computations.
For example, a compiler might take this code:

r1 = a/x; r2 = b/x; r3 = c/x; r4 = d/x;

and optimize it (at least if allowed) into an equivalent of this:

tmp = 1/x; r1 = a*tmp; r2 = b*tmp; r3 = c*tmp; r4 = d*tmp;

  Now, "a/x" often gives a different result than "a*(1/x)" due to how
floating point calculations work. (Technically speaking, the "1/x"
calculation loses information which is not lost when the final result is
calculated with a direct "a/x".)
  There are many other places where the compiler might use shortcuts in
order to create faster code.

  All these differences are in the very least significant bits of the
result. Whether this minuscule difference will end up as a differing
pixel in the resulting image depends a lot on what is done. Some operations
done by a raytracer like POV-Ray may be quite prone to even minuscule
changes in the very least-significant bits of some calculations. For
example a change of 0.00001% in the direction of a ray may in some scenes
cause a big enough difference to produce a pixel which differs in the
least significant bit (and sometimes even more).

-- 
                                                          - Warp

Post a reply to this message