Does anyone have a guide on how to get numpy to use the ACML as its
blas/lapack backend?
-gideon
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Would anyone be willing to help me interpret an error while trying to
build and install Numpy? I've searched around, and haven't seen this
elsewhere.
I've been running into this wall for about half the day now. I've
tried reinstalling Python, using numpy 1.2.0 and 1.2.1.
I have Python
You have setup.cfg:
* set add the directory where acml libraries reside to the library dir path list
* add acmllibraries under blas and lapack sections
Nadav
-הודעה מקורית-
מאת: numpy-discussion-boun...@scipy.org בשם Gideon Simpson
נשלח: ש 24-ינואר-09 18:21
אל: Discussion of Numerical
Nadav-
That doesn't quite seem to work for me. I added:
[blas_opt]
library_dirs = /usr/local/nonsystem/simpson/acml4.2.0/gfortran64/lib
include_dirs = /usr/local/nonsystem/simpson/acml4.2.0/gfortran64/include
libraries = acml
[lapack_opt]
library_dirs =
Hi,
I just discovered a new whohas command in Debian, that can show a
package in virtually all important distributions (Arch, Debian,
Fedora, Gentoo, openSUSE, Slackware (and
linuxpackages.net), Source Mage, Ubuntu, FreeBSD, NetBSD, OpenBSD,
Fink and MacPorts distributions).
So for example
Sat, 24 Jan 2009 15:26:17 -0500, Gideon Simpson wrote:
Nadav-
That doesn't quite seem to work for me. I added:
[blas_opt]
library_dirs = /usr/local/nonsystem/simpson/acml4.2.0/gfortran64/lib
include_dirs = /usr/local/nonsystem/simpson/acml4.2.0/gfortran64/include
libraries = acml
On 2009-01-24, at 11:34 AM, Nat Wilson wrote:
Would anyone be willing to help me interpret an error while trying to
build and install Numpy? I've searched around, and haven't seen this
elsewhere.
I've been running into this wall for about half the day now. I've
tried reinstalling Python,
I had not, but that doesn't seem to make any difference. By the way,
I'm using gfortran 4.2.3 as I do this.
Nat
On Jan 24, 2009, at 4:38 PM, John Gleeson wrote:
On 2009-01-24, at 11:34 AM, Nat Wilson wrote:
Would anyone be willing to help me interpret an error while trying to
build and
Nat Wilson wrote:
Would anyone be willing to help me interpret an error while trying to
build and install Numpy? I've searched around, and haven't seen this
elsewhere.
I've been running into this wall for about half the day now. I've
tried reinstalling Python, using numpy 1.2.0 and
I've tried building CBLAS, which seems to run properly by itself, but
numpy is still having difficulty. I've got the following in my
site.cfg:
[blas_opt]
library_dirs = /usr/local/nonsystem/simpson/CBLAS/lib/LINUX:/usr/local/
nonsystem/simpson/acml4.2.0/gfortran64/lib
include_dirs =
Pierre,
I've found what I consider to be a bug in the new mafromtxt (though apparently
it
existed in earlier versions as well). If you have an entire column of data in a
file that contains only masked data, and try to get mafromtxt to automatically
choose the dtype, the dtype gets selected to
On Sat, Jan 24, 2009 at 12:34, Nat Wilson njwilso...@gmail.com wrote:
Would anyone be willing to help me interpret an error while trying to
build and install Numpy? I've searched around, and haven't seen this
elsewhere.
File /Library/Frameworks/Python.framework/Versions/2.6/lib/
Ryan,
Thanks for reporting. An idea would be to force the dtype of the
masked column to the largest dtype of the other columns (in your
example, that would be int). I'll try to see how easily it can be done
early next week. Meanwhile, you can always give an explicit dtype at
creation.
On
I did manage to get it working.
I remember that both libcblas.a (or a link to it) and libacml.so had
to be in the same directory.
Also I had to comment out lines 399-400 of setup.py:
# if ('NO_ATLAS_INFO',1) in blas_info.get('define_macros',[]):
# return None # dotblas
Pierre GM wrote:
Ryan,
Thanks for reporting. An idea would be to force the dtype of the
masked column to the largest dtype of the other columns (in your
example, that would be int). I'll try to see how easily it can be done
early next week. Meanwhile, you can always give an explicit
That's not working for me. Any thoughts on how to troubleshoot it?
-gideon
On Jan 24, 2009, at 6:18 PM, George Nurser wrote:
I did manage to get it working.
I remember that both libcblas.a (or a link to it) and libacml.so had
to be in the same directory.
Also I had to comment out lines
Ah, no, I can't import it.
What does this mean? As far as I know, I built Python as instructed.
Python 2.6.1 (r261:67515, Jan 24 2009, 16:08:37)
[GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin
Type help, copyright, credits or license for more information.
from random import
On Sat, Jan 24, 2009 at 17:58, Nat Wilson njwilso...@gmail.com wrote:
Ah, no, I can't import it.
What does this mean? As far as I know, I built Python as instructed.
I'm not sure. Can you show me what os.urandom(16) gives you?
--
Robert Kern
I have come to believe that the whole world is an
It throws this out.
Python 2.6.1 (r261:67515, Jan 24 2009, 16:08:37)
[GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin
Type help, copyright, credits or license for more information.
import os
os.urandom(16)
'\xe0;n\x8a*\xb4\x08N\x80\xef\x9b*\x06\x1b\xc4'
Nat
On Jan 24,
On Sat, Jan 24, 2009 at 18:31, Nat Wilson njwilso...@gmail.com wrote:
It throws this out.
Python 2.6.1 (r261:67515, Jan 24 2009, 16:08:37)
[GCC 4.0.0 20041026 (Apple Computer, Inc. build 4061)] on darwin
Type help, copyright, credits or license for more information.
import os
To be honest, I really don't know. I followed the directions in /Mac/
README for a framework install.
How would I check this?
Thanks a lot for sticking with me,
Nat
On Jan 24, 2009, at 7:41 PM, Robert Kern wrote:
On Sat, Jan 24, 2009 at 18:31, Nat Wilson njwilso...@gmail.com
wrote:
It
On Sat, Jan 24, 2009 at 19:13, Nat Wilson njwilso...@gmail.com wrote:
To be honest, I really don't know. I followed the directions in /Mac/
README for a framework install.
How would I check this?
Rebuild and look at the compiler command lines as they go by.
--
Robert Kern
I have come to
Having built an up to date lapack and ATLAS against gcc 4.3.2, I tried
installing numpy 1.2.1 on Python 2.5.4. When testing I get:
Python 2.5.4 (r254:67916, Jan 24 2009, 00:27:20)
[GCC 4.3.2] on linux2
Type help, copyright, credits or license for more information.
import numpy
numpy.test()
Gideon Simpson wrote:
Having built an up to date lapack and ATLAS against gcc 4.3.2, I tried
installing numpy 1.2.1 on Python 2.5.4. When testing I get:
Python 2.5.4 (r254:67916, Jan 24 2009, 00:27:20)
[GCC 4.3.2] on linux2
Type help, copyright, credits or license for more information.
Not sure what the problem is in your case, but I had the same error a
while back. For some reason, ATLAS thought it should be compiled as
64 bit but numpy as 32 bit. . It went away after I passed the -b 32
flag to configure in ATLAS (I think). Thus that's one thing to check.
Also, make sure
Hoyt Koepke wrote:
Not sure what the problem is in your case, but I had the same error a
while back. For some reason, ATLAS thought it should be compiled as
64 bit but numpy as 32 bit. . It went away after I passed the -b 32
flag to configure in ATLAS (I think). Thus that's one thing to
Rerunning the tests with verbosity, it dies at:
test_single (test_linalg.TestSolve) ... ok
Ticket #652 ... *** glibc detected *** python: free(): invalid next
size (fast): 0x01e284e0 ***
I'm using ATLAS 3.8.2 and lapack 3.2. ATLAS and lapack were all built
with the -m64 flag.
Gideon Simpson wrote:
Rerunning the tests with verbosity, it dies at:
test_single (test_linalg.TestSolve) ... ok
Ticket #652 ... *** glibc detected *** python: free(): invalid next
size (fast): 0x01e284e0 ***
I'm using ATLAS 3.8.2 and lapack 3.2.
Lapack 3.2 may be the
28 matches
Mail list logo