Skip to main content
GameDev.net gamedev.net
🔒 Locked

Cross Product, Normalizing, and overflows

Started by Mr Lane Sep 24, 2005 at 1:50 AM 8 replies 1.6k views
Original Post
Mr Lane
Mr Lane
Hello I have 2 vectors (128,0,0) and (128,0,128). They are coplanar. They are actually represented as doubles in C++. I need to find the normal of these. Now I have taken the cross product and the result is: (0, -16384,0) (I think :)) Now I need to normalize the normal vector, by doing: sqrt(x^2, y^2, z^2) and then dividing each component of the normal vector by the result of this square root. My problem is: 16384^2 is a big big number and I may have vectors with components even larger than 128. I am worrying about overflow here. I am not a maths guru, so I ask: what can I do to "compress" this 16384 value down before normalizing without affecting the computation? (Also, check my working if you can :) ) Thanks
timw
timw
I don't think this is a problem. but if you were having problems with it you could multiply your vector by a small constant (<< 1) before normalizing. since multiplying a vector by a constant doesn't effect the direction of the vector. In this way you'd ensure that the squared components are all small.
Mr Lane
Mr Lane
Quote:
Original post by timw
I don't think this is a problem. but if you were having problems with it you could multiply your vector by a small constant (<< 1) before normalizing. since multiplying a vector by a constant doesn't effect the direction of the vector. In this way you'd ensure that the squared components are all small.
Ahh yes, scalar multiplication wont affect the direction of the vector. I am an idiot.

Infact, this is what normalizeing is effectively doing isnt it? (but i just need to divide by a scalar value before I normalize so i dont run into that ^2 overflow) :)

Thanks. Problem solved I think.
Dmytry
Dmytry
If you work with doubles, them are okay for numbers up to around
10308 , i.e.
1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 00

so with cross product you might get overflow only when components of vector have more than 75 digits [grin][lol] (when you multiply two 75-digits numbers you get something like 150 digits and when you multiply together two 150-digit numbers, you get something around 300 digits, still fits in the double) You wouldn't even get precision losses.
timw
timw
Quote:

Infact, this is what normalizeing is effectively doing isnt it?

yup..

ya, like dmytry said I don't think it'll be a problem. lol but if it is.. do the multiplication.



Tim
Dmytry
Dmytry
with multiplication you can get underflow instead of overflow...
Mr Lane
Mr Lane
Quote:
Original post by Dmytry
If you work with doubles, them are okay for numbers up to around
10308 , i.e.
1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 00

so with cross product you might get overflow only when components of vector have more than 75 digits [grin][lol] (when you multiply two 75-digits numbers you get something like 150 digits and when you multiply together two 150-digit numbers, you get something around 300 digits, still fits in the double) You wouldn't even get precision losses.
I just realized that floating point gives you much larer number range that int. I always assumed that 32-bit int would be able to take larger numbers, whereas floating point had less of a range but allowed for decimals. Seems it doesnt work that way and that FP also allows for much larger numbers than int.
Bobtree
Bobtree
You need to read this:
"What Every Computer Scientist Should Know About Floating-Point Arithmetic"
http://docs.sun.com/source/806-3568/ncg_goldberg.html

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.