Python fails on math

[Grant Edwards]

On 2011-02-25, Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:

>> C double *variables* are, but as John suggests, C compilers are allowed
>> (to my knowledge) to keep intermediate results of an expression in the
>> larger-precision FPU registers. The final result does get shoved back
>> into a 64-bit double when it is at last assigned back to a variable or
>> passed to a function that takes a double.
>
> So...
>
> (1) you can't rely on it, because it's only "allowed" and not mandatory;
>
> (2) you may or may not have any control over whether or not it happens;
>
> (3) it only works for calculations that are simple enough to fit in a 
>     single expression; and

(3) is sort of an interesting one.

If a C compiler could elminate stores to temporary variables (let's
say inside a MAC loop) it might get a more accurate result by leaving
temporary results in an FP register.  But, IIRC the C standard says
the compiler can only eliminate stores to variables if it doesn't
change the output of the program.  So I think the C standard actually
forces the compiler to convert results to 64-bits at the points where
a store to a temporary variable happens.  It's still free to leave the
result in an FP register, but it has to toss out the extra bits so
that it gets the same result as it would have if the store/load took
place.

> (4) we could say the same thing about Python -- there's no
>     prohibition on Python using extended precision when performing
>     intermediate results, so it too could be said to be "allowed".

Indeed.  Though C-python _will_ (AFAIK) store results to variables
everywhere the source code says to, and C is allowed to skip those
stores, C is still required to produce the same results as if the
store had been done.

IOW, I don't see that there's any difference between Python and C
either.

-- 
Grant