[Numpy-discussion] Numarray 0.5
Todd Miller
jmiller at stsci.edu
Tue May 6 15:02:10 EDT 2003
On Tue, 2003-05-06 at 08:24, Peter Verveer wrote:
> Hi All,
>
> I found the following problems after testing my software with numarray 0.5:
>
> 1) Following works fine if both a and b are arrays:
>
> >>> a = array([2])
> >>> b = array([1, 2])
> >>> print a + b
> [3 4]
>
> However, if b is an python sequence:
>
> >>> a = array([2])
> >>> b = [1, 2]
> >>> print a + b
> [3]
>
> Apparently broadcasting does not work with python sequeces anymore. This used
> to work fine in version 0.4. Is this a bug?
Yes, unfortunately. Thanks for reporting it!
>
> 2) It is not possible to compare an array type object to the 'Any' object:
>
> >>> Float64 == Any
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File "/usr/local/lib/python2.2/site-packages/numarray/numerictypes.py", line
> 112, in __cmp__
> return (genericTypeRank.index(self.name) -
> ValueError: list.index(x): x not in list
>
> I am not sure if this is a bug, or intended behaviour, but the possibilty to
> compare an array type object to 'Any' would be very useful for me.
>
'Any' grew up from the C-API, rather than down from the Python design,
so it's not very well thought out. Right now, it is a placeholder used
to mark arrays with undefined types and to indicate "no type constraint"
in C API calls. In normal contexts, you can't make an array of type
'Any'. I think there are two reasonable behaviors for comparisons with
'Any', both used in C. The first behavior is literal comparison; here
comparison to Any would generally return "not equal". The second
behavior is wild-card matching; here, comparison to Any would generally
return "equal". Which makes sense to you? How do you want to use
this?
> 3) The NA_typeNoToTypeObject() function fails if it is called before any
> arrays are created. It looks to me as if the pNumType array in
> libnumarraymodule.c is not initialized until an array is created. I don't
> know if any other functions are affected in the same way. Could this be
> fixed?
Yes. This is fixed now in CVS. Thanks again!
>
> Cheers, Peter
>
> --
> Dr. Peter J. Verveer
> Cell Biology and Cell Biophysics Programme
> EMBL
> Meyerhofstrasse 1
> D-69117 Heidelberg
> Germany
> Tel. : +49 6221 387245
> Fax : +49 6221 387242
> Email: Peter.Verveer at embl-heidelberg.de
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
--
Todd Miller jmiller at stsci.edu
STSCI / ESS / SSB
More information about the NumPy-Discussion
mailing list