Nan/Inf from angle
The first error/warning that sometimes occurs in my simulation is:
warning: NaN/Inf returned from internal function angle at line 31 of "Math3D.tz"
Presumably, I would be warned if NaN/Inf were passed as an argument to angle (since this seems to happen with other functions), so why is angle returning NaN/Inf despite receiving only vectors as input? How is angle defined exactly, and under what conditions does it return NaN/Inf?
-Jacob
Example
Here's a strange example:
The angle between
(0.59598, 0.00000, 0.80300) and
(-6.55583, 0.00000, -8.83296)
is NaN. I think this should return pi, or something close to 3.14. Why does it return NaN?
-Jacob
could not repeat with your example
I tried to repeat the problem with the values you gave, but was unable to do so:
print angle( ( 0.59598, 0.00000, 0.80300 ), (-6.55583, 0.00000, -8.83296) ).
This prints out 3.141587.
The algorithm for computing angle is given by the expression acos( dot( a, b ) / ( length( a ) * length( b ) ) ). The only thing I can think of that is likely to cause a NaN value is if vector a or b is extremely small.
- jon
Well, that's annoying.
Well, that's annoying. Perhaps the error has to do with some obsolete libraries on my system (I'm assuming C++ gets involved at some point). This error only seems to occur on my XP machine, and not on others.
Anyway, the values I gave were intermediate values I printed out from some other calculation, so perhaps they weren't identical to what was printed out. I've also had problems where things like (0.55656565 == 0.55656565) returns false (0). I fixed that by using an epsilon value for comparison, ie: |0.55656565 - 0.55656565| < epsilon. I was able to fix this angle problem in a similar manner. First I normalized the vectors and then compared the individual components:
|v1::x + v2::x| < epsilon, ... , |v1::z + v2::z| < epsilon.
This works, so I guess it's what I'll stick with.
That is indeed strange that
That is indeed strange that it would only affect the XP machine. Can you confirm that it returns NaN when running the test statement I posted above?
As for the (0.55656565 == 0.55656565) issue, does it actually happen when you have hardcoded values like that, or just when two simulation values should be identical? It should work for the hardcoded values, but for simulation values which should be identical, it's always advisable to use the epsilon approach because of numerical error.
- jon
Hardcoded works fine
Sorry if I made the problem look worse than it is. Both for equality (==) and for the angle function, hardcoded values work fine. I confirmed that the example with angle works as well. It is only when the values are results from some other calculation that epsilon methods appear to be needed, both for equality and for angle.
-Jacob