Python fails on math

[Heather Brown]

On 01/-10/-28163 02:59 PM, Grant Edwards wrote:
> 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
>
>   <snip>
>

In 1975, I was writing the arithmetic and expression handling for an 
interpreter.  My instruction primitives could add two bytes;  anything 
more complex was done in my code.  So I defined a floating point format 
(decimal, of course) and had extended versions of it available for 
intermediate calculations.  I used those extended versions, in logs for 
example, whenever the user of our language could not see the 
intermediate results.

When faced with the choice of whether to do the same inside explicit 
expressions, like  (a*b) - (c*d), I deliberately chose *not* to do such 
optimizations, in spite of the fact that it would improve both 
performance and (sometimes) accuracy.

I wrote down my reasons at the time, and they had to do with 'least 
surprise."  If a computation for an expression gave a different result 
than the same one decomposed into separate variables, the developer 
would have a hard time knowing when results might change, and when they 
might not.  Incidentally, the decimal format also assured "least 
surprise," since the times when quantization error entered in were 
exactly the same times as if one were doing the calculation by hand.

I got feedback from a customer who was getting errors in a complex 
calculation (involving trig), and wanted help in understanding why. 
While his case might have been helped by intermediate values having 
higher accuracy, the real solution was to reformulate the calculation to 
avoid subtracting two large numbers that differed by very little.  By 
applying a little geometry before writing the algorithm, I was able to 
change his accuracy from maybe a millionth of an inch to something 
totally unmeasurable.

I still think the choice was appropriate for a business language, if not 
for scientific use.

DaveA