First of all, thanks to the Numerical Python developers for releasing version 23.8 of Numerical Python. It compiles out of the box and avoids the blas/lapack compilation problems in earlier versions, which makes my life as a developer a lot easier. Thanks! Travis Oliphant wrote:
I wanted to let people who may be waiting, that now is a good time to help with numeric3. The CVS version builds (although I"m sure there are still bugs), but more eyes could help me track them down.
Currently, all that remains for the arrayobject is to implement the newly defined methods (really it"s just a re-organization and re-inspection of the code in multiarraymodule.c to call it using methods).
I downloaded Numeric3 today and installed it. The compilation and installation run fine. There are still some warnings from the compiler here and there, but I guess they will be fixed some other time. During compilation, I noticed that some test program is run, presumably for configuration. The test program is compiled by a different compiler as the one used in the build process. Note that "python setup.py config" is available in the standard distutils, so it may be better to use that instead of a self-defined configuration tool. For one thing, it'll make sure that the compiler used for configuration is the same as the one used for compilation. To use Numeric3, I did "from ndarray import *". I guess for the final version, this will be "from Numeric import *"? When using ndarray, I got a core dump using "zeros": $ python Python 2.5a0 (#1, Mar 2 2005, 12:15:06) [GCC 3.3.3] on cygwin Type "help", "copyright", "credits" or "license" for more information.
from ndarray import * zeros(5) creating data 0xa0c03d0 associated with 0xa0d52c0 array([0.0, 0.0, 0.0, 0.0, 0.0], 'd') Segmentation fault (core dumped)
With Python 2.4, the segmentation fault occurs slightly later: $ python2.4 Python 2.4 (#1, Dec 5 2004, 20:47:03) [GCC 3.3.3] on cygwin Type "help", "copyright", "credits" or "license" for more information.
from ndarray import * zeros(5) creating data 0xa0a07f8 associated with 0xa0d6230 array([0.0, 0.0, 0.0, 0.0, 0.0], 'd')
^D freeing 0xa0a07f8 associated with array 0xa0d6230 freeing 0xa123b88 associated with array 0xa0d6230 Segmentation fault (core dumped)
Finally, I tried to compile a C extension module that uses Numerical Python (by replacing #include <Numeric/arrayobject.h> by #include <ndarray/arrayobject.h>): $ python setup.py build running build running build_py running build_ext building 'Pycluster.cluster' extension gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Isrc -Iranli b/src -I/usr/local/include/python2.5 -c python/clustermodule.c -o build/temp.cyg win-1.5.12-i686-2.5/python/clustermodule.o In file included from python/clustermodule.c:2: /usr/local/include/python2.5/ndarray/arrayobject.h:76: warning: redefinition of `ushort' /usr/include/sys/types.h:85: warning: `ushort' previously declared here /usr/local/include/python2.5/ndarray/arrayobject.h:77: warning: redefinition of `uint' /usr/include/sys/types.h:86: warning: `uint' previously declared here These two warnings are probably not so serious, but it would be better to get rid of them anyway. python/clustermodule.c: In function `parse_data': python/clustermodule.c:38: warning: passing arg 1 of pointer to function from in compatible pointer type The offending line 38 is: { PyArrayObject* av = (PyArrayObject*) PyArray_Cast(*array, PyArray_DOUBLE); where array is a PyArrayObject**. Another warning was that PyArrayObject's "dimensions" doesn't seem to be an int array any more. Finally, when linking I get an undefined reference to _PyArray_API. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon