POV-Ray : Newsgroups : povray.binaries.images : Divide by negative zero : Re: Divide by negative zero Server Time
20 Apr 2024 00:21:17 EDT (-0400)
  Re: Divide by negative zero  
From: clipka
Date: 26 Oct 2018 02:02:46
Message: <5bd2ae06$1@news.povray.org>
Am 26.10.2018 um 05:41 schrieb Anthony D. Baye:
> It seems to me that the engine used to throw an error when this happened...
...
> Version 3.8.0-alpha.9606898.unofficial

That's on Linux, I presume?

POV-Ray does produce a warning if the second operand compares /equal to 
zero/.

Now as you've already noticed, there are two different zero values: A 
positive and a negative.

According to the C++ standard, /both/ values should compare equal to 
zero, so you /should/ get a warning when dividing by negative zero.

- BUT -

POV-Ray for Linux is usually compiled with `-ffast-math`. In this mode, 
the compiler does some smart floating-point optimizations - by cutting 
corners and /violating the standard/ for various special cases.

I don't know the details, but this sounds just like the kind of 
optimizations `-ffast-math` would do: Refuse to consider negative zero 
equal to (positive) zero just because hey, how can two values be equal 
if they have different binary representation.


There is no reliable way to work around this: Since this is all about 
the compiler violating the standard for the sake of optimization, there 
is no guarantee that a workaround would actually kick in, as it might 
also be subject to non-standard-compliant optimizations - or 
optimizations /based/ on the standard.

For example, if we chose to work around this by comparing the divisor 
with positive zero /and/ with negative zero, the compiler might decide 
that since positive and negative zeros are equivalent according to the 
standard, it can just as well drop one of the comparisons. Theoretically 
we might even end up making things worse, because the compiler might 
choose to keep the comparison with negative zero rather than the one 
with positive zero.

A compiler violating the C++ standard is free to contradict itself in 
the presumptions it uses for optimizations.


So if you want to be sure that you're not dividing by negative zero, 
either (a) explicitly test if the divisor is equal to zero in your scene 
code (this is reliable because POV-Ray's equality operator is 
implemented to use an error margin), or (b) re-compile POV-Ray without 
`-ffast-math`.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.