glob2-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [glob2-devel] Nicowar and desync


From: Cyrille Dunant
Subject: Re: [glob2-devel] Nicowar and desync
Date: Wed, 19 Jul 2006 19:53:21 +0200
User-agent: KMail/1.9.3

On Wednesday 19 July 2006 19:41, Bradley Arsenault wrote:
> On 7/18/06, Cyrille Dunant <address@hidden> wrote:
> > It is _not_ the compiler, it is the hardware. read the IEEE 754 norm.
> >
> > CU
> >
> >  -- CFD
> >
> >
> > _______________________________________________
> > glob2-devel mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/glob2-devel
>
> Right after you mentioned mantissa, I went out and researched the
> float standard, which mentioned nothing of initialization. The

No, but it does mention what happens to the last bits stored in the cpu. 
Specifically, it mentions they can be anything at all. Because your 32 bit 
number is really stored on 80 bits. Because the CPU builders assume that the 
margin will be sufficient. It is. Sometimes.

> compiler compiles code that initializes a number, I still see no
> reason that a number would be left unitialized. 

because it is time consuming ? and irrelevant anyway.

> Anyway, that page you 
> gave me is about accumulated error, and he does it over a billion
> values.

Yes, true, but the problem is that the errors accumulate because the values 
were wrong from the start.

> Its fairly good that most computers are less then a 10'th off 
> (in my opponion)

It is actually catastrophic. For all sorts of applications, this simply kills 
you. Think numerics with unstable algorithms.

Think also that this error means that quite a few bits have been jumbled in 
all directions. And that you cannot depend on two doubles or floats being 
equal. Ever.

Because the compared values are those produced from the truncature of the 
actual number stored in the CPU. And the truncature can happen however the 
builder thought appropriate at the time. Which might mean he chose a 
"systematically wrong" algorithm (this is allowed in the spec).

> Anyway, I don't feel like arguing this, I have no intention of not
> fixing my code, machine-machine is still unsafe.

and computing with ints is faster anyway, if the resolution suffices.

CU

 -- CFD




reply via email to

[Prev in Thread] Current Thread [Next in Thread]