[Top][All Lists]
[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
- [glob2-devel] Nicowar and desync, Stéphane Magnenat, 2006/07/16
- Re: [glob2-devel] Nicowar and desync, Bradley Arsenault, 2006/07/16
- Re: [glob2-devel] Nicowar and desync, Stéphane Magnenat, 2006/07/18
- Re: [glob2-devel] Nicowar and desync, Cyrille Dunant, 2006/07/18
- Re: [glob2-devel] Nicowar and desync, Bradley Arsenault, 2006/07/18
- Re: [glob2-devel] Nicowar and desync, Cyrille Dunant, 2006/07/18
- Re: [glob2-devel] Nicowar and desync, Bradley Arsenault, 2006/07/18
- Re: [glob2-devel] Nicowar and desync, Bradley Arsenault, 2006/07/18
- Re: [glob2-devel] Nicowar and desync, Cyrille Dunant, 2006/07/18
- Re: [glob2-devel] Nicowar and desync, Bradley Arsenault, 2006/07/19
- Re: [glob2-devel] Nicowar and desync,
Cyrille Dunant <=
- Re: [glob2-devel] Nicowar and desync, Bradley Arsenault, 2006/07/19
- Re: [glob2-devel] Nicowar and desync, Cyrille Dunant, 2006/07/18