accounting for floating-point innacuracies
Author
I've been mulling this over for a while, but when I was writing my plane-aabbox intersection functions, I had to account for errors due to the inaccuracies that using floating point numbers in a computer.
Is there a site that anyone knows of that will explain this and help me write a couple of basic methods for floating-point comparisons and the like?
This may seem overly simple, but could your problem be solved by using doubles instead of floats?
A description of ieee 754 standard will probably answer all your questions when you start working things out.
http://en.wikipedia.org/wiki/IEEE_754
I'm also assuming that the errors you were accounting for were when testing equality?
http://en.wikipedia.org/wiki/IEEE_754
I'm also assuming that the errors you were accounting for were when testing equality?
Author
Quote:Original post by Anonymous Poster
A description of ieee 754 standard will probably answer all your questions when you start working things out.
http://en.wikipedia.org/wiki/IEEE_754
I'm also assuming that the errors you were accounting for were when testing equality?
At the moment, yeah. But I was thinking that there'll probably be many more things that I'll end up needing to do (not really sure what yet, but there probably will be) that will have problems with floating point numbers, either with equality accuracy, or other things, and it would be better to start now on finding out how to fix them.
Quote:Original post by EndarSee my GDC 2005 presentation here: http://realtimecollisiondetection.net/pubs/
I've been mulling this over for a while, but when I was writing my plane-aabbox intersection functions, I had to account for errors due to the inaccuracies that using floating point numbers in a computer.
Is there a site that anyone knows of that will explain this and help me write a couple of basic methods for floating-point comparisons and the like?
It (slides 39-43 in particular) has details on how you want to compare floating-point numbers (and why).
The only other issue I can think of that needs to be understood is the mismatch between dynamic range and precision.
Let X be the number of centimeters between the earth and the sun, X has an error of many centimeters under 32-bit floats. Adding one centimeter to X will never change X.
This really really needs to be understood if you intend to add numbers together that could have a big difference in magnitude.
Let X be the number of centimeters between the earth and the sun, X has an error of many centimeters under 32-bit floats. Adding one centimeter to X will never change X.
This really really needs to be understood if you intend to add numbers together that could have a big difference in magnitude.
Quote:Original post by Christer EricsonQuote:Original post by EndarSee my GDC 2005 presentation here: http://realtimecollisiondetection.net/pubs/
I've been mulling this over for a while, but when I was writing my plane-aabbox intersection functions, I had to account for errors due to the inaccuracies that using floating point numbers in a computer.
Is there a site that anyone knows of that will explain this and help me write a couple of basic methods for floating-point comparisons and the like?
I was about to suggest the chapter from your book on numerical robustness.
I have a copy of "Real-Time Collision Detection" that the publisher sent us. I wanted to send them some notes with constructive criticism (as is usually the polite thing to do), but I couldn't find anything to criticize! Nice work. It helped me when I was implementing a (non-real-time) cloth self-collision & response system.
Sorry for the thread hijack, just a quick plug for "Real-Time Collision Detection".
did you consider the possibility that integers might be better suited for AABB's?
dont be fooled: floats dont have infinite range. actually, the range over which they have acceptable accuracy is probably much less than what you could get with an int.
dont be fooled: floats dont have infinite range. actually, the range over which they have acceptable accuracy is probably much less than what you could get with an int.
If you require floating point, please check out Christer's book and site, as the error is logarithmic in relation to magnitude or something like that. If you can get away with fixed point, then your problem is a bit easier as the precision doesn't vary with magnitude but you're limiting yourself to the integer pipes of most modern CPUs, effectively halving your efficiency unless you can do other float stuff in parallel.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement