 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
and my calculation returns the following values:
< -1.#IND000,-1.#IND000,-1.#IND000 >
can anyone help me make sense of this?
Bottom line, I just need to know how to test for these and give them a
skip when they occur.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Charter wrote in message <3C7### [at] aol com>...
>and my calculation returns the following values:
>
>< -1.#IND000,-1.#IND000,-1.#IND000 >
>
>can anyone help me make sense of this?
>
>Bottom line, I just need to know how to test for these and give them a
>skip when they occur.
Without seeing the code you are using, I can't tell you for certain.
The -1.#IND means that a recent calculation had an undefined result. I'm
guessing you're dividing by zero somewhere. Do your calculations normalize
the vector?
--
Mark
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mark Wagner wrote:
>
> Without seeing the code you are using, I can't tell you for certain.
> The -1.#IND means that a recent calculation had an undefined result. I'm
> guessing you're dividing by zero somewhere. Do your calculations normalize
> the vector?
>
> --
> Mark
>
Thanks Mark, as it turns out it is not really a show stopper
I tested: #if ( Norm.x = -1 & Norm.y = -1 & Norm.z = -1 )
don't use Norm
crude, I know, but good enough in this case
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 28 Feb 2002 05:46:57 -0500, Jim Charter <jrc### [at] aolcom> wrote:
> I tested: #if ( Norm.x = -1 & Norm.y = -1 & Norm.z = -1 )
AFAIK
-1 != -1.#IND
btw: I didn't found any place in 3.5 documentation where "#IND" is noted
and/or explained. It can confuse newbies.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Skiba <abx### [at] babilonorg> wrote:
> AFAIK
>
> -1 != -1.#IND
>
> btw: I didn't found any place in 3.5 documentation where "#IND" is noted
> and/or explained. It can confuse newbies.
It is an artifact of the C library used. Results may be different for
different C libraries and thus this cannot be noted in the documentation.
Further, checking for NANs and other invalid floating-point values was not
part of the C standard until C99, so many compilers don't support those recent
improvements yet. For this reason, it remains the users' responsibility to
only feed valid input into the various floating-point calculations in order to
get valid output...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thankyou again for the explanation. My SDL was not well-formed and the
bad input was most likely do to sloppy loop control. Since it happened
at the end of a loop, it was just as easy to drop the offending
calculation.
Thorsten Froehlich wrote:
> In article <vo2s7uc355p2c5e52bea9uva2ibjbqcndt@4ax.com> , W"odzimierz ABX
> Skiba <abx### [at] babilonorg> wrote:
>
>
>>AFAIK
>>
>>-1 != -1.#IND
>>
>>btw: I didn't found any place in 3.5 documentation where "#IND" is noted
>>and/or explained. It can confuse newbies.
>>
>
> It is an artifact of the C library used. Results may be different for
> different C libraries and thus this cannot be noted in the documentation.
> Further, checking for NANs and other invalid floating-point values was not
> part of the C standard until C99, so many compilers don't support those recent
> improvements yet. For this reason, it remains the users' responsibility to
> only feed valid input into the various floating-point calculations in order to
> get valid output...
>
> Thorsten
>
> ____________________________________________________
> Thorsten Froehlich, Duisburg, Germany
> e-mail: tho### [at] trfde
>
> Visit POV-Ray on the web: http://mac.povray.org
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
