Python fails on math

[John Nagle]

On 2/22/2011 9:59 AM, Roy Smith wrote:
> In article<ik0rmr$ck4$1 at reader1.panix.com>,
>   Grant Edwards<invalid at invalid.invalid>  wrote:
>
>> Python doesn't do equations.  Python does floating point operations.
>
> More generally, all general-purpose programming languages have the same
> problem.  You'll see the same issues in Fortran, C, Java, Ruby, Pascal,
> etc, etc.

     Not quite.  CPython has the problem that it "boxes" its floating 
point numbers.  After each operation, the value is stored back into
a 64-bit space.

     The IEEE 754 compliant FPU on most machines today, though, has
an 80-bit internal representation.  If you do a sequence of
operations that retain all the intermediate results in the FPU
registers, you get 16 more bits of precision than if you store
after each operation.   Rounding occurs when the 80-bit value is
forced back to 64 bits.

     So it's quite possible that this would look like an equality
in C, or ShedSkin, or maybe PyPy (which has some unboxing
optimizations) but not in CPython.

     (That's not the problem here, of course.  The problem is that
the user doesn't understand floating point.  The issues I'm talking
about are subtle, and affect few people.  Those of us who've had
to worry about this and read Kahan's papers are typically developers
of simulation systems, where cumulative error can be a problem.
In the 1990s, I had to put a lot of work into this for collision
detection algorithms for a physics engine.  As two objects settle
into contact, issues with tiny differences between large numbers
start to dominate.  It takes careful handling to prevent that from
causing high frequency simulated vibration in the simulation,
chewing up CPU time at best and causing simulations to fly apart
at worst.  The problems are understood now, but they weren't in
the mid-1990s.  The licensed Jurassic Park game "Trespasser" was a flop
for that reason.)

				John Nagle