[Numpy-discussion] numpy.dot and ACML
Hi all, I have managed to compile numpy using pathscale and ACML on a 64 bit AMD system. Now I wanted to verify that numpy.dot indeed uses the ACML libs. The example for dot() (http://www.scipy.org/Numpy_Example_List?highlight=%28example%29#head-c7a573f030ff7cbaea62baf219599b3976136bac) suggest a way of doing this: 1 [EMAIL PROTECTED] .../core $ python -c "import numpy; print id(numpy.dot)==id(numpy.core.multiarray.dot);" True This indicates that I am not using the acml libraries. When running a benchmark (see attach) and comparing to a non-ACML installation though, the strange thing is that there is a clear speed difference, suggesting again that the acml libraries are indeed used. Because this is not all that clear to me, I was wondering whether there exists an alternative way of verifying what libraries are used. Many thanks, YVES ACML: dimx.T*yx*y.T A*xA*BA.T*x - 5000 0.002492 0.002417 0.002412 0.002399 0.002416 5 0.020074 0.020024 0.020004 0.020003 0.020024 10 0.092777 0.093690 0.100220 0.093787 0.094250 20 0.184933 0.198623 0.196120 0.197089 0.197273 30 0.276583 0.279177 0.280898 0.284016 0.276204 50 0.476340 0.481987 0.471875 0.480868 0.481501 100.0 0.892623 0.895500 0.915173 0.894815 0.922501 500.0 4.450555 4.465748 4.467870 4.468188 4.469083 No ACML: dimx.T*yx*y.T A*xA*BA.T*x - 5000 0.002523 0.002428 0.002410 0.002430 0.002419 5 0.024756 0.061520 0.036575 0.036399 0.036450 10 0.338576 0.353074 0.169472 0.302087 0.334633 20 0.670803 0.735732 0.538166 0.649335 0.744496 30 1.004381 1.269259 0.482542 2.194308 0.611997 50 1.110656 1.504701 1.571736 1.656021 1.491146 100.0 2.182746 2.234478 2.254645 2.439508 2.537558 500.0 10.878910 16.578266 8.265109 8.905976 17.124400 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Forcing the use of unoptimized blas/lapack even when atlas is present
On Feb 19, 2007, at 11:04 , Robert Kern wrote: > David Cournapeau wrote: >> Hi there, >> >> I am developing a building tool to automatically build the whole >> numpy/scipy/matplotlib set from sources including dependencies, >> and one >> of the problem I got is to force which blas/lapack version to use >> when >> building numpy and scipy. >> I thought that doing a BLAS=blaslib LAPACK=lapacklib python >> setup.config was enough when build numpy, but numpy still wants to >> use >> atlas. I would like to avoid using site.cfg if possible, as I want to >> build everything automatically, > > Set ATLAS=0, I believe. Not quite, you need LAPACK=None BLAS=None (ATLAS=None is only needed if ATLAS is being looked for specifically, i.e., system_info.atlas_info is used instead of system_info.lapack_opt_info in the setup.py. AFAIK, that's only used when debugging ATLAS installs in scipy). -- |>|\/|< /--\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |[EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Forcing the use of unoptimized blas/lapack even when atlas is present
Robert Kern wrote: > David Cournapeau wrote: > >> Hi there, >> >> I am developing a building tool to automatically build the whole >> numpy/scipy/matplotlib set from sources including dependencies, and one >> of the problem I got is to force which blas/lapack version to use when >> building numpy and scipy. >> I thought that doing a BLAS=blaslib LAPACK=lapacklib python >> setup.config was enough when build numpy, but numpy still wants to use >> atlas. I would like to avoid using site.cfg if possible, as I want to >> build everything automatically, >> > > Set ATLAS=0, I believe. > > IIRC, export ATLAS=None should also work. Nils ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Forcing the use of unoptimized blas/lapack even when atlas is present
David Cournapeau wrote: > Hi there, > > I am developing a building tool to automatically build the whole > numpy/scipy/matplotlib set from sources including dependencies, and one > of the problem I got is to force which blas/lapack version to use when > building numpy and scipy. > I thought that doing a BLAS=blaslib LAPACK=lapacklib python > setup.config was enough when build numpy, but numpy still wants to use > atlas. I would like to avoid using site.cfg if possible, as I want to > build everything automatically, Set ATLAS=0, I believe. -- 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
Re: [Numpy-discussion] linalg.eigh orders eigenvalues/eigenvectors differently than linalg.eig
Johannes Loehnert wrote:
> On Monday 19 February 2007 12:06, Sven Schreiber wrote:
>
>> Zachary Pincus schrieb:
>>
>>> Hello all,
>>>
>>> It seems that the 'eigh' routine from numpy.linalg does not follow
>>> the same convention as numpy.linalg.eig in terms of the order of the
>>> returned eigenvalues. (And thus eigenvectors as well...)
>>>
>> I was told on this list that the ordering should not be relied upon, and
>> that it might change in the future. So it seems that user code should
>> explicitly re-order the eigenvalues (and corresponding eigenvectors,
>> probably using argsort and fancy indexing -- if those are the right terms).
>>
>
> Indeed. eig and eigh are wrappers for lapack functions, so the result is
> whatever those give back. Do not rely on a particular order of eigenvalues,
> sort yourself.
>
> Short example for convenience:
> #-
> eigvals, eigvecs = eig(some_matrix)
> ind = argsort(eigvals)
> eigvals = eigvals[ind]
> eigvecs = eigvecs[:, ind] # second axis !!
> # etc.
> #
>
> Johannes
> ___
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
eigh is based on *heev (* placeholder for s,d,c,z)
http://www.netlib.org/lapack/complex16/zheev.f
* W (output) DOUBLE PRECISION array, dimension (N)
* If INFO = 0, the eigenvalues in ascending order.
Apparently the eigenvalues are in ascending order for eigh.
Hence, It would be nice if scipy could offer more wrappers for matrices
with certain properties, e.g.
http://www.netlib.org/lapack/double/dsygv.f
http://www.netlib.org/lapack/double/dsyevr.f
http://www.netlib.org/lapack/double/dsygvx.f
http://www.netlib.org/lapack/double/dstevr.f
Any comments ?
Nils
Also LAPACK3.1 has many improved eigensolvers. Please try suzuki.py with
LAPACK3.0
>>> w_e
array([-200.+0.j, -100.+0.j,
700.00307816+0.00103379j, 700.00307816-0.00103379j,
699.9993562 +0.00318262j, 699.9993562 -0.00318262j,
699.99756564+0.00214883j, 699.99756564-0.00214883j])
versus
LAPACK3.1.
>>> w_e
array([-200.+0.j, -100.+0.j,
699.99891191+0.00188463j, 699.99891191-0.00188463j,
700.00217619+0.j, 700.00294523+0.j,
699.99852738+0.0025507j , 699.99852738-0.0025507j ])
from scipy import *
from pylab import plot, show, xlabel, ylabel, legend, xlim, ylim
import os, sys
os.system("uname -a")
print show_config()
#
# Tomohiro Suzuki and Toshio Suzuki
# An eigenvalue problem for derogatory matrices
# Journal of Computational and Applied Mathematics
# Vol. 199 (2007) pp. 245-250
#
A = array((
[740,115,-305,-170,-45,415,-310,-80],
[10,410,130,220,430,-70,-60,-310],
[-130,-430,410,-60,290,70,220,110],
[-380,45,185,390,-115,-215,-170,-220],
[60,10,430,270,550,350,-150,100],
[380,210,-210,170,210,410,30,-220],
[-170,255,115,-240,375,275,600,-150],
[-10,-345,-205,60,-145,-45,-360,390.]))
n = shape(A)[0]
w_e = linalg.eigvals(A)
wr,wi,vl,vr,info=linalg.flapack.dgeev(A,compute_vl=1,compute_vr=1,lwork=4*n,overwrite_a=0)
plot(w_e.real,w_e.imag,'b+')
legend(('$\lambda_i$',),shadow=True)
xlim(699,701)
xlabel(r'$\Re\lambda$')
ylabel(r'$\Im\lambda$')
show()
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy1.0.1 installation problem - urgent :(
Thanks so much. It works. Lu Quoting Brian Granger <[EMAIL PROTECTED]>: > I don't run numpy no linux often, but you shouldn't have any trouble. > I would do the following: > > 1. Blast your current numpy install > > rm -rf /usr/local/lib/python2.5/site-packages/numpy > > 2. Get the lastest svn version > > cd $HOME > svn co http://svn.scipy.org/svn/numpy/trunk numpy > > 3. Try doing a fresh install (starting from $HOME): > > cd numpy > python setup.py build > sudo python setup.py install > > Let us know if that helps. > > Brian > > On 2/14/07, lu yang <[EMAIL PROTECTED]> wrote: > > Hi, > > This is the first time I install Numpy on a linux machine. I have been > > working on it for several days without luck. I sincerely appreciate if > > anybody can give any comments. My OS is Red Hat 8. > > I have downloaded Python 2.5 and Numpy 1.0.1. Python 2.5 has been installed > > on my machine. However, when I type: > > "python2.5 setup.py install" to install Numpy in my home directory > > /home/o6c11/numpy-1.0.1 , I got: > > > > [EMAIL PROTECTED] numpy-1.0.1]$ python2.5 setup.py install > > Traceback (most recent call last): > > File "setup.py", line 89, in > > setup_package() > > File "setup.py", line 59, in setup_package > > from numpy.distutils.core import setup > > File "numpy/__init__.py", line 36, in > > import core > > File "/mnt/storage/home/o6c11/numpy-1.0.1/numpy/core/__init__.py", line 5, > > in > > import multiarray > > ImportError: No module named multiarray > > > > I changed the directory to > > /usr/local/lib/python2.5/site-packages/numpy, I got: > > > > [EMAIL PROTECTED] numpy]$ python2.5 setup.py install > > Traceback (most recent call last): > > File "setup.py", line 28, in > > from numpy.distutils.core import setup > > File > > "/usr/local/lib/python2.5/site-packages/numpy/__init__.py", > > line 40, in > > import linalg > > File > > "/usr/local/lib/python2.5/site-packages/numpy/linalg/__init__.py", > > line 4, in > > from linalg import * > > File > > "/usr/local/lib/python2.5/site-packages/numpy/linalg/linalg.py", > > line 25, in > > from numpy.linalg import lapack_lite > > ImportError: /usr/lib/libblas.so.3: undefined symbol: e_wsfe > > > > I also tried to import numpy in this way: > > > > [EMAIL PROTECTED] numpy]$ python2.5 > > Python 2.5 (r25:51908, Feb 12 2007, 22:36:33) > > [GCC 3.2 20020903 (Red Hat Linux 8.0 3.2-7)] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import numpy > > Traceback (most recent call last): > > File "", line 1, in > > File > > "/usr/local/lib/python2.5/site-packages/numpy/__init__.py", > > line 40, in > > import linalg > > File > > "/usr/local/lib/python2.5/site-packages/numpy/linalg/__init__.py", > > line 4, in > > from linalg import * > > File > > "/usr/local/lib/python2.5/site-packages/numpy/linalg/linalg.py", > > line 25, in > > from numpy.linalg import lapack_lite > > ImportError: /usr/lib/libblas.so.3: undefined symbol: e_wsfe > > >>> > > > > I have no idea how to solve these problems. Please help a newbie. Thanks a > > lot. > > ___ > > 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 > ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] linalg.eigh orders eigenvalues/eigenvectors differently than linalg.eig
On Monday 19 February 2007 12:06, Sven Schreiber wrote: > Zachary Pincus schrieb: > > Hello all, > > > > It seems that the 'eigh' routine from numpy.linalg does not follow > > the same convention as numpy.linalg.eig in terms of the order of the > > returned eigenvalues. (And thus eigenvectors as well...) > > I was told on this list that the ordering should not be relied upon, and > that it might change in the future. So it seems that user code should > explicitly re-order the eigenvalues (and corresponding eigenvectors, > probably using argsort and fancy indexing -- if those are the right terms). Indeed. eig and eigh are wrappers for lapack functions, so the result is whatever those give back. Do not rely on a particular order of eigenvalues, sort yourself. Short example for convenience: #- eigvals, eigvecs = eig(some_matrix) ind = argsort(eigvals) eigvals = eigvals[ind] eigvecs = eigvecs[:, ind] # second axis !! # etc. # Johannes ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] linalg.eigh orders eigenvalues/eigenvectors differently than linalg.eig
Zachary Pincus schrieb: > Hello all, > > It seems that the 'eigh' routine from numpy.linalg does not follow > the same convention as numpy.linalg.eig in terms of the order of the > returned eigenvalues. (And thus eigenvectors as well...) I was told on this list that the ordering should not be relied upon, and that it might change in the future. So it seems that user code should explicitly re-order the eigenvalues (and corresponding eigenvectors, probably using argsort and fancy indexing -- if those are the right terms). ... > scipy.linalg.) If not a bug, or not-fixable-now, then at least some > documentation as to the convention regarding ordering of eigenvalues > is probably worthwhile... > true cheers, sven ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] linalg.eigh orders eigenvalues/eigenvectors differently than linalg.eig
Hello all, It seems that the 'eigh' routine from numpy.linalg does not follow the same convention as numpy.linalg.eig in terms of the order of the returned eigenvalues. (And thus eigenvectors as well...) Specifically, eig returns eigenvalues in order from largest to smallest, while eigh returns them from smallest to largest. Example: >>> a = numpy.array([[21, 28, 35],[28, 38, 48],[35, 48, 61]]) >>> numpy.linalg.eigh(a) (array([ -1.02825542e-14, 7.04131679e-01, 1.19295868e+02]), array([[ 0.40824829, -0.81314396, -0.41488581], [-0.81649658, -0.12200588, -0.56431188], [ 0.40824829, 0.56913221, -0.71373795]])) >>> numpy.linalg.eig(a) (array([ 1.19295868e+02, 7.04131679e-01, 4.62814557e-15]), array([[-0.41488581, -0.81314396, 0.40824829], [-0.56431188, -0.12200588, -0.81649658], [-0.71373795, 0.56913221, 0.40824829]])) Is this a bug? If it is, though, fixing it now might break code that depends on this 'wrong' order. (This is also present in scipy.linalg.) If not a bug, or not-fixable-now, then at least some documentation as to the convention regarding ordering of eigenvalues is probably worthwhile... Any thoughts? Zach ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
