POV-Ray : Newsgroups : povray.beta-test : master branch issue 29 linux compilation errors : Re: master branch issue 29 linux compilation errors Server Time
15 May 2024 09:11:51 EDT (-0400)
  Re: master branch issue 29 linux compilation errors  
From: clipka
Date: 7 Jul 2014 12:51:05
Message: <53bacff9$1@news.povray.org>
Am 06.07.2014 13:18, schrieb clipka:

> I finally found out what's going on here.
>
> The implementation of adaptive area lights uses an N*M cache for
> "lightlet" data it has already computed. Previously, yet-uncomputed data
> was flagged by setting the respective colour's red channel to -1. I had
> changed this to use a NaN ("Not-a-Number") value instead, to avoid
> problems when a user deliberately sets a light source's colour to
> negative red.
>
> Now of course this NaN value has to be tested for; according to IEEE
> standard, a NaN value has the property that it is non-equal to anything,
> even itself. So I wrote the test: "if (red != red)...".
>
> Well, it turns out that the g++ compiler optimizes this comparison away
> when in "-ffast_math" mode.

Solved as follows:

Configure will now test whether NaNs and/or Infinities are available for 
both double and single precision, survive conversion between the two 
types, and can be tested for.

Attempted ways to test for NaNs include std::isnan(), global isnan(), or 
comparison of the value with itself (or, more precisely, a volatile copy 
thereof, to prevent the test from being optimized away).

Attempted ways to test for Infinities include std::isnan(), global 
isnan(), or comparison of the value's absolute with the highest finite 
value representable by the respective type (or, more precisely, a 
volatile copy thereof, to prevent the test from being optimized away).


If NaNs are available, survive type conversion and are testable, those 
will be used to mark a colour as invalid.

Otherwise, if Infinities are available, survive type conversion and are 
testable, negative infinity will be used instead.

Otherwise, as a last resort, the negative of the highest finite value 
representable by single-precision float will be used instead.


On g++ with -ffast_math, it turns out that negative infinity is a viable 
option; while isinf() is dysfunctional as expected, infinities do 
survive type conversion and can be tested for by comparing the value's 
absolute with the highest finite value representable.


Post a reply to this message

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