Warp <war### [at] tagpovrayorg> wrote:
> Dennis Clarke <dcl### [at] blastwaveorg> wrote:
> > Wow .. now comes the really hard part, is there a test scene file that
> > always reports the same output data byte for byte ?  Some way to confirm
> > the accurate functionality of the resultant binary that I have here ?
>
>   Different systems and sometimes even different compilers can produce
> POV-Ray binaries which produce different results (in the least significant
> bits). All kinds of floating point optimizations, for instance, can produce
> different results which usually are not visible because the differences are
> so minimal, but revealed by a bit-by-bit comparison of the result.
>   Floating point artithmetic is slightly fuzzy and different systems and
> compilers may generate slightly differing results (and even the same compiler
> may produce different results depending on the optimization flags). Thus you
> shouldn't expect identical results from a program so heavily dependant on
> floating point as POV-Ray compiled in two totally different architectures
> with two totally different compilers.
>

You are totally right and wrong at the same time :-)

In my opinion.

please .. let me expound on that before you delete me as a mindless troll
that wanders into mailists groping in the dark for anything to beat up on
.... I swear that is not me !

I have this belief, and its just a belief founded on simple theory, that a
computer that complies with well documented specs should be able to take
code and compile it, run it, and produce the exact same results repeatedly
provided that there are no noise components in the process such as
stochastic processes or PRNG/RNG data involved.  One would also expect that
the architecture of the computer would be of no concern.

Yes, a silly dream to be sure but I guess I come from a background of
Fortran and Pascal ( and something we called machine code! ) from the 80's
on mainframes while I worked in the military and aerospace industry.  It
was very common to take code from a given development environment with
tightly defined input data sets and move that code to other systems and
then perform various tests to ensure that the output data matched
precisely.  Needless to say the process of working with floating point was
made more interesting in that we often defined our own floating point spec
( sign + exponent + mantissa + other stuff like an error field etc etc ).
The emergence of commercially available libraries for matrix operations and
bessel functions etc etc changed all that.

I guess i am trying to say that, as my old professor used to say, working
with floating point is like moving piles of dirt on a beach.  Every time
you move the dirt you pick up some sand and lose some dirt.  Its the nature
of the beast.  Yet somehow we were able to take code from a Honeywell
CP6/DPS8 system and move it to an IBM 3090 with an exact match on the
output data given well defined test sets.

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.

I could then build the binary using highly standards compliant tools on
multiple architectures and get the exact same data from a given scene file
and set of parameters.

Probably a silly idea but it may be fun to get the output data in a floating
point format as opposed to an image.  Perhaps the OpenEXR image format (
http://www.openexr.com/ ) may be of value with its 32-bit floating point
and 32-bit integer data types.

Sorry for the long post here ... I recognize your name going back many years
in this project and was hoping that you could express your feelings on some
of these ideas.  At the very least, there is the issue of my use of
standard tools from the Sun/Solaris world and watching them issue thousands
of warnings.

Dennis

Post a reply to this message