Re: [Rd] Computing means, variances and sums

From: Prof Brian Ripley <>
Date: Wed 22 Feb 2006 - 12:27:10 GMT

On Wed, 22 Feb 2006, Duncan Murdoch wrote:

> On 2/22/2006 3:52 AM, Prof Brian Ripley wrote:
>> I've managed to track this down. The setting of the FPU control word on a
>> ix86 machine changes the precision of (gcc) long double calculations in the
>> FPU, as well as those of double. So if it gets changed to PC_53, long
>> doubles lose accuracy even though 10 bytes are carried around.
>> For some discussion of extended-precision issues, see Priest's annex to
>> Goldberg's paper at
>> Many other OSes other than Windows on ix86 do consider the FPU control word
>> when doing context-switching. There is (often heated) debate as to what
>> the correct default should be, see e.g. the thread begining
> I think Windows also preserves the FPU control word across context switches.
> The problem is that it doesn't do a context switch when you make a call into
> the system. In particular, the shell services (file dialogs, URL
> recognition, etc.) involve a large number of DLLs, all running within the
> same context. MSVC++ normally chooses 53 bit precision as the default, and
> will set that when a DLL starts up, or whenever a function in it asks to
> reset the FPU.

Yes, I think you are correct. In that case the difference is that it is considered legitimate for a shared resource (a DLL) to change the control word in the context that initializes it.

Since as I understand it Win64 does not have a working controlfp nor the ability to change precision (from in its native mode, maybe one day this will go away.

Brian Ripley

Brian D. Ripley,        
Professor of Applied Statistics,
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

______________________________________________ mailing list
Received on Wed Feb 22 23:45:06 2006

This archive was generated by hypermail 2.1.8 : Wed 22 Feb 2006 - 19:30:50 GMT