 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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:
> 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
|
|
| |
| |
|
|
|
|
| |
