In article <3A6231FA.FD3761DD@sunshine.net>, dan williams 
<dan### [at] sunshinenet> wrote:

> I have here a verry interesting little (only happens with particular
> values) bug, it turned up when I started using linux for povray, the
> comments in the file say about everything else I know about it.
> 
> I'd do some debugging if I knew where to start.
> 
> if you see the sphere you are not affected by the problem, if not, you
> are.

This group, povray.unix, is for Unix-specific problems. For help with 
the scene language or a possible bug with the core program, you should 
post to one of the general POV-Ray groups, like povray.newusers, 
povray.advanced-users, or povray.general. I'm forwarding this thread to 
povray.general.

If you put:
#debug concat("rotate < ", str(rbshx, 1, 1), ", ", str(rbshy, 1, 1), ", 
", str(rbshz, 1, 1), ">")
in your scene, you will see that "rgshx" is NaN (Not a Number). The NaN 
gets into the matrix and fouls things up. If you put;
#debug concat("acos(", str((len/2)/0.78, 1, 1), ")\n")
you will see that you are attempting to calculate the arc-sine of 1, 
which seems to be undefined.

Using a macro to detect and work around this case works:
#macro ACos(V) #if(V < 1) acos(V) #else (0) #end #end

#declare rbshx = degrees(ACos((len/2)/0.78));

As I recall, the behavior of the inverse trig functions was one of the 
things that was changed in 3.1...they are more mathematically correct, 
but maybe less useable...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

awsome, thanks!

and sorry for posting it in the wrong place... chris young suggested it :-)
this leads me to a question: Why does it not detect the NAN and drop out of
the parse???

dan

/me likes the way old dos ver works...

Chris Huff wrote:

> In article <3A6231FA.FD3761DD@sunshine.net>, dan williams
> <dan### [at] sunshinenet> wrote:
>
> > I have here a verry interesting little (only happens with particular
> > values) bug, it turned up when I started using linux for povray, the
> > comments in the file say about everything else I know about it.
> >
> > I'd do some debugging if I knew where to start.
> >
> > if you see the sphere you are not affected by the problem, if not, you
> > are.
>
> This group, povray.unix, is for Unix-specific problems. For help with
> the scene language or a possible bug with the core program, you should
> post to one of the general POV-Ray groups, like povray.newusers,
> povray.advanced-users, or povray.general. I'm forwarding this thread to
> povray.general.
>
> If you put:
> #debug concat("rotate < ", str(rbshx, 1, 1), ", ", str(rbshy, 1, 1), ",
> ", str(rbshz, 1, 1), ">")
> in your scene, you will see that "rgshx" is NaN (Not a Number). The NaN
> gets into the matrix and fouls things up. If you put;
> #debug concat("acos(", str((len/2)/0.78, 1, 1), ")\n")
> you will see that you are attempting to calculate the arc-sine of 1,
> which seems to be undefined.
>
> Using a macro to detect and work around this case works:
> #macro ACos(V) #if(V < 1) acos(V) #else (0) #end #end
>
> #declare rbshx = degrees(ACos((len/2)/0.78));
>
> As I recall, the behavior of the inverse trig functions was one of the
> things that was changed in 3.1...they are more mathematically correct,
> but maybe less useable...
>
> --
> Christopher James Huff
> Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
> TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
>
> <><

Post a reply to this message

On Sun, 14 Jan 2001 17:33:22 -0800, dan wrote:
>awsome, thanks!
>
>and sorry for posting it in the wrong place... chris young suggested it :-)
>this leads me to a question: Why does it not detect the NAN and drop out of
>the parse???

The question should be "why does the parser let me do things that return NaN
and not print a warning about it?"

I suspect that the reason it can't detect a NaN has something to do with 
portability across systems; there's no guarantee that every system uses 
IEEE floating point, so we can't check for NaN directly.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On 14 Jan 2001 22:16:33 -0500, Ron Parker wrote:
>On Sun, 14 Jan 2001 17:33:22 -0800, dan wrote:
>>awsome, thanks!
>>
>>and sorry for posting it in the wrong place... chris young suggested it :-)
>>this leads me to a question: Why does it not detect the NAN and drop out of
>>the parse???
>
>The question should be "why does the parser let me do things that return NaN
>and not print a warning about it?"

By the way, this specific problem (domain errors in asin/acos) will be fixed
in version 3.5.  Specifically, the asin and acos functions will clip their
input to the -1..1 range and print a warning each time a domain error occurs.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Sun, 14 Jan 2001 17:33:22 -0800, dan wrote:
>and sorry for posting it in the wrong place... chris young suggested it :-)

I'm sure he told you, but for the benefit of anyone else who may be reading:
Emailing Chris Young with your POV problems is not a very productive thing
to do.  It wasn't even a very productive thing to do when he was the Team
coordinator.  Problems such as this one are why this newsgroup and the 
bugreports newsgroup exist, and why the TAG exists.  If you absolutely need
support by email, try contacting the TAG first; see http://tag.povray.org for 
more information.

I realize that you did just what the documentation says you should do with
bug reports; I'm not trying to single you out or anything.  I just thought 
it needed to be said.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

[ I can't see Dan's original article for some reason, so I may be a bit
out of context ]

On 2001-01-14 23:52, Chris Huff <chr### [at] maccom> wrote:
>If you put:
>#debug concat("rotate < ", str(rbshx, 1, 1), ", ", str(rbshy, 1, 1), ", 
>", str(rbshz, 1, 1), ">")
>in your scene, you will see that "rgshx" is NaN (Not a Number). The NaN 
>gets into the matrix and fouls things up. If you put;
>#debug concat("acos(", str((len/2)/0.78, 1, 1), ")\n")
>you will see that you are attempting to calculate the arc-sine of 1, 
>which seems to be undefined.

The arc-cosine of 1 should be defined (0), but the arc-cosine of any
value above 1 isn't. He is probably trying to compute asin(1.0000001)
or something like that, especially since there is a mysterious constant
"0.78" above, which looks as if it was rounded to two digits. Never
round numbers[1], always let povray do the calculations. I.e., if you want
the square root of two, write sqrt(2), not 1.41.

	hp

[1] Of course the computer rounds, too, but it uses more digits and -
more importantly - its rounding rules are consistent with its arithmetic
rules.

-- 
   _  | Peter J. Holzer    | All Linux applications run on Solaris,
|_|_) | Sysadmin WSR       | which is our implementation of Linux.
| |   | hjp### [at] wsracat      | 
__/   | http://www.hjp.at/ |	-- Scott McNealy, Dec. 2000

Post a reply to this message