Mailman 3 April 2006 - NumPy-Discussion

Question about __array_struct__
by Sasha 25 Apr '06

25 Apr '06

I am trying to add __array_struct__ attribute to R object wrappers in RPy. This is desirable because it eliminates a compile-time dependency on an array module and makes the binary compatible with either Numeric or numpy. R has four types of data: logical, integer, float, and character. The first three map perfectly to Numpy with inter->data simply pointing to an appropriate internal memory area. The character type, however is more problematic. In R character arrays are arrays of variable length strings and therefore similar to Numpy object arrays holding python strings. Obviously, there is no memory area that can be reused. I've tried to allocate new memory in __array_struct__ getter, but this presents a problem: I cannot deallocate that memory in CObject destructor because it is passed to the newly created array which lives long after the interface object is deleted. The __array_struct__ mechanism does not seem to allow to cause the new array assume ownership of the data, but even if it did, I do not know what memory allocator is appropriate. The only solution that I can think of is to create a dummy buffer type with the sole purpose of deleting an array of PyObjects and make an instance of that type the "base" of the new array. Can anyone suggest a better approach?

2 1

Backporting numpy to Python 2.2
by Tim Wegener 25 Apr '06

25 Apr '06

Hi, I am attempting to backport numpy-0.9.6 to be compatible with python 2.2. (Some of our machines run python 2.2 as part of Red Hat 9 and Red Hat 7.3 and it is hazardous to alter the standard setup.) I was able to change most of the 2.3-isms to be 2.2 compatible (see the attached patch). However I had problems compiling the following c module: In file included from numpy/core/src/multiarraymodule.c:64: numpy/core/src/arrayobject.c: In function `arraydescr_dealloc': numpy/core/src/arrayobject.c:8417: warning: passing arg 1 of pointer to function from incompatible pointer type numpy/core/src/multiarraymodule.c: In function `PyArray_DescrConverter': numpy/core/src/multiarraymodule.c:4072: `PyBool_Type' undeclared (first use in this function) numpy/core/src/multiarraymodule.c: In function `setup_scalartypes': numpy/core/src/multiarraymodule.c:5736: `PyBool_Type' undeclared (first use in this function) numpy/core/src/multiarraymodule.c: In function `initmultiarray': numpy/core/src/multiarraymodule.c:5897: `PyObject_SelfIter' undeclared (first use in this function) error: Command "gcc -DNDEBUG -O2 -g -pipe -march=i386 -mcpu=i686 -D_GNU_SOURCE -fPIC -fPIC -Ibuild/src/numpy/core/src -Inumpy/core/include -Ibuild/src/numpy/core -Inumpy/core/src -Inumpy/core/include -I/usr/include/python2.2 -c numpy/core/src/multiarraymodule.c -o build/temp.linux-i686-2.2/multiarraymodule.o" failed with exit status 1 Is it possible to modify this module for python 2.2 compatibility or have I reached a dead end? It would be great if numpy were compatible with 2.2 out of the box, given that 2.3 is only a couple of years old (new), and 2.2 is still quite widely deployed. I am trying to migrate to numpy from Numeric, which worked happily with 2.2. FYI, a quick summary of the compatibility amendments to the python code: - backported os.walk - backported enumerate - backported distutils.log - used slices instead of list.index(item, <start>) - used 'r' mode instead of 'U' mode (it didn't seem that universal newline support was needed where it was used) - used the {} way of building a new dict rather than using keyword args to the dict constructor - from __future__ import generators - used str.count(substr) rather than substr in str - used os.sep rather than os.path.sep - commented out some of the new Configuration keword arguments (download_url and classifiers) The above don't really affect the functionality, but a couple of more unusual changes were needed as well: - had to add "self.compiler.exe_extension = ''" to numpy/distutils/command/config.py (see patch) - had to change the following to and empty dict: "kws = {'depends':ext.depends}" in numpy/distutils/command/build_ext.py (see patch) These two changes may have unwanted side effects, and a better fix is probably needed there. Regards, Tim

4 3

Voce recebeu uma charge humortadela
by Humortadela 25 Apr '06

25 Apr '06

1 0

Broadcasting rules (Ticket 76).
by Sasha 25 Apr '06

25 Apr '06

I was looking at ticket 76: http://projects.scipy.org/scipy/numpy/ticket/76 At first, I concluded that the ticket was valid and that >>> a = zeros([5,2]) >>> a[:] = arange(5) should raise an error as it did in Numeric. However, once I started looking at the code, I've realized that numpy supports more flexible broadcasting rules than Numeric. For example: >>> x = zeros([10]) >>> x[:] = 1,2 >>> x array([1, 2, 1, 2, 1, 2, 1, 2, 1, 2]) That would be an error in Numeric. Given that the above is valid, the result in Ticket 76 actually makes sense. I believe it is time to have some discussion about the future of broadcasting rules in numpy. Can anyone provide a summary of the status quo?

3 13

Re: [SciPy-dev] Google Summer of Code
by Robert Kern 24 Apr '06

24 Apr '06

[Cross-posted because this is partially an announcement. Continuing discussion should go to only one list, please.] Antonio Arauzo Azofra wrote: > Google Summer of Code > http://code.google.com/soc/ > > Have you considered participating as a Mentoring organization? Offering > any project about Scipy? I'm not sure which "you" you are referring to here, but yes! Unfortunately, it was a bit late in the process to be applying as a mentoring organization. Google started consolidating mentoring organizations. However, I and several others at Enthought are volunteering to mentor through the PSF. I encourage others on these lists to do the same or to apply as students, whichever is appropriate. We'll be happy to provide SVN workspace for numpy and scipy SoC projects. I've added one fairly general scipy entry to the python.org Wiki page listing project ideas: http://wiki.python.org/moin/SummerOfCode If you have more specific ideas, please add them to the Wiki. Potential mentors: Neal Norwitz is coordinating PSF mentors this year and has asked that those he or Guido does not know personally to give personal references. If you've been active on this list, I'm sure we can play the "Two Degrees of Separation From Guido Game" and get you a reference from someone else here. -- Robert Kern robert.kern(a)gmail.com "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

1 0

Problems building numpy
by Rick Muller 24 Apr '06

24 Apr '06

Numpy really builds nicely now, and I appreciate all of the hard work that people have put into portability of this code. That being said, I just had my first system where Numpy failed to build. It's on a redhat 7.3 (yes, we have a 7.3 box. I didn't believe it either. not my decision.) and I get the following error when trying to run Numpy: Python 2.4.3 (#1, Apr 24 2006, 09:54:46) [GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-42)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from numpy import array import linalg -> failed: /usr/local/lib/python2.4/site-packages/numpy/ linalg/lapack_lite.so: undefined symbol: s_wsfe If this is easy to fix, I'd prefer to fix it. However, if the numpy developers have better things to do than to support a 10-year-old operating system (and I suspect that they do), I'm cool with that. Rick Rick Muller rmuller(a)sandia.gov

4 6

Changing the Trac authentication, for real this time!
by Robert Kern 24 Apr '06

24 Apr '06

If you encounter errors accessing the Trac sites for NumPy and SciPy over the next hour or so, please wait until I have announced that I have finished. If things are still broken after that, please let me know and I will try to fix it immediately. The details of the changes were posted to the previous thread "Changing the Trac authentication". Apologies for any disruption and for the noise. -- Robert Kern robert.kern(a)gmail.com "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

1 1

numexpr enhancements
by faltet＠xot.carabos.com 24 Apr '06

24 Apr '06

Hi, After looking at the numpy performance issues on strided and unaligned data, I decided to have a try at the numexpr package and finally implemented better suport for them. As a result, numexpr can reach now a 2x of performance improvement for simple expressions, like 'a>2.'. In the way, I've added support for boolean expressions (&, | and ~, as in the where() function), a new boolean data type (important to get better performance on boolean expressions) and support for numarray (maintaining the compatibility with numpy, of course). I've called the new package numexpr 0.2 to not confuse it with existing 0.1. Well, let's hope that numexpr can continue making its way towards integration in numpy. You can fetch this new package at: http://www.carabos.com/downloads/divers/numexpr-0.2.tar.gz Finally, let me say that numexpr is a wonderful toy to get your hands dirty ;-) Many thanks to David (and Tim) for this! Cheers! Francesc

2 1

Changing the Trac authentication
by Robert Kern 23 Apr '06

23 Apr '06

I will be changing the Trac authentication over the next hour or so. I will be installing the AccountManagerPlugin to allow users to create accounts for themselves without needing to have SVN write access. Anonymous users will not be able to edit the Wikis or tickets. Non-developer, but registered users will be able to do so with some restrictions, notably not being able to resolve tickets. Developers who currently have accounts will have the same username/password as before. If you have problems using the Trac sites before I announce that I am done, please wait until I am finished. If there are still problems, please let me know and I will try to fix them as soon as possible. Thank you for your patience. Hopefully, this change will resolve the spam problem. -- Robert Kern robert.kern(a)gmail.com "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

1 1

Error installing on amd64 Debian-unstable
by Angus McMorland 23 Apr '06

23 Apr '06

I had no troubles installing numpy and scipy on my 32-bit laptop, but cannot get numpy to install on my amd64 debian desktop. I've pulled in the latest svn versions, then run: $ python setup.py install Installation seems to run okay (no error messages), but the following happens: In [1]: import numpy import core -> failed: /usr/lib/python2.3/site-packages/numpy/core/_sort.so: undefined symbol: PyArray_CompareUCS4 import lib -> failed: module compiled against version 90703 of C-API but this version of numpy is 90704 import linalg -> failed: module compiled against version 90703 of C-API but this version of numpy is 90704 import dft -> failed: cannot import name asarray import random -> failed: 'module' object has no attribute 'dtype' --------------------------------------------------------------------------- exceptions.ImportError Traceback (most recent call last) /home/amcmorl/<ipython console> /usr/lib/python2.3/site-packages/numpy/__init__.py 47 return NumpyTest().test(level, verbosity) 48 ---> 49 import add_newdocs 50 51 if __doc__ is not None: /usr/lib/python2.3/site-packages/numpy/add_newdocs.py ----> 2 from lib import add_newdoc 3 4 add_newdoc('numpy.core','dtype', 5 [('fields', "Fields of the data-typedescr if any."), 6 ('alignment', "Needed alignment for this data-type"), ImportError: cannot import name add_newdoc Can anyone suggest what I'm doing wrong? Cheers, A. -- Angus McMorland email a.mcmorland(a)auckland.ac.nz mobile +64-21-155-4906 PhD Student, Neurophysiology / Multiphoton & Confocal Imaging Physiology, University of Auckland phone +64-9-3737-599 x89707 Armourer, Auckland University Fencing Secretary, Fencing North Inc.

2 1