Mailman 3 September 2006 - NumPy-Discussion

arr.dtype.kind is 'i' for dtype=unit !?
by Sebastian Haase 22 Sep '06

22 Sep '06

Hi, What are the possible values of arr.dtype.kind ? It seems that signed and unsigned are considered to be the same "kind" >>> arr=N.arange(10,dtype=N.uint) >>> arr.dtype.kind 'i' >>> arr.dtype.itemsize 8 (OK - this is just showing off our amd64 linux ;-) ) How can I distinguish signed from unsigned without having to list all possible cases explicitly ? Thanks, Sebastian Haase

6 8

1.0rc1 doesn't seem to work on AMD64
by Peter Bienstman 21 Sep '06

21 Sep '06

Hi, I just installed rc1 on an AMD64 machine. but I get this error message when trying to import it: Python 2.4.3 (#1, Sep 21 2006, 13:06:42) [GCC 4.1.1 (Gentoo 4.1.1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import numpy Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib64/python2.4/site-packages/numpy/__init__.py", line 36, in ? import core File "/usr/lib64/python2.4/site-packages/numpy/core/__init__.py", line 7, in ? import numerictypes as nt File "/usr/lib64/python2.4/site-packages/numpy/core/numerictypes.py", line 191, in ? _add_aliases() File "/usr/lib64/python2.4/site-packages/numpy/core/numerictypes.py", line 169, in _add_aliases base, bit, char = bitname(typeobj) File "/usr/lib64/python2.4/site-packages/numpy/core/numerictypes.py", line 119, in bitname char = base[0] IndexError: string index out of range Thanks! Peter

2 1

nan adds lots of whitespace
by Keith Goodman 21 Sep '06

21 Sep '06

NaN adds a lot of whitespace in the representation of a matrix. Without NaN: matrix([[1, 2], [3, 4]]) With NaN: matrix([[ nan, 2. ], [ 3. , 4. ]]) There's enough room for the wikipedia entry for nan.

1 0

sorting -inf, nan, inf
by Keith Goodman 21 Sep '06

21 Sep '06

In what order would you like argsort to sort the values -inf, nan, inf? In numpy 1.0b1 nan is always left where it began: EXAMPLE 1 >> x matrix([[ inf], [ -inf], [ nan]]) >> x[x.argsort(0),:] matrix([[ -inf], [ inf], [ nan]]) EXAMPLE 2 >> x matrix([[ nan], [ inf], [ -inf]]) >> x[x.argsort(0),:] matrix([[ nan], [ -inf], [ inf]]) I would like nan to be in the middle between -inf and inf.

9 27

Division by zero doesn't raise exception in the integer case.
by Charles R Harris 21 Sep '06

21 Sep '06

Travis, Is this intentional? In [77]: arange(5, dtype=int)/0 Out[77]: array([0, 0, 0, 0, 0]) It looks deliberate because all zeros are returned, but it might be better if it raised an exception. Chuck

3 3

If you don't want to receive $5000 per month then don't open that letter
by Katherine Goldberg 21 Sep '06

21 Sep '06

Please read this letter attentively! Financial company is in search of representatives in the US. - Age: from 18 till 60 years - Have a skill to communicate and access to the Internet. - You can speak english language above average - You need to know how to use excel and word. You will earn from 1500 up to 3000 USD per week, working only some hours per day. You can work part time or full time. If you are interested in our offer send the following data to our e-mail usa(a)euroimperial2.com - Your full name - Your contact e-mail - Your phone number If you have any questions. Feel free to ask them

2 1

I've just tagged the tree for 1.0rc1
by Travis Oliphant 21 Sep '06

21 Sep '06

There is now a 1.0rc1 tag on the NumPy SVN tree. I've confirmed it builds and passes all tests on my Linux box for Python2.3-Python2.5 -Travis

2 1

ANN: Job postings -- Enthought, Inc.
by eric 21 Sep '06

21 Sep '06

Hey group, We are growing again and have multiple positions open here at Enthought. I'd love to recruit more people out of the Scipy/numpy community. I think many of you would find the work interesting. You can look at our career page for more info: http://www.enthought.com/careers.htm <http://www.enthought.com/careers.html> thanks! eric

1 0

Possible inconsisteny in enumerated type mapping
by Francesc Altet 20 Sep '06

20 Sep '06

Hi, I'm sending a message here because discussing about this in the bug tracker is not very comfortable. This my last try before giving up, so don't be afraid ;-) In bug #283 (http://projects.scipy.org/scipy/numpy/ticket/283) I complained about the fact that a numpy.int32 is being mapped in NumPy to NPY_LONG enumerated type and I think I failed to explain well why I think this is a bad thing. Now, I'll try to expose an (real life) example, in the hope that things will make clearer. Realize that you are coding a C extension that receives NumPy arrays for saving them on-disk for a later retrieval. Realize also that an user is using your extension on a 32-bit platform. If she pass to this extension an array of type 'int32', and the extension tries to read the enumerated type (using array.dtype.num), it will get NPY_LONG. So, the extension use this code (NPY_LONG) to save the type (together with data) on-disk. Now, she send this data file to a teammate that works on a 64-bit machine, and tries to read the data using the same extension. The extension would see that the data is NPY_LONG type and would try to deserialize interpreting data elements as being as 64-bit integer (this is the size of a NPY_LONG in 64-bit platforms), and this is clearly wrong. Besides this, if for making your C extension you are using a C library that is meant to save data in a platform-independent (say, HDF5), then, having a NPY_LONG will not automatically say which C library datatype maps to, because it only have datatypes that are of a definite size in all platforms. So, this is a second problem. Of course there are workarounds for this, but my impression is that they can be avoided with a more sensible mapping between NumPy Python types and NumPy enumerated types, like: numpy.int32 --> NPY_INT numpy.int64 --> NPY_LONGLONG numpy.int_ --> NPY_LONG in all platforms, avoiding the current situation of ambiguous mapping between platforms. Sorry for being so persistent, but I think the issue is worth it. -- >0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"

2 2

ufunc.reduce and conversion
by A. M. Archibald 20 Sep '06

20 Sep '06

Hi, What are the rules for datatype conversion in ufuncs? Does ufunc(a,b) always yield the smallest type big enough to represent both a and b? What is the datatype of ufunc.reduce(a)? I ask because I was startled by the following behaviour: >>> a = array([1,1],uint8); print a.dtype; print maximum.reduce(a).dtype; '|u1' '<u4' uint16 behaves similarly, but none of the others seem to involve a conversion (with the possible exception, in SVN, of int32 -> float, possibly only for add.reduce). Thanks, A. M. Archibald

2 1