Mailman 3 April 2006 - NumPy-Discussion

Re: ***[Possible UCE]*** [SciPy-user] Regarding what "where" returns
by Travis Oliphant 13 Apr '06

13 Apr '06

Perry Greenfield wrote: >We've noticed that in numpy that the where() function behaves >differently than for numarray. In numarray, where() (when used with a >mask or condition array only) always returns a tuple of index arrays, >even for the 1D case whereas numpy returns an index array for the 1D >case and a tuple for higher dimension cases. While the tuple is a >annoyance for users when they want to manipulate the 1D case, the >benefit is that one always knows that where is returning a tuple, and >thus can write code accordingly. The problem with the current numpy >behavior is that it requires special case testing to see which kind >return one has before manipulating if you aren't certain of what the >dimensionality of the argument is going to be. > > I went ahead and made this change to the code. The nonzero function still behaves as before (and in fact only works for 1-d arrays as it did in Numeric). The where(condition) function works the same as condition.nonzero() and both always return a tuple. I had to change exactly one piece of code that used the new where syntax. This does represent a code breakage with the where syntax (but only if you used the newer, numarray-introduced usage). I think this is a small-enough segment that we can make this change. -Travis

3 2

Segfault when indexing on second or higher dimension with list or tuple
by Albert Strasheim 13 Apr '06

13 Apr '06

Hello all, The following segfault bug was discovered in NumPy 0.9.7.2348 by someone at our Python workshop: import numpy as N F = N.zeros((1,1)) F[:,[0]] = 0 The following also segfaults: F[:,(0,)] = 0 Something seems to go wrong when one uses a tuple or a list to index into a NumPy array on the second or higher dimension, since the following code works: F = N.zeros((1,)) F[[0]] = 0 The Trac ticket is here: http://projects.scipy.org/scipy/numpy/ticket/59 If someone gets around to fixing this, please include some test cases. Thanks! Regards, Albert

2 3

index objects are not broadcastable to a single shape
by Simon Burton 13 Apr '06

13 Apr '06

This must be up there with the most useless confusing error messages: >>> a=numpy.array([1,2,3]) >>> b=numpy.array([1,2,3,4]) >>> a*b Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: index objects are not broadcastable to a single shape >>> Simon. -- Simon Burton, B.Sc. Licensed PO Box 8066 ANU Canberra 2601 Australia Ph. 61 02 6249 6940 http://arrowtheory.com

3 3

Re: your news
by Socorro Tejeda 12 Apr '06

12 Apr '06

A M B r I E N X A q N A X C I A f L I S V o I A G R A V b A L I U M http://www.korbahcut.com

1 0

Massive differences in numpy vs. numeric string handling
by Jeremy Gore 12 Apr '06

12 Apr '06

In Numeric: Numeric.array('test') -> array([t, e, s, t],'c'); shape = (4,) Numeric.array(['test','two']) -> array([[t, e, s, t], [t, w, o, ]],'c') but in numpy: numpy.array('test') -> array('test', dtype='|S4'); shape = () numpy.array('test','S1') -> array('t', dtype='|S1'); shape = () in fact you have to do an extra list cast: numpy.array(list('test'),'S1') -> array([t, e, s, t], dtype='|S1'); shape = (4,) to get the desired result. I don't think this is very pythonic, as strings are fully indexable and iterable objects. Furthermore, converting/treating a string as an array of characters is a very common thing. convertcode.py would not appear to convert this part of the code correctly either. Also, the use of quotes in the shape () array but not in the shape (4,) array is inconsistent. I realize the ability to use strings of arbitrary length as array elements is important in numpy, but there really should be a more natural option to convert/cast strings as character arrays. Also, unlike Numeric.equal and 'c' arrays, numpy.equal cannot compare '|S1' arrays or presumably other strings for equality, although this is a very useful comparison to make. For the record, I have used the Numeric (and to a lesser degree the numarray) module extensively in bioinformatics applications for its speed and brevity. Jeremy

5 6

AD运用EXCEL促进市场营销与财务管理
by 4月15-16上海/21-22深圳 12 Apr '06

12 Apr '06

1 0

Rash Guard
by winnie 12 Apr '06

12 Apr '06

The products name :Rash Guard The price :USD4.50/pc (with shiiping cost) The qty : 200pcs The size :XL,L,M,and S see the attached www.rmb.com.hk Thanks, winnie

1 0

[SciPy-user] Regarding what "where" returns
by Travis Oliphant 12 Apr '06

12 Apr '06

Perry Greenfield wrote: >We've noticed that in numpy that the where() function behaves >differently than for numarray. In numarray, where() (when used with a >mask or condition array only) always returns a tuple of index arrays, >even for the 1D case whereas numpy returns an index array for the 1D >case and a tuple for higher dimension cases. While the tuple is a >annoyance for users when they want to manipulate the 1D case, the >benefit is that one always knows that where is returning a tuple, and >thus can write code accordingly. The problem with the current numpy >behavior is that it requires special case testing to see which kind >return one has before manipulating if you aren't certain of what the >dimensionality of the argument is going to be. > > I think this is reasonable. I don't think much thought went in to the current behavior as it simply defaults to the behavior of the nonzero method (where just defaults to nonzero in the circumstances you are describing). The nonzero method has it's behavior because of the nonzero function in Numeric (which only worked with 1-d and returned an array not a tuple). Ideally, I think we should fix the nonzero method and where to have the same behavior (both return tuples --- that's actually what the docstring of nonzero says right now). The nonzero function can be special-cased to index the tuple for backward compatibility. -Travis

1 0

sqrt and divide
by Stefan van der Walt 12 Apr '06

12 Apr '06

Hi all Two quick questions regarding unintuitive numpy behaviour: Why is the square root of -1 not equal to the square root of -1+0j? In [5]: N.sqrt(-1.) Out[5]: nan In [6]: N.sqrt(-1.+0j) Out[6]: 1j Is there an easier way of dividing two scalars than using divide? In [9]: N.divide(1.,0) Out[9]: inf (also In [8]: N.divide(1,0) Out[8]: 0 should probably ruturn inf / nan?) Regards Stéfan

4 5

Seeking articles for special issue on Python and Science and Engineering
by Paul Dubois 12 Apr '06

12 Apr '06

IEEE's magazine, Computing in Science and Engineering (CiSE), has asked me to put together a theme issue on the use of Python in Science and Engineering. I will write an overview to be accompanied by 3-5 articles of a few pages (say 3000 words or so) each. The deadline for manuscripts will be in the Fall and publication early next year. I would like to select articles that show a diverse set of applications or tools, to give our readers a sense of whether or not Python might be useful in their own work. I will tailor the overview to "fill in the holes" a bit since with only a few articles we can't cover everything. Note that these are expository pieces, not research reports. We have a peer-reviewed section for the latter. Think "Scientific American" with respect to level: everybody gets something out of it, maybe a little more for those who know about the area. Please contact me if you are interested in writing such an article. The process is that I work with you on the shape of the article, then you write it, and our editorial staff helps you get it ready for publication. There is no annoying review process except that I am annoying. Ideas for cover art to go with the issue are always welcome. Information about CiSE and our author's guidelines are at computer.org/cise. It has a fairly large readership as such things go. Thanks, Paul Dubois Editor, Scientific Programming Department CiSE

1 0