Mailman 3 March 2006 - NumPy-Discussion

Difference between eigh and Heigenvectors
by Rick Muller 17 Mar '06

17 Mar '06

What exactly is the difference between eigh and Heigenvectors. As far as I can tell, the eigenvalues are the same, but the eigenvectors are transposes of each other. Is this a matlab compatibility thing? Thanks in advance, R. Rick Muller rmuller(a)sandia.gov

1 0

Call for posters to gmane.comp.python.devel newsgroup
by Travis Oliphant 17 Mar '06

17 Mar '06

I'm trying to start discussions on python dev about getting a simple object into Python that at least exposes the array interface and/or has the basic C-structure of NumPy arrays. Please voice your support and comments on the newsgroup. The more people that respond, the more the python developers will see that it's not just my lonely voice asking for things to change. Perhaps it will help somebody with more time to get a PEP written up. I doubt we will make it into Python 2.5, unless somebody steps up in the next month, but it will help for Python 2.6 Thanks, -Travis

1 0

How compile Numpy on Gentoo system (finding atlas-blas and atlas-lapack)
by Zdeněk Hurák 17 Mar '06

17 Mar '06

Hello, is anybody here working with Numpy on Gentoo Linux system? I have troubles with compiling it with ATLAS-BLAS and ATLAS-LAPACK. The trouble is perhaps that Gentoo has a little bit different approach to storing optimized BLAS and LAPACK on the system then other Linux distros. And apparently Numpy cannot find it. Numpy documentation says that I should specify the path to ATLAS in site.cfg in numpy/distutils, but I cannot find one. Thanks for your help, Zdenek Hurak ------------------------------------------------------------------ hurak@note-zhurak ~ $ ls -l /usr/lib | grep atlas -rw-r--r-- 1 root root 5293184 led 27 15:57 libatlas.a -rwxr-xr-x 1 root root 793 led 27 15:57 libatlas.la lrwxrwxrwx 1 root root 17 led 27 15:57 libatlas.so -> libatlas.so.0.0.0 lrwxrwxrwx 1 root root 17 led 27 15:57 libatlas.so.0 -> libatlas.so.0.0.0 -rwxr-xr-x 1 root root 2883644 led 27 15:57 libatlas.so.0.0.0 lrwxrwxrwx 1 root root 21 led 27 15:57 libblas.so -> blas/atlas/libblas.so lrwxrwxrwx 1 root root 23 led 27 15:57 libblas.so.0 -> blas/atlas/libblas.so.0 lrwxrwxrwx 1 root root 21 led 27 15:57 libcblas.a -> blas/atlas/libcblas.a lrwxrwxrwx 1 root root 22 led 27 15:57 libcblas.so -> blas/atlas/libcblas.so lrwxrwxrwx 1 root root 24 led 27 15:57 libcblas.so.0 -> blas/atlas/libcblas.so.0 lrwxrwxrwx 1 root root 25 led 27 21:37 liblapack.so -> lapack/atlas/liblapack.so lrwxrwxrwx 1 root root 27 led 27 21:37 liblapack.so.0 -> lapack/atlas/liblapack.so.0 ------------------------------------------------------------------ hurak@note-zhurak ~/tmp/install/numpy-0.9.6/numpy/distutils $ cat ../../build/lib.linux-i686-2.4/numpy/__config__.py # This file is generated by /home/hurak/tmp/install/numpy-0.9.6/setup.py # It contains system_info results at the time of building this package. __all__ = ["get_info","show"] blas_info={'libraries': ['blas'], 'library_dirs': ['/usr/lib'], 'language': 'f77'} lapack_info={'libraries': ['lapack', 'blas'], 'library_dirs': ['/usr/lib'], 'language': 'f77'} atlas_threads_info={} blas_opt_info={'libraries': ['blas'], 'library_dirs': ['/usr/lib'], 'define_macros': [('NO_ATLAS_INFO', 1)], 'language': 'f77'} atlas_blas_threads_info={} lapack_opt_info={'libraries': ['lapack', 'blas'], 'library_dirs': ['/usr/lib'], 'define_macros': [('NO_ATLAS_INFO', 1)], 'language': 'f77'} atlas_info={} lapack_mkl_info={} blas_mkl_info={} atlas_blas_info={} mkl_info={} [...] ------------------------------------------------------------------ hurak@note-zhurak ~/tmp/install/numpy-0.9.6 $ ls numpy/distutils/ ccompiler.py exec_command.pyc intelccompiler.py system_info.py ccompiler.pyc extension.py lib2def.py system_info.pyc command extension.pyc line_endings.py tests conv_template.py fcompiler log.py unixccompiler.py conv_template.pyc from_template.py log.pyc unixccompiler.pyc core.py from_template.pyc mingw32ccompiler.py __version__.py core.pyc info.py misc_util.py __version__.pyc cpuinfo.py info.pyc misc_util.pyc cpuinfo.pyc __init__.py setup.py exec_command.py __init__.pyc setup.pyc ------------------------------------------------------------------

2 3

strange paths on install and some warnings
by Arnd Baecker 17 Mar '06

17 Mar '06

Hi, for a current svn checkout of numpy and installing with python setup.py build python setup.py install --prefix=/tmp/NUMPY this results in an install under: $HOME/.PythonLibrary/Python2.3/ ... (("""copying build/lib.linux-i686-2.3/numpy/_import_tools.py -> /home/abaecker/.PythonLibrary/Python2.3/site-packages/numpy""")) Only f2py behaves and gets installed in /tmp/NUMPY/bin. First I thought that it has something to do with a setuptools test I did some time ago, but moving ~/.PythonLibrary to a different place before installing numpy did not help. (it was also not on the PYTHONPATH before, so it should not have made a difference anyway). Even more weirdly, everything works fine on a different machine. So it looks like some configuration issue. On the other hand I did a couple of builds before (some time ago) on this machine. Before I start looking into this in more detail, I would be interested in any ideas how the above could come about and what tests I could do. In addition to the above I get a couple of warnings/errors (see below). I am not sure about their relevance (I don't remember to have seen them before). Best, Arnd Warning: not existing path in numpy/distutils: site.cfg No module named __svn_version__ F2PY Version 2_2255 blas_opt_info: blas_mkl_info: /tmp/NUMPY/numpy/numpy/distutils/system_info.py:531: UserWarning: Library error: libs=['mkl', 'vml', 'guide'] found_libs=[] warnings.warn("Library error: libs=%s found_libs=%s" % \ NOT AVAILABLE atlas_blas_threads_info: Setting PTATLAS=ATLAS /tmp/NUMPY/numpy/numpy/distutils/system_info.py:531: UserWarning: Library error: libs=['ptf77blas', 'ptcblas', 'atlas'] found_libs=[] warnings.warn("Library error: libs=%s found_libs=%s" % \ /tmp/NUMPY/numpy/numpy/distutils/system_info.py:531: UserWarning: Library error: libs=['ptf77blas', 'ptcblas', 'atlas'] found_libs=['/usr/lib/sse2/libatlas.so'] warnings.warn("Library error: libs=%s found_libs=%s" % \ /tmp/NUMPY/numpy/numpy/distutils/system_info.py:531: UserWarning: Library error: libs=['ptf77blas', 'ptcblas', 'atlas'] found_libs=['/usr/lib/sse2/libatlas.a'] warnings.warn("Library error: libs=%s found_libs=%s" % \ /tmp/NUMPY/numpy/numpy/distutils/system_info.py:531: UserWarning: Library error: libs=['ptf77blas', 'ptcblas', 'atlas'] found_libs=['/usr/lib/libatlas.so'] warnings.warn("Library error: libs=%s found_libs=%s" % \ NOT AVAILABLE atlas_blas_info: /tmp/NUMPY/numpy/numpy/distutils/system_info.py:531: UserWarning: Library error: libs=['f77blas', 'cblas', 'atlas'] found_libs=[] warnings.warn("Library error: libs=%s found_libs=%s" % \ FOUND: libraries = ['f77blas', 'cblas', 'atlas'] library_dirs = ['/usr/lib/sse2'] language = c include_dirs = ['/usr/include'] /tmp/NUMPY/numpy/numpy/distutils/system_info.py:1075: FutureWarning: hex()/oct() of negative int will return a signed string in Python 2.4 and up magic = hex(hash(repr(config)))

1 1

Status of pyfits with numpy?
by Andrew Jaffe 17 Mar '06

17 Mar '06

Hi All, Is a numpy-compatible version of pyfits nearing stability? I see that there is a pyfits-numpy branch visible on the trac browser -- is that available and stable enough for public use? Thanks, Andrew

4 4

Re: [SciPy-dev] Computing correlations with SciPy
by Travis Oliphant 17 Mar '06

17 Mar '06

John Hunter wrote: > The following message is a courtesy copy of an article > that has been posted to comp.lang.python as well. > > >>>>>> "tkpmep" == tkpmep <tkpmep(a)hotmail.com> writes: >>>>>> > > tkpmep> I want to compute the correlation between two sequences X > tkpmep> and Y, and tried using SciPy to do so without success.l > tkpmep> Here's what I have, how can I correct it? > > >>>> X = [1, 2, 3, 4, 5] Y = [5, 4, 3, 2, 1] import scipy > >>>> scipy.corrcoef(X,Y) > tkpmep> Traceback (most recent call last): File "<interactive > tkpmep> input>", line 1, in ? File > tkpmep> "C:\Python24\Lib\site-packages\numpy\lib\function_base.py", > tkpmep> line 671, in corrcoef d = diag(c) File > tkpmep> "C:\Python24\Lib\site-packages\numpy\lib\twodim_base.py", > tkpmep> line 80, in diag raise ValueError, "Input must be 1- or > tkpmep> 2-d." ValueError: Input must be 1- or 2-d. > >>>> > > Hmm, this may be a bug in scipy. matplotlib also defines a corrcoef > function, which you may want to use until this problem gets sorted out > > The problem is now sorted out in SVN of numpy. The problem was inherited from Numeric's MLab. I revamped the cov function (which corrcoef depended on) so it should hopefully work better than it did. Thanks for the heads up. -Travis

1 0

Trouble building NumPy on 64bit Ubuntu Linux
by Rudolph van der Merwe 17 Mar '06

17 Mar '06

I followed the instructions given on http://pong.tamu.edu/tiki/tiki-view_blog_post.php?blogId=6&postId=97 (linked to from main Numpy / SciPy wiki) to try and install Numpy + Scipy on a 64bit Ubuntu Linux system, but something is not working. I get the following error message during the 'build phase of Numpy (0.9.6): /usr/bin/g77 -shared build/temp.linux-x86_64-2.4/numpy/linalg/lapack_litemodule.o -L/usr/local/lib/atlas -llapack -lptf77blas -lptcblas -latlas -lg2c-pic -o build/lib.linux-x86_64-2.4/numpy/linalg/lapack_lite.so /usr/bin/ld: /usr/local/lib/atlas/liblapack.a(dlamch.o): relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC /usr/local/lib/atlas/liblapack.a: could not read symbols: Bad value collect2: ld returned 1 exit status The main problem seems to be this part... "relocation R_X86_64_32S can not be used when making a shared object; recompile with -fPIC". This seems to be related to the ATLAS optimized LAPACK library which I built using the standard method as laid out in the ATLAS errata. The weird thing is that I did in fact specify the -fPIC compiler flag, so I'm not sure how to proceed from here. Any thoughts? Thanks R. -- Rudolph van der Merwe

2 2

Re: [Numpy-discussion] Trouble building NumPy on 64bit Ubuntu Linux
by Rudolph van der Merwe 17 Mar '06

17 Mar '06

Nils, Thanks... that solved the problem. Much appreciated! Rudolph On 3/16/06, Nils Wagner <nwagner(a)mecha.uni-stuttgart.de> wrote: > > Did you use > > # > # On 64 bit systems with GNU compiler > # > OPTS = -O2 -m64 -fPIC > NOOPT = -m64 -fPIC > > (two lines of make.inc) > > to compile lapack ? > > Also I have added -m64 -fPIC to some lines in the ATLAS generated makefile ( > Make.Linux_HAMMER64SSE3) > > F77 = /usr/bin/g77 > F77FLAGS = -fomit-frame-pointer -O -m64 -fPIC > FLINKER = $(F77) > FLINKFLAGS = $(F77FLAGS) > FCLINKFLAGS = $(FLINKFLAGS) > > > # --------------------------------------------------------------------------- > # Various C compilers, and the linker to be used when we are not linking in > # non-ATLAS BLAS (which usually necessitate using the Fortran linker). > # The C compilers recognized by ATLAS are: > # CC : Compiler to use to compile regular, non-generated code > # MCC : Compiler to use to compile generated, highly-optimized code > # XCC : Compiler to be used on the compile engine of a cross-compiler > # These will typically all be the same. An example of where this is not > # the case would be DEC ALPHA 21164, where you want to use gcc for MCC, > # because DEC's cc does not allow the programmer access to all 32 floating > # point registers. However, on normal C code, DEC's cc produces much faster > # code than gcc, so you CC set to cc. Of course, any system where you are > # cross-compiling, you will need to set XCC differently than CC & MCC. > # --------------------------------------------------------------------------- > CDEFS = $(L2SIZE) $(INCLUDES) $(F2CDEFS) $(ARCHDEFS) > > GOODGCC = gcc > CC = /usr/bin/gcc > CCFLAG0 = -fomit-frame-pointer -O -mfpmath=387 -m64 -fPIC > CCFLAGS = $(CDEFS) $(CCFLAG0) > MCC = /usr/bin/gcc > MMFLAGS = -fomit-frame-pointer -O -mfpmath=387 -m64 -fPIC > XCC = /usr/bin/gcc > XCCFLAGS = $(CDEFS) -fomit-frame-pointer -O -mfpmath=387 -m64 -fPIC > CLINKER = $(CC) > CLINKFLAGS = $(CCFLAGS) > BC = $(CC) > BCFLAGS = $(CCFLAGS) > ARCHIVER = ar > ARFLAGS = r > RANLIB = echo > > > Nils > > > > > -- Rudolph van der Merwe

1 0

Re: [SciPy-user] nd_image
by Travis Oliphant 16 Mar '06

16 Mar '06

joris(a)ster.kuleuven.ac.be wrote: > [TO]: So, what we have in SciPy is "the official" home for the numpy > [TO]: version of his package. > >Sorry, I am a bit lost here. So nd_image was a numarray library, and is now >available via scipy where it works with numpy arrays (correct?). > nd_image was a Package that built on top of numarray and was also distributed with numarray. Exactly what goes in the base numpy backage and what goes into add-on packages is a question we will wrestle with for a while. With the existence of SciPy, I don't favor growing NumPy much beyond the (general) feature-set it has now. There are already people who grumble that it includes too-much stuff that they don't need. Other functionality should be added by other packages. We are trying to make SciPy into a large collection of packages that don't all have to be installed, so that users can pick and choose what they need if they must. >At the moment, >the library is unmaintained though, regardless whether it would be part of >scipy or numpy. Correct? If so, why exactly would it be better to put it under >scipy rather than under numpy? > > Not directly accurate. The SciPy version is maintained by the SciPy developers (not by the original author). >Some people don't need scipy for their work and are happy with numpy alone. >It used to be rather easy for them to use nd_image with numarray, but if I >understand you correctly, they would now have to install an entire new package, > > Many SciPy packages can be installed separately and nd_image (now scipy.image) is one of them. So, it is very easy to just install the scipy.image package. Hopefully, more people will run with this concept as the need arises. And, scipy is not has hard to install as you might think. Especially if you go into the setup.py file and comment out all the packages you don't actually want... -Travis

1 0

SVN version of NumPy will require rebuild of extensions
by Travis Oliphant 16 Mar '06

16 Mar '06

This is to serve notice that I altered the C-API table in the SVN version of numpy. This change will require a rebuild of extension modules. You are supposed to get notice of that when you try to import the extension module (but that didn't work for me for some reason, importing scipy just segfaulted --- ahh.. I just figured it out... the command that gets the version number is located down in the table. This location has just changed. It makes a case that this command should always be the first entry in the C-API table). The modifications (with a few new C-API calls) will allow construction of the scalar-math tables. -Travis

1 0