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 (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 -- http://mail.python.org/mailman/listinfo/python-list