-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris B wrote:

> news:44281e86$1@news.povray.org...
> 
>>Those kind of numbers are
>>usually generated by the floating point hardware and the code that
>>writes them as the string "QNAN" is in the standard C library, so a
>>search through the povray code shouldn't turn up anything...
>>
>>Jerome
>>
> 
> 
> Ah OK.
> Well is there something Tim could do to detect this from within POV-Ray 
> before writing it out to the file?
> 
	Not that I know. The C99 standard defines the "isfinite",
"isnormal", "isnan" and "isinf" functions to check for this kind of
numbers but AFAIK there are no SDL equivalent.

> I had one idea. Don't know if it's valid or whether it might be a stupid 
> idea, but , if it's an intermittent problem with the FPU (an overflow or 
> something), then could he perform each calculation twice and compare the 
> results? (either with a numeric comparison or converting the numbers to 
> strings)
> 
	In most cases, performing the same computation twice should give
the same result. Moreover, the equality test isn't a solution: I
don't remember what the standard says but gcc with the -ffast-math
option will give nan==1. Now, I know that the -ffast-math option
breaks the standards (it says so in the docs), but I also know that
VisualC breaks them too and I don't know whith what options Tim's
version of POV was compiled...

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEKFRsd0kWM4JG3k8RAo2XAJ9aMS+IVQW1WKL5V/WuLK9ZxpYKpACgqu3R
2ioKRyyeHomfurWhPkEdD1I=
=A+cp
-----END PGP SIGNATURE-----

Post a reply to this message

> In most cases, performing the same computation twice should give
> the same result. Moreover, the equality test isn't a solution: I
> don't remember what the standard says but gcc with the -ffast-math
> option will give nan==1. Now, I know that the -ffast-math option
> breaks the standards (it says so in the docs), but I also know that
> VisualC breaks them too and I don't know whith what options Tim's
> version of POV was compiled...

*sigh*

Hm, what to do, what to do... I'd sure like a solution to the problem. Since
then I've found of course that it seems that every now and then, when you
use vaxis_rotate without an actual axis (<0,0,0> ain't an axis), it returns
something that POV-Ray will write as <1.#QNAN,1.#QNAN,1.#QNAN>. Not all the
time, and even with the same scene, same seed and same settings, it doesn't
reproduce. It's weird thought that I can still do vcross-calculations, check
the length using vlength to ensure the matrix has unit-length vectors and
some other stuff with that "QNAN-Vector", but just when I write the file, I
write something that I can't read...

Regards,
Tim

-- 
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Nikias wrote:
> Hm, what to do, what to do... I'd sure like a solution to the problem. Since
> then I've found of course that it seems that every now and then, when you
> use vaxis_rotate without an actual axis (<0,0,0> ain't an axis), it returns
> something that POV-Ray will write as <1.#QNAN,1.#QNAN,1.#QNAN>. Not all the
> time, and even with the same scene, same seed and same settings, it doesn't
> reproduce. It's weird thought that I can still do vcross-calculations, check
> the length using vlength to ensure the matrix has unit-length vectors and
> some other stuff with that "QNAN-Vector", but just when I write the file, I
> write something that I can't read...
> 
	Yes, NaN values may still be used in any following floating point
operations and the result will then be NaN whatever the operation
and the other operands (except for tests). I think there is a way to
cause a program to fail in this case, but I can't remember what it
is (and it might require a modification of the source code).

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEKFw3d0kWM4JG3k8RAn+rAJ4+olt5aFaPoDToKClM/2FpO/X/KACcCc+7
grnPY/L2AALv5/1Uw317C5Q=
=9zyI
-----END PGP SIGNATURE-----

Post a reply to this message

> Yes, NaN values may still be used in any following floating point
> operations and the result will then be NaN whatever the operation
> and the other operands (except for tests). I think there is a way to
> cause a program to fail in this case, but I can't remember what it
> is (and it might require a modification of the source code).

Hm. Since the results will always be NaN, but tests return something
specific, maybe I could construct a validity-check which covers that exact
problem. Any ideas what tests I could do to find if it's a NaN? Obviously I
can't check if the value is equal to every known float, but if the value is
larger as well as smaller than a given other value, it surely has to be NaN
(I'm guessing that a test will always return false or true when coupled with
an NaN, so maybe checking to paradox things could be the clue).

Of course, to actually test any of this, I'd need a fail-proof way to
generate NaN. I might have to fumble a little with vaxis_rotate and the
<0,0,0>-axis...

Regards,
Tim

-- 
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

Tim Nikias wrote:
> I might have to write myself a script to generate QNANs in order
> to "experiment" what I can do about them... Unless someone already knows a
> fool-proof way of generating one?

Generating NaNs should be quite trivial. I can do it like this:

   #debug str(1/0 - 1/0, 0, 3)

It shows up as "nan", not as "#QNAN" here on Mac OS X, but I guess 
that's an implementation detail of my C library.

(For some reason POV-Ray here considers 0/0 as inf, while I'd expect it 
to be nan - and in my own programs, it is.)

  -Christian

Post a reply to this message

> Generating NaNs should be quite trivial. I can do it like this:
>
>    #debug str(1/0 - 1/0, 0, 3)
>
> It shows up as "nan", not as "#QNAN" here on Mac OS X, but I guess
> that's an implementation detail of my C library.
>
> (For some reason POV-Ray here considers 0/0 as inf, while I'd expect it
> to be nan - and in my own programs, it is.)

Strange enough, when I use
 #declare Val = 1/0;
and write it to disc, I get this in the file:

1e+017

A high number. I seem to remember that POV-Ray stops at division by 0, why
not when I declare it? Must be some parsing-thing or such, probably. Well,
not the slightest closer to getting to the test-subject! :-)

Regards,
Tim

-- 
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

> A high number. I seem to remember that POV-Ray stops at division by 0, why
> not when I declare it? Must be some parsing-thing or such, probably. Well,
> not the slightest closer to getting to the test-subject! :-)

PS: That POV-Ray "stopped", not "stops". Didn't it stop in former versions,
or am I brain-damaged and having false memories?

-- 
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

"Tim Nikias" <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> wrote in 
message news:4428663a$1@news.povray.org...
>
> Of course, to actually test any of this, I'd need a fail-proof way to
> generate NaN. I might have to fumble a little with vaxis_rotate and the
> <0,0,0>-axis...
>
> Regards,
> Tim
>

Hi Tim,

For me the following SDL generates a QNAN every time (or rather 3).
I'm on Windows XP with POV-Ray 3.6.
This string comparison detects it too.

Regards,
Chris B.


#local A = vaxis_rotate(0,0,0);
#local B = str(A.x,1,5);
#if (strcmp(B,"1.#QNAN")=0)
  #debug "***     QNAN Detected     ***\n"
#end

Post a reply to this message

> For me the following SDL generates a QNAN every time (or rather 3).
> I'm on Windows XP with POV-Ray 3.6.
> This string comparison detects it too.

Yup, works for me too. Making the string smaller kills your
string-comparison, but that doesn't matter. I'll see what I can do with this
QNAN-Vector, might be interesting stuff to find. "EXPERIMENTAL" numbers,
so-to-speak. :-)

My first thought of checking if the QNAN is smaller as well as larger as a
given value doesn't work, too bad. I had hoped to have some means of simple
arithmetic to sort out QNANs instead of a pure check for QNAN and an
else-clause if there is...

Regards,
Tim

-- 
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim Nikias wrote:
> My first thought of checking if the QNAN is smaller as well as larger as a
> given value doesn't work, too bad. I had hoped to have some means of simple
> arithmetic to sort out QNANs instead of a pure check for QNAN and an
> else-clause if there is...
> 
	You might want to try if the number is equal (==) but not lower or
equal (<=) than 1.0 (with gcc 4.0.1 in fast math mode the first test
returns true, and the second false). Of course this will be
platform-specific and possibly even pov-version-specific...

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEKYQld0kWM4JG3k8RAs4YAKCMOKQxR0SRz2MLULUczKQFAnQMxgCeOI+O
S6it6oRHj/mMUi/lzH6g3tA=
=8EbK
-----END PGP SIGNATURE-----

Post a reply to this message