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? 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. 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? 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@embl-heidelberg.de
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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- Todd Miller jmiller@stsci.edu STSCI / ESS / SSB
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?
I use 'Any' right now in C functions to indicate 'no type constraint'. You could use both literal comparison and wild-card matching behaviour for that, if you want to do this in Python, I think. But maybe one should not do such a thing in Python by comparison to 'Any' at all. Literal comparison is what I generally expect from Python objects, so anything else may just be confusing (at least to me). However, the name 'Any' does suggest the wild-card matching behaviour. Is there specific reason why you exposed 'Any' in python? Maybe it would be better not to expose such a type object since it seems to be a 'special case'. I am starting to think that my use for it at the Python level is not appropiate. For instance, I could easily use 'None' instead, and I think I will do that in the future. You mentioned that 'Any' is really a C-API thing. Unless somebody has a good use for it I would now actually say that it maybe should not be exposed at the Python API level at all... 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@embl-heidelberg.de
On Wed, 2003-05-07 at 05:16, Peter Verveer wrote:
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?
I use 'Any' right now in C functions to indicate 'no type constraint'. You could use both literal comparison and wild-card matching behaviour for that, if you want to do this in Python, I think. But maybe one should not do such a thing in Python by comparison to 'Any' at all.
Literal comparison is what I generally expect from Python objects, so anything else may just be confusing (at least to me). However, the name 'Any' does suggest the wild-card matching behaviour.
Is there specific reason why you exposed 'Any' in python?
Initially it was not exposed. As the API type functions evolved, it made Any less of a special case to expose it.
Maybe it would be better not to expose such a type object since it seems to be a 'special case'. I am starting to think that my use for it at the Python level is not appropiate. For instance, I could easily use 'None' instead, and I think I will do that in the future.
Yes. That's probably what I should have done in C as well: tNone rather than tAny.
You mentioned that 'Any' is really a C-API thing. Unless somebody has a good use for it I would now actually say that it maybe should not be exposed at the Python API level at all...
I agree with this. It might be as simple as renaming it to _Any in Python, but I still hesitate to change this until I have a little more time to think about it. Too often, things go from "bad" to "not so good"... Thanks for the input, Todd
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
Hi All, After I read this thread I thought I would wait a bit before upgrading my numarray (from 0.4) - Are the mentioned fixes available somewhere ? Or actually: Is the CVS version publicly readable and - if so - would you recommend using that ? Thanks, Sebastian Haase ----- Original Message ----- From: "Todd Miller" <jmiller@stsci.edu> To: "Peter Verveer" <verveer@embl-heidelberg.de> Cc: <numpy-discussion@lists.sourceforge.net> Sent: Tuesday, May 06, 2003 3:02 PM Subject: Re: [Numpy-discussion] Numarray 0.5 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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
-- Todd Miller jmiller@stsci.edu STSCI / ESS / SSB
------------------------------------------------------- Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara The only event dedicated to issues related to Linux enterprise solutions www.enterpriselinuxforum.com
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
On Tue, 2003-05-20 at 12:19, Sebastian Haase wrote:
Hi All, After I read this thread I thought I would wait a bit before upgrading my numarray (from 0.4) - numarray-0.6 is probably not far off; if you're on the fence, you might want to sit this out.
Are the mentioned fixes available somewhere ? All of the problems Peter found have been fixed as of yesterday. The fixes are checked into CVS on Source Forge in the numarray component of
However, there is a new API function which I added in response to your last post: NA_NewAllFromBuffer() which enables you to create arrays in C from existing buffer objects rather than just C arrays. Also, I modified setup.py to support independent build and install. Both of these new features are under tested. Let me know how it works out. the numpy project. Instructions for doing an anonymous numarray cvs checkout are here: http://sourceforge.net/cvs/?group_id=1369 These basically say to: % cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/numpy login % cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/numpy co numarray
Or actually: Is the CVS version publicly readable and - if so - would you recommend using that ?
If you check out today, you'll be OK. I tagged "now" as v0_5_2 which will never be "officially released" but which just passed all self-tests under i386-Linux. Todd -- Todd Miller jmiller@stsci.edu STSCI / ESS / SSB
participants (3)
-
Peter Verveer -
Sebastian Haase -
Todd Miller