[Numpy-discussion] Numeric3 CVS compiles now

Michiel Jan Laurens de Hoon mdehoon at ims.u-tokyo.ac.jp
Sat Mar 26 02:49:23 CST 2005


I've downloaded the latest Numeric3 and tried to compile it. I found one error 
in setup.py that I put in myself a couple of days ago; I fixed this in CVS.

On Cygwin, the compilation and installation runs without problems, other than 
the warning messages. However, when I try to compile Numeric3 for Windows, an 
error windows pops up with the following message:

16 bit MS-DOS Subsystem
~/Numeric3
The NTVDM CPU has encountered an illegal instruction.
CS:071d IP:210f OP:63 69 66 69 65 Choose 'Close' to terminate the application

It seems that this message is due to the section labeled "#Generate code" in 
setup.py, where python is being run with a call to os.system. What does this do? 
Is there a need to generate code automatically in setup.py, rather than include 
the generated code with the Numeric3 source code?

When using Numeric3, I found that the zeros function now returns a float array 
by default, whereas Numeric returns an integer array:

$ 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)
array([0.0, 0.0, 0.0, 0.0, 0.0], 'd')
 >>> array([1,2,3])
array([1, 2, 3], 'l')
 >>>

mdehoon at ginseng ~
$ 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 Numeric import *
 >>> zeros(5)
array([0, 0, 0, 0, 0])
 >>> array([1,2,3])
array([1, 2, 3])
 >>> array([1,2,3]).typecode()
'l'
 >>>

Is there a reason to change the default behavior of zeros? Existing code may 
assume that zeros returns an integer array, and may behave incorrectly with 
Numeric3. Such bugs would be very hard to find.

Finally, I tried to compile an extension module with Numeric3. The warning 
messages concerning the type of PyArrayObject->dimensions no longer occur, now 
that intp is typedef'd as an int instead of a long. But I agree with David Cooke 
that using Py_intptr_t in pyport.h would be better:

> Why not use Py_intptr_t? It's defined by the Python C API already (in
> pyport.h).

When compiling the extension module, I get warning messages about PyArray_Cast, 
which now takes a PyObject* instead of a PyArrayObject* as in Numerical Python. 
Is this a typo in Src/arrayobject.c? Also, the PyArray_Cast function has the 
comment /* For backward compatibility */ in Src/arrayobject.c. Why is that?

Linking the extension module fails due to the undefined reference to _PyArray_API.

--Michiel.

Travis Oliphant wrote:

> 
> To all who were waiting:
> 
> I've finished adding the methods to the array object so that Numeric3 in 
> CVS now compiles (at least for me on Linux).
> 
> I will be away for at least a day so it is a good time to play...
> -Travis
> 
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
> 
> 

-- 
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




More information about the Numpy-discussion mailing list