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 g
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 accura
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 d
On 2/19/2006 3:18 PM, Prof Brian Ripley wrote:
> On Sun, 19 Feb 2006, hadley wickham wrote:
>
>>> p.s. If my computations are correct, 0.2 = 0*/2 + 0/4 + 1/8 + 1/16 +
>>> 0/32 + 0/64 + 1/128 + 1/256 + 0/512 + 0/1024 + 1/2048 + 1/4096 + ... =
>>> 0.3h. Perhaps someone can extend this
On Sun, 19 Feb 2006, hadley wickham wrote:
>> p.s. If my computations are correct, 0.2 = 0*/2 + 0/4 + 1/8 + 1/16 +
>> 0/32 + 0/64 + 1/128 + 1/256 + 0/512 + 0/1024 + 1/2048 + 1/4096 + ... =
>> 0.3h. Perhaps someone can extend this to an FAQ to help
>> explain finite precision arithmet
As I have said before on R-help, it is _already_ fixed in this (and
related cases) and the reasons it is fixed were explained here. If you
read carefully, you will have noticed that some platforms (such as Sparc)
only use 53 bits (+ a guard bit).
Not that I accept that the 53-bit calculation i
> p.s. If my computations are correct, 0.2 = 0*/2 + 0/4 + 1/8 + 1/16 +
> 0/32 + 0/64 + 1/128 + 1/256 + 0/512 + 0/1024 + 1/2048 + 1/4096 + ... =
> 0.3h. Perhaps someone can extend this to an FAQ to help
> explain finite precision arithmetic and rounding issues.
This is drifting a bit
Dear Professors Ripley & Murdoch, & others:
If this were just an issue of computations like var(rep(0.02, 10))
producing something other than 0 on certain platforms (e.g.,
combinations of operating systems and microprocessors), then I would
suggest it be documented as an FAQ and left
There has been a recent thread on R-help on this, which resurrected
concepts from bug reports PR#1228 and PR#6743. Since the discussion has
included a lot of erroneous 'information' based on misunderstandings of
floating-point computations, this is an attempt to set the record straight
and exp
