are int, float, long, double, side-effects of computer engineering?

John Nagle nagle at animats.com
Wed Mar 14 01:32:14 EDT 2012


On 3/7/2012 2:02 PM, Russ P. wrote:
> On Mar 6, 7:25 pm, rusi<rustompm... at gmail.com>  wrote:
>> On Mar 6, 6:11 am, Xah Lee<xah... at gmail.com>  wrote:

> I might add that Mathematica is designed mainly for symbolic
> computation, whereas IEEE floating point numbers are intended for
> numerical computation. Those are two very different endeavors. I
> played with Mathematica a bit several years ago, and I know it can do
> numerical computation too. I wonder if it resorts to IEEE floating
> point numbers when it does.

    Mathematica has, for some computations, algorithms to determine the
precision of results.  This is different than trying to do infinite
precision arithmetic, which doesn't help as soon as you get to trig
functions.  It's about bounding the error.

    It's possible to do bounded arithmetic, where you carry along an
upper and lower bound on each number.  The problem is what to do
about comparisons.  Comparisons between bounded numbers are
ambiguous when the ranges overlap.  Algorithms have to be designed
to deal with that.  Mathematica has such algorithms for some
operations, especially numerical integration.

    It's a very real issue. I had to deal with this when I was
writing the first "ragdoll physics" system that worked right,
back in the 1990s.  Everybody else's system blew up on the hard
cases; mine just slowed down.  Correct integration over a force
function that's changing over 18 orders of magnitude is difficult,
but quite possible.

(Here it is, from 1997: "http://www.youtube.com/watch?v=5lHqEwk7YHs")
(A test with a heavy object:
"http://www.youtube.com/watch?v=-DaWIHc1VLY".  Most physics engines
don't do heavy objects well. Everything looks too light. We call
this the "boink problem.")

				John Nagle



More information about the Python-list mailing list