<br><br><div><span class="gmail_quote">On 1/28/07, <b class="gmail_sendername">Keith Goodman</b> <<a href="mailto:kwgoodman@gmail.com">kwgoodman@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 1/27/07, Keith Goodman <<a href="mailto:kwgoodman@gmail.com">kwgoodman@gmail.com</a>> wrote:<br>> On 1/27/07, Fernando Perez <<a href="mailto:fperez.net@gmail.com">fperez.net@gmail.com</a>> wrote:<br>> > It's definitely looking like something SMP related: on my laptop, with
<br>> > everything other than the hardware being identical (Linux distro,<br>> > kernel, numpy build, etc), I can't make it fail no matter how I muck<br>> > with it.  I always get '0 differences'.
<br>> ><br>> > The desktop is a dual-core AMD Athlon as indicated before, the laptop<br>> > is an oldie Pentium III.  They both run the same SMP-aware Ubuntu i686<br>> > kernel, since Ubuntu now ships a unified kernel, though obviously on
<br>> > the laptop the SMP code isn't active.<br>><br>> After installing a kernel that is not smp aware, I still have the same problem.<br><br>The problem goes away if I remove atlas (atlas3-sse2 for me). But that
<br>just introduces another problem: slowness.<br><br>So is this something to report to Clint Whaley? Or does it have to do<br>with how numpy uses atlas?</blockquote><div><br><br>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.
<br>
<br>How come your computation is so sensitive to these small effects? <br><br>Chuck<br> </div></div><br>