Near as I can tell, this is still unresolved for people with non-sse2 machines. Is that right?
I have a student trying to get started with such a machine. Numpy is causing Python to crash. What is the easiest solution? Does he need to build numpy from source on that machine (I actually still have access to one and could do it)? Is it just Numpy or also Scipy? Here is his responses to me: Laptop - Ok Windows XP Professional, Service Pack 2 AMD Athlon 64 3400+ (ClawHammer) 1.67 GHz, 768 MB of RAM Chipset: SiS 755/755FX Southbridge: SiS LPC Bridge Instructions: MMX (+), 3DNow! (+), SSE, SSE2, x86-64 Machine 1 - Crashes Windows XP Professional, Service Pack 2 AMD Athlon XP 2000+ (Thoroughbred) 1.67 GHz, 768 MB of RAM ASUS A7V8X-X motherboard Chipset: VIA KT400 (VT8377) Southbridge: VIA VT8235 Instructions: MMX (+), 3DNow! (+), SSE Machine 2 - Crashes Windows XP Professional, Service Pack 2 AMD Athlon XP 2600+ (Barton) 1.92 GHz, 2.0 GB of RAM ASUS A7V880 motherboard Chipset: VIA KT880 Southbridge: VIA VT8237 Instructions: MMX (+), 3DNow! (+), SSE I ran the following statements on both machines which caused it to crash: import numpy numpy.test() Here is the output: Numpy is installed in C:\Python25\lib\site-packages\numpy Numpy version 1.0.4 Python version 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Int el)] Found 10/10 tests for numpy.core.defmatrix Found 36/36 tests for numpy.core.ma Found 223/223 tests for numpy.core.multiarray Found 65/65 tests for numpy.core.numeric Found 31/31 tests for numpy.core.numerictypes Found 12/12 tests for numpy.core.records Found 6/6 tests for numpy.core.scalarmath Found 14/14 tests for numpy.core.umath Found 4/4 tests for numpy.ctypeslib Found 5/5 tests for numpy.distutils.misc_util Found 1/1 tests for numpy.fft.fftpack Found 3/3 tests for numpy.fft.helper Found 9/9 tests for numpy.lib.arraysetops Found 46/46 tests for numpy.lib.function_base Found 5/5 tests for numpy.lib.getlimits Found 4/4 tests for numpy.lib.index_tricks Found 3/3 tests for numpy.lib.polynomial Found 49/49 tests for numpy.lib.shape_base Found 15/15 tests for numpy.lib.twodim_base Found 43/43 tests for numpy.lib.type_check Found 1/1 tests for numpy.lib.ufunclike Found 40/40 tests for numpy.linalg Found 2/2 tests for numpy.random Found 0/0 tests for __main__ ................................................................................ ................................................................................ ................................................................................ ................................................................................ ..................................... Sounds like the problem is the fact that my desktop computers do not support SSE2 instructions which are in the latest numpy binaries. This also explains why it works fine on the laptop which does support SSE2. On Dec 11, 2007 6:48 PM, Robert Kern <[EMAIL PROTECTED]> wrote: > David Cournapeau wrote: > > On Dec 12, 2007 2:58 AM, Christopher Barker <[EMAIL PROTECTED]> wrote: > >> David Cournapeau wrote: > >>>> I think this idea is the way to go (maybe along with an ACML build, but > >>>> my > >>>> limited testing seemed to indicate that MKL works on AMD CPUs). > >>>> > >>> I am personally totally against it. It is one thing to support > >>> proprietary software, that's quite another to build our official > >>> binaries against it. I consider myself far from any kind of open > >>> source zealot, but that would be crossing a line I would much prefer > >>> avoiding to cross. > >> Interesting -- I DO consider myself a kind of Open Source Zealot -- and > >> this doesn't bother me a bit. > >> > >> It would bother me a LOT if numpy could only be built against this lib, > >> and not an Open Source one -- but I don't see this as any different than > >> providing a binary built with the Microsoft compiler. > >> > > For me it is: when using a MS compiler, you are not forcing people to > > use a non open source product (except maybe the C runtime). What will > > happen if we offer binaries using MKL ? The ATLAS will not be tested > > anymore on windows, it forces every developer to use the MKL to > > support it.... At least, now, with atlas problems, I can reproduce the > > problems. With the MKL, not so much. > > I agree. The official-official Win32 binaries > (numpy-<version>-py<pyversion>.msi > and numpy-<version>-py<pyversion>-win32.egg on the SourceForge donwload page) > should be unencumbered. Other versions can be on the download page, too, but > they should be named differently, like numpy-mkl-<version>-... . > > -- > Robert Kern > > "I have come to believe that the whole world is an enigma, a harmless enigma > that is made terrible by our own mad attempt to interpret it as though it had > an underlying truth." > -- Umberto Eco > _______________________________________________ > > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://projects.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion