On 1/28/07, Fernando Perez <[EMAIL PROTECTED]> wrote:
On 1/28/07, Charles R Harris <[EMAIL PROTECTED]> wrote: > > The problem goes away if I remove atlas (atlas3-sse2 for me). But that > > just introduces another problem: slowness. > > > > So is this something to report to Clint Whaley? Or does it have to do > > with how numpy uses atlas? > > > Interesting, I wonder if ATLAS is resetting the FPU flags and changing the > 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.
But how come it isn't consistent and seems to depend on timing? That is what makes me think there is a race somewhere in doing something, like setting flags . I googled yesterday for floating point errors and didn't find anything that looked relevant. Maybe I should try again with the combination of atlas and sse2. Chuck
_______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
