 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've got a weird problem with POV-Ray and I/O...
What I do is write a series of floats and vectors to a file to save the
transformation of a sphere. I have a macro which gets called and checks if
the matrix is perpendicular and valid. The file is written after that check.
Nontheless, I get "1.#QNAN" in my file, which of course can't be read. The
problem doesn't appear all the time, seems to be slightly persistent when I
make no scene-changes, but generally, it happens right out of the blue. It's
a single file with which it happens, it runs properly on about 50 other file
(I'm using my Rolling-Script in conjunction with my particle system).
Any idea how to check if POV-Ray writes a QNAN instead of a value? I'm
stumped, because POV-Ray doesn't return warning messages or faults with
divide by zero or such. Why should it write a QNAN then?
Regards,
Tim
--
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <442416b6$1@news.povray.org>,
"Tim Nikias" <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> wrote:
> I've got a weird problem with POV-Ray and I/O...
>
> What I do is write a series of floats and vectors to a file to save the
> transformation of a sphere. I have a macro which gets called and checks if
> the matrix is perpendicular and valid. The file is written after that check.
>
> Nontheless, I get "1.#QNAN" in my file, which of course can't be read. The
> problem doesn't appear all the time, seems to be slightly persistent when I
> make no scene-changes, but generally, it happens right out of the blue. It's
> a single file with which it happens, it runs properly on about 50 other file
> (I'm using my Rolling-Script in conjunction with my particle system).
>
> Any idea how to check if POV-Ray writes a QNAN instead of a value? I'm
> stumped, because POV-Ray doesn't return warning messages or faults with
> divide by zero or such. Why should it write a QNAN then?
>
> Regards,
> Tim
The IEEE standard defines two classes of NaN: quiet NaNs (QNaNs) and
signaling NaNs (SNaNs). A QNaN is a NaN with the most significant
fraction bit set; an SNaN is a NaN with the most significant fraction
bit clear. QNaNs are allowed to propagate through most arithmetic
operations without signaling an exception. SNaNs generally signal an
invalid-operation excep-tion whenever they appear as operands in
arithmetic operations.
I was just thinking that Division by zero in float should not give a
NAN strictly speaking because you can never really express a ZERO in
float, instead it will be a small residual value.
--
klp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
kurtz le pirate <kur### [at] yahoo fr> wrote:
> I was just thinking that Division by zero in float should not give a
> NAN strictly speaking because you can never really express a ZERO in
> float, instead it will be a small residual value.
Doesn't division by zero give INF?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The IEEE standard defines two classes of NaN: quiet NaNs (QNaNs) and
> signaling NaNs (SNaNs). A QNaN is a NaN with the most significant
> fraction bit set; an SNaN is a NaN with the most significant fraction
> bit clear. QNaNs are allowed to propagate through most arithmetic
> operations without signaling an exception. SNaNs generally signal an
> invalid-operation excep-tion whenever they appear as operands in
> arithmetic operations.
>
> I was just thinking that Division by zero in float should not give a
> NAN strictly speaking because you can never really express a ZERO in
> float, instead it will be a small residual value.
Hm, all that's pretty interesting and such, but is there any way that I can
check for that in order to prevent POV-Ray writing 1.#QNAN instead of some
number? Should I perhaps check if something is below a certain threshold
value, but not 0, and then do something appropriate to/for the data (e.g. if
it's a vector from a matrix, add+normalize+regenerate a little). Basically,
I take it that this is some sort of precision problem, the kind you can get
when working with too small or too large numbers. Is that a correct
assumption? 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?
Regards,
Tim
--
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Nikias" <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> a écrit
dans le message de news: 44253295$1@news.povray.org...
> I might have to write myself a script to generate QNANs in order
> to "experiment" what I can do about them...
yes, i think this is a good step.
> Unless someone already knows a fool-proof way of generating one?
i don't know. povray'programmers team should provide you more about
that
--
klp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> i don't know. povray'programmers team should provide you more about
> that
Well, then let this post be my cry for help to the programmers! :-)
I'm not sure, I've tried simply successively dividing by 2 or 10 to get
smaller and smaller numbers. Interesting enough is that when you divide 1 by
10 and use str(Value,1,50) you find another fraction somewhere (but this is
of course floating point arithmetic and the troubles associated with it,
just interesting to see it in person). Neither of the two methods get me a
QNAN though, the only thing I ended up with when building a number by hand
(using a while-loop to add "0"s behind the comma and a "1" at the end) was a
string too long error.
Another interesting thing to note is that I'm starting to think that this
QNAN is more a problem with vectors than with single floating point values.
Cause everytime I get the QNAN in my matrix-output (which I simply output as
3 vectors for the three axis') I get the QNAN in x, y and z, not just a
single spot of the vector. OTOH, the vector-arithmetic might end up with an
invalid vector (using vcross a few times to build a matrix out of a few
vectors) and thus get me the QNAN in every dimension... Well well, gotta go
look further until some POV-Ray-programming-wiz stumbles upon this post and
knows where to look. :-)
Regards,
Tim
--
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:4427d830$1@news.povray.org...
>> i don't know. povray'programmers team should provide you more about
>> that
>
> Well, then let this post be my cry for help to the programmers! :-)
>
> I'm not sure, I've tried simply successively dividing by 2 or 10 to get
> smaller and smaller numbers. Interesting enough is that when you divide 1
> by
> 10 and use str(Value,1,50) you find another fraction somewhere (but this
> is
> of course floating point arithmetic and the troubles associated with it,
> just interesting to see it in person). Neither of the two methods get me a
> QNAN though, the only thing I ended up with when building a number by hand
> (using a while-loop to add "0"s behind the comma and a "1" at the end) was
> a
> string too long error.
>
> Another interesting thing to note is that I'm starting to think that this
> QNAN is more a problem with vectors than with single floating point
> values.
> Cause everytime I get the QNAN in my matrix-output (which I simply output
> as
> 3 vectors for the three axis') I get the QNAN in x, y and z, not just a
> single spot of the vector. OTOH, the vector-arithmetic might end up with
> an
> invalid vector (using vcross a few times to build a matrix out of a few
> vectors) and thus get me the QNAN in every dimension... Well well, gotta
> go
> look further until some POV-Ray-programming-wiz stumbles upon this post
> and
> knows where to look. :-)
>
> Regards,
> Tim
>
Hi TIm,
I tried to write out a few different things that I thought might be invalid,
but I didn't manage to generate any QNANs.
I would suggest doing a tool that will let you do a multi-file search on
'QNAN' against the POV-Ray source to give you some idea about the type of
circumstances in POV-Ray that can lead to a QNAN. I can't imagine there'll
be that many.
Regards,
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris B wrote:
> Hi TIm,
> I tried to write out a few different things that I thought might be invalid,
> but I didn't manage to generate any QNANs.
> I would suggest doing a tool that will let you do a multi-file search on
> 'QNAN' against the POV-Ray source to give you some idea about the type of
> circumstances in POV-Ray that can lead to a QNAN. I can't imagine there'll
> be that many.
>
Unfortunately, there probably aren't any! 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
- --
+------------------------- 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)
iD4DBQFEKBtmd0kWM4JG3k8RAhjjAJY/ft3ahJMlQ0ArVz+2AkR3qOQgAKCfQYZz
rAYVSxuBbLV0EQBZbWsUaA==
=AB89
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
""Jérôme M. Berger"" <jeb### [at] freefr> wrote in message
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?
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)
Chris B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chris B wrote:
> ""Jérôme M. Berger"" <jeb### [at] freefr> wrote in message
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
