The subject line contains what I consider to be an invalid range expression. Numarray, now and always, reacts badly to it. Currently, numarray tries to allocate a multi-gigabyte array. In the past, it has dumped core. The question is, what should it do? 1. raise ValueError, "Invalid negative range expression" (my +1) 2. zeros((0,), 'l') (Numeric does this) Is there a good justification to keep the existing Numeric behavior? Any other suggestions? Todd
On Mon, 7 Oct 2002, Todd Miller wrote:
The subject line contains what I consider to be an invalid range expression. Numarray, now and always, reacts badly to it. Currently, numarray tries to allocate a multi-gigabyte array. In the past, it has dumped core.
The question is, what should it do?
1. raise ValueError, "Invalid negative range expression" (my +1) 2. zeros((0,), 'l') (Numeric does this)
Is there a good justification to keep the existing Numeric behavior? Any other suggestions?
Does Numarray support empty arrays? If yes, I'd vote for Python behavior:
range(-10) []
Otherwise, the case 1. Hmm, according to Numeric.arange docs, "arange is just like range() except it returns an array whose type can be specified ...". But given example shows that there are other (undocumented?) exceptions when comparing arange and range. Pearu
Pearu Peterson wrote:
On Mon, 7 Oct 2002, Todd Miller wrote:
The subject line contains what I consider to be an invalid range expression. Numarray, now and always, reacts badly to it. Currently, numarray tries to allocate a multi-gigabyte array. In the past, it has dumped core.
The question is, what should it do?
1. raise ValueError, "Invalid negative range expression" (my +1) 2. zeros((0,), 'l') (Numeric does this)
Is there a good justification to keep the existing Numeric behavior? Any other suggestions?
Does Numarray support empty arrays? If yes, I'd vote for Python behavior:
Numarray has no problem with empty arrays so both choices are easy to implement. It apparently has a different repr (than Numeric) for "nothing" which is: array([]) Currently the tally is +2 exception, +1 Numeric-compatible. I'll probably just implement it at COB today, before I forget. Thanks for voting Todd
On Mon, 7 Oct 2002, Todd Miller wrote:
The subject line contains what I consider to be an invalid range expression. Numarray, now and always, reacts badly to it. Currently, numarray tries to allocate a multi-gigabyte array. In the past, it has dumped core.
The question is, what should it do?
1. raise ValueError, "Invalid negative range expression" (my +1) +1
I didn't realize Numeric behaved badly in this area. -Travis
Travis Oliphant wrote:
On Mon, 7 Oct 2002, Todd Miller wrote:
The subject line contains what I consider to be an invalid range expression. Numarray, now and always, reacts badly to it. Currently, numarray tries to allocate a multi-gigabyte array. In the past, it has dumped core.
The question is, what should it do?
1. raise ValueError, "Invalid negative range expression" (my +1)
+1
I didn't realize Numeric behaved badly in this area.
-Travis
I replied to this earlier, but I may have forgotten to reply-all,
because I never saw my response.
Anyway, I don't think Numeric has a problem with
arange(
On Mon, 7 Oct 2002, Todd Miller wrote:
Pearu Peterson wrote:
On Mon, 7 Oct 2002, Todd Miller wrote:
The subject line contains what I consider to be an invalid range expression. Numarray, now and always, reacts badly to it. Currently, numarray tries to allocate a multi-gigabyte array. In the past, it has dumped core.
The question is, what should it do?
1. raise ValueError, "Invalid negative range expression" (my +1) 2. zeros((0,), 'l') (Numeric does this)
Is there a good justification to keep the existing Numeric behavior? Any other suggestions?
Does Numarray support empty arrays? If yes, I'd vote for Python behavior:
Numarray has no problem with empty arrays so both choices are easy to implement. It apparently has a different repr (than Numeric) for "nothing" which is:
array([])
Hmm, so it means that Numeric.arange is consistent with Python range after all. Then I'd like to change my vote from exception to array([]) (if it is not too late). Rationale: sometimes using range(i1) + range(i2) + range(i3) can save lots of code if the indices i1,i2,i3 can also be negative with the meaning that the resulting lists are then empty. If using arange, then the above would be equivalent to concatenate((arange(i1),arange(i2),arange(i3))) or concatenate(map(arange,[i1,i2,i3])) for short. Now, if arange would raise an exception if one of i1,i2,i3 is negative, then the above would not work without checking i1,i2,i3 first. And I find that bad because additional (read: meaningless) code is needed. Pearu
Pearu Peterson wrote:
On Mon, 7 Oct 2002, Todd Miller wrote:
Pearu Peterson wrote:
On Mon, 7 Oct 2002, Todd Miller wrote:
The subject line contains what I consider to be an invalid range expression. Numarray, now and always, reacts badly to it. Currently, numarray tries to allocate a multi-gigabyte array. In the past, it has dumped core.
The question is, what should it do?
1. raise ValueError, "Invalid negative range expression" (my +1) 2. zeros((0,), 'l') (Numeric does this)
Is there a good justification to keep the existing Numeric behavior? Any other suggestions?
Does Numarray support empty arrays? If yes, I'd vote for Python behavior:
Numarray has no problem with empty arrays so both choices are easy to implement. It apparently has a different repr (than Numeric) for "nothing" which is:
array([])
Hmm, so it means that Numeric.arange is consistent with Python range after all. Then I'd like to change my vote from exception to array([]) (if it is not too late).
Rationale: sometimes using
range(i1) + range(i2) + range(i3)
can save lots of code if the indices i1,i2,i3 can also be negative with the meaning that the resulting lists are then empty. If using arange, then the above would be equivalent to
concatenate((arange(i1),arange(i2),arange(i3)))
or
concatenate(map(arange,[i1,i2,i3]))
for short. Now, if arange would raise an exception if one of i1,i2,i3 is negative, then the above would not work without checking i1,i2,i3 first. And I find that bad because additional (read: meaningless) code is needed.
Pearu
Hi Pearu, Well, as fate would have it, your vote was already mis-cast in favor of Numeric compatability. However, you've changed my mind, so I'm changing *my* vote. That leaves the current vote at +2 "raise", +3 "compatible", so barring any new votes, I'll check it in as Numeric compatible (returning an empty range) at COB today. Todd -- Todd Miller jmiller@stsci.edu STSCI / SSB
participants (4)
-
Pearu Peterson -
Pearu Peterson -
Todd Miller -
Travis Oliphant