[Numpy-discussion] Numarray 0.5

[Todd Miller]

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