Sign in to follow this  
Endar

accounting for floating-point innacuracies

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Guest 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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Endar
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?
See my GDC 2005 presentation here: http://realtimecollisiondetection.net/pubs/

It (slides 39-43 in particular) has details on how you want to compare floating-point numbers (and why).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Christer Ericson
Quote:
Original post by Endar
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?
See my GDC 2005 presentation here: http://realtimecollisiondetection.net/pubs/


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".

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this