[Numpy-discussion] Changing the distributed binary for numpy 1.0.4 for windows ?

[Ryan Krauss]

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 <robert.kern at gmail.com> wrote:
> David Cournapeau wrote:
> > On Dec 12, 2007 2:58 AM, Christopher Barker <Chris.Barker at noaa.gov> 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 at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>