[Numpy-discussion] Different results from repeated calculation
Charles R Harris
charlesr.harris at gmail.com
Sun Jan 28 13:10:55 EST 2007
On 1/28/07, Keith Goodman <kwgoodman at gmail.com> wrote:
> On 1/28/07, Fernando Perez <fperez.net at gmail.com> wrote:
> > On 1/28/07, Charles R Harris <charlesr.harris at gmail.com> wrote:
> > > > The problem goes away if I remove atlas (atlas3-sse2 for me). But
> > > > just introduces another problem: slowness.
> > > >
> > > > So is this something to report to Clint Whaley? Or does it have to
> > > > with how numpy uses atlas?
> > >
> > >
> > > Interesting, I wonder if ATLAS is resetting the FPU flags and changing
> > > rounding mode? It is just the LSB of the mantissa that looks to be
> > > changing. Before reporting the problem it might be good to pin it down
> a bit
> > > more if possible.
> > Well, the fact that I don't see the problem on a PentiumIII (with
> > atlas-sse) but I see it on my desktop (atlas-sse2) should tell us
> > something. The test code uses double arrays, and SSE2 has double
> > precision support but it's purely 64-bit doubles. SSE is
> > single-precision only, which means that for a double computation,
> > ATLAS isn't used and the Intel FPU does the computation instead.
> > Intel FPUs use 80 bits internally for intermediate operations (even
> > though they only return a normal 64-bit double result), so it's fairly
> > common to see this kind of thing.
> Removing ATLAS SSE2 does fix the problem. But why does test1 pass when
> ATLAS SSE2 is present?
It is strange, isn't it. I'm still thinking race condition, but where? I
suppose even python could be involved someplace.
BTW, your algorithm sounds like a great way to expose small descrepancies.
There's a great test for floating point errors lurking in there.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion