In article <slr### [at] tealhhjpat> , 
hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:

> On Sat, 22 Apr 2000 14:43:54 -0500, Thorsten Froehlich wrote:
>>The other comparison operators do not take EPSILON into account.  So
>>practically POV-Ray should contain a workaround for these cases as well.
>
> I disagree. This workaround assumes that all numbers are in a certain
> range (about 1E-3 ... 1E6). While this may be true for most scenes it
> certainly isn't universally true. In my scene files one pov unit is
> always one meter, whether I am modelling the circuits of a microchip or
> the whole solar system.

Be aware that you currently cannot model a solar system in POV-Ray anyway!

I think it does not make sense to have scales the way you suggest, it will
always cause problems with floating-point precision.

> Right. Especially make it clear that floating point numbers are binary
> and cannot exactly represent fractions which are not a multiple of some
> power of two. 1/2, 3/4, 356/1024 can be exactly represented, but 1/10
> cannot (just like 1/3 cannot be exactly represented in decimal).
> Therefore 10 * 0.1 is not equal to 1.
>
> Instead of
>
> #local D = 2;
> #local X = -D;
> #while (X <= D)
>    #local X = X + 0.1;
>    do_something_with(X)
> #end
>
> write
>
> #local D = 20;
> #local X1 = -D;
> #while (X1 <= D)
>    #local X1 = X1 + 1;
>    #local X = X/10
>    do_something_with(X)
> #end
>
> this is exact and will produce the expected result.

It is also important to keep it simple for most users.  Telling them that
there are pitfalls when using floating-point math is one thing, forcing them
to know about the exact internals behind floating-point math is inadequate
for a user centric program like POV-Ray.  In my opinion users should be able
to use regular mathematics expressions, and not have to even think about
precision.  Your example above clearly shows how messy and unintuitive it
would be :-)

To solve this problem it might be best to go the way a lot of programs go:
Force maximum (and minimum) limits somewhere in the range of 10e-9 to 10e9.
Thus, if objects are placed outside this limit (the current one is 10e6 I
think) the scene should be rejected.  This would also eliminate the 'new
user wants to model solar system'-error.  The lower bound can not be
enforced, but at least we can tell users that anything below 10e-9 will
fail.  As basically all systems today use IEEE floating-point formats (or
other formats with more, but not less precision) we should be able to define
reasonable small a cross-platform EPSILON that cannot be changed in config.h
(as changing it currently can break scenes).


      Thorsten


PS: Usual disclaimer applies, I do not speak for the team.

Post a reply to this message