On Dec 12, 2007 4:20 AM, Jarrod Millman [EMAIL PROTECTED] wrote:
I will put new binaries on the sourceforge site this weekend for both
NumPy 1.0.4 and SciPy 0.6.0. I should be able to find an old PIII
WinXP machine around somewhere, which I will devote to building the
official non-SSE2
On Dec 11, 2007 5:58 PM, Fernando Perez [EMAIL PROTECTED] wrote:
On Dec 11, 2007 6:45 PM, Ryan Krauss [EMAIL PROTECTED] wrote:
Near as I can tell, this is still unresolved for people with non-sse2
machines. Is that right?
Yup. Your more detailed testing seems to confirm the hunch I had at
I will put new binaries on the sourceforge site this weekend for both
NumPy 1.0.4 and SciPy 0.6.0. I should be able to find an old PIII
WinXP machine around somewhere, which I will devote to building the
official non-SSE2 releases from here on out.
Great, many thanks!
Keep in mind that as
Fernando Perez wrote:
I will put new binaries on the sourceforge site this weekend for both
NumPy 1.0.4 and SciPy 0.6.0. I should be able to find an old PIII
WinXP machine around somewhere, which I will devote to building the
official non-SSE2 releases from here on out.
Great, many
On Dec 11, 2007 3:16 PM, Fernando Perez [EMAIL PROTECTED] wrote:
On Dec 10, 2007 11:04 PM, David Cournapeau [EMAIL PROTECTED] wrote:
On Dec 11, 2007 12:46 PM, Andrew Straw [EMAIL PROTECTED] wrote:
According to the QEMU website, QEMU does not (yet) emulate SSE on x86
target, so a Windows
binary for numpy
1.0.4 for windows ?
Andrew Straw wrote:
A function
could be called at numpy import time that specifically checks for the
instruction set on the CPU running
Even better would be a run-time selection of the best version. I've
often fantasized about an ATLAS that could do
On Dec 11, 2007 8:47 PM, Albert Strasheim [EMAIL PROTECTED] wrote:
Hello
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
At 02:32 AM 12/11/2007, you wrote:
If so I'd be happy to contribute part of the purchase price,
and I assume others would too.
What's more, I *have* an old PIII at home.
The main company I consult for is set to buy the Intel compiler and
FFT lib for Windows, for the express purpose of compiling
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
On Dec 12, 2007 3:04 AM, Christopher Barker [EMAIL PROTECTED] wrote:
Fernando Perez wrote:
a simple, reasonable solution that is likely to work: ship TWO
binaries of Numpy/Scipy each time:
1. {numpy,scipy}-reference: built with the reference blas from netlib,
no atlas, period.
2.
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
Hello all,
I'm not sure the licensing really makes it possible though. Numpy isn't
exactly an application, but rather a development tool, so I'm not sure
how Intel would feel about it being distributed. Also, it looks like
they require each developer to have license, rather than only the
Hi,
Several people reported problems with numpy 1.0.4 (See #627 and
#628, but also other problems mentionned on the ML, which I cannot
find). They were all solved, as far as I know, by a binary I produced
(simply using mingw + netlib BLAS/LAPACK, no ATLAS). Maybe it would be
good to use
On Dec 10, 2007 6:48 AM, David Cournapeau [EMAIL PROTECTED] wrote:
Hi,
Several people reported problems with numpy 1.0.4 (See #627 and
#628, but also other problems mentionned on the ML, which I cannot
find). They were all solved, as far as I know, by a binary I produced
(simply using
2007/12/10, Alexander Michael [EMAIL PROTECTED]:
On Dec 10, 2007 6:48 AM, David Cournapeau [EMAIL PROTECTED]
wrote:
Hi,
Several people reported problems with numpy 1.0.4 (See #627 and
#628, but also other problems mentionned on the ML, which I cannot
find). They were all solved,
On Dec 10, 2007, at 10:30 , Matthieu Brucher wrote:
2007/12/10, Alexander Michael [EMAIL PROTECTED]: On Dec 10, 2007
6:48 AM, David Cournapeau [EMAIL PROTECTED] wrote:
Hi,
Several people reported problems with numpy 1.0.4 (See #627 and
#628, but also other problems mentionned on
On Dec 10, 2007 10:59 PM, Alexander Michael [EMAIL PROTECTED] wrote:
On Dec 10, 2007 6:48 AM, David Cournapeau [EMAIL PROTECTED] wrote:
Hi,
Several people reported problems with numpy 1.0.4 (See #627 and
#628, but also other problems mentionned on the ML, which I cannot
find). They
David M. Cooke wrote:
On Dec 10, 2007, at 10:30 , Matthieu Brucher wrote:
2007/12/10, Alexander Michael [EMAIL PROTECTED]: On Dec 10, 2007
6:48 AM, David Cournapeau [EMAIL PROTECTED] wrote:
Hi,
Several people reported problems with numpy 1.0.4 (See #627 and
#628, but also other
On Dec 10, 2007 4:41 PM, Robert Kern [EMAIL PROTECTED] wrote:
The current situation is untenable. I will gladly accept a slow BLAS for an
official binary that won't segfault anywhere. We can look for a faster BLAS
later.
Just to add a note to this: John Hunter and I just finished teaching a
An idea that occurred to me after reading Fernando's email. A function
could be called at numpy import time that specifically checks for the
instruction set on the CPU running and makes sure that is completely
covers the instruction set available through all the various calls,
including to BLAS.
Fernando Perez wrote:
On Dec 10, 2007 4:41 PM, Robert Kern [EMAIL PROTECTED] wrote:
The current situation is untenable. I will gladly accept a slow BLAS for an
official binary that won't segfault anywhere. We can look for a faster BLAS
later.
Just to add a note to this: John
According to the QEMU website, QEMU does not (yet) emulate SSE on x86
target, so a Windows installation on a QEMU virtual machine may be a
good way to build binaries free of these issues.
http://fabrice.bellard.free.fr/qemu/qemu-tech.html
-Andrew
Travis E. Oliphant wrote:
Fernando Perez wrote:
This may be a naive question, but just to be sure...
If troubles building without SSE2 support on an SSE2
processor are the problem, withould the problem be addressed
by purchasing an old PIII like
Andrew Straw wrote:
A function
could be called at numpy import time that specifically checks for the
instruction set on the CPU running
Even better would be a run-time selection of the best version. I've
often fantasized about an ATLAS that could do this.
I think the Intel MKL has this
On Dec 11, 2007 11:03 AM, Fernando Perez [EMAIL PROTECTED] wrote:
On Dec 10, 2007 4:41 PM, Robert Kern [EMAIL PROTECTED] wrote:
The current situation is untenable. I will gladly accept a slow BLAS for an
official binary that won't segfault anywhere. We can look for a faster BLAS
later.
On Dec 11, 2007 11:59 AM, Andrew Straw [EMAIL PROTECTED] wrote:
An idea that occurred to me after reading Fernando's email. A function
could be called at numpy import time that specifically checks for the
instruction set on the CPU running and makes sure that is completely
covers the
On Dec 11, 2007 12:46 PM, Andrew Straw [EMAIL PROTECTED] wrote:
According to the QEMU website, QEMU does not (yet) emulate SSE on x86
target, so a Windows installation on a QEMU virtual machine may be a
good way to build binaries free of these issues.
On Dec 10, 2007 11:04 PM, David Cournapeau [EMAIL PROTECTED] wrote:
On Dec 11, 2007 12:46 PM, Andrew Straw [EMAIL PROTECTED] wrote:
According to the QEMU website, QEMU does not (yet) emulate SSE on x86
target, so a Windows installation on a QEMU virtual machine may be a
good way to build
28 matches
Mail list logo
