On 01/-10/-28163 02:59 PM, Grant Edwards wrote:
On 2011-02-25, Steven D'Aprano<steve+comp.lang.pyt...@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
--
http://mail.python.org/mailman/listinfo/python-list
