ENH: delete and insert generalization and speed improvements #452

Merged
merged 6 commits into from Apr 11, 2013

Conversation

Projects
None yet
4 participants
@seberg
Member

seberg commented Sep 21, 2012

This allows boolean indices for both delete and insert, improves their speed and makes them work with negative indices and in the case of insert unsorted indices as well as some smaller changes.

np.delete has some serious issues and the first two things are a serious bugs IMO since it creates plain wrong results (and its not documented):

  1. When using slices with negative strides, it does not work (best case) or give even wrong results.
  2. When using an index array, it will simply ignore negative indexes.
  3. The fact that it uses setdiff1d makes it unnecessarily slow and bloated compared to boolean indexing based methods.

This PR fixes these issues. There is one more behaviour change, and that is that out of bound indices now will raise an error, however I consider that a feature. For the negative steps, I guess another option would be to just explicitely raise an error.

I will add tests if this is wanted, and I honestly think this is a very necessary clean up of the delete function.

Example for the complete wrong results:

In [1]: arr = np.arange(4)

In [2]: set(arr) - set(arr[1::-1])
Out[2]: set([2, 3])

In [3]: np.delete(arr, np.s_[1::-1])
Out[3]: array([3, 3])
@teoliphant

This comment has been minimized.

Show comment Hide comment
@teoliphant

teoliphant Oct 10, 2012

Owner

This looks like a nice improvement. This needs a test to be merged.

Owner

teoliphant commented Oct 10, 2012

This looks like a nice improvement. This needs a test to be merged.

@seberg

This comment has been minimized.

Show comment Hide comment
@seberg

seberg Oct 11, 2012

Member

I have added tests and fixed a small bug from the old version, but also changed it a bit:

  1. Made boolean indexes to work as boolean indexes (not speed optimized but no surprises, though it was documented to not support bools, so not sure if this is right).
  2. Some corner cases like [[2,3], [3,4]] worked before but now fails (This is for: delete(arr, obj, axis=1) fails where when arr[:,obj,:] works since arr1d[obj] fails). I could probably work around this if you want.
  3. Changed the errors a bit so they are more similar to what np.take, etc. give. (ValueError -> IndexError for out of bounds index)

I mostly like this approach since it now is the exact inverse of arr[obj] for 1D arrays. But maybe it would be better to treat bools as ints at the moment (check explicitely for bool or (bool,)) and raise a DeprectionWarning then to change later?

Member

seberg commented Oct 11, 2012

I have added tests and fixed a small bug from the old version, but also changed it a bit:

  1. Made boolean indexes to work as boolean indexes (not speed optimized but no surprises, though it was documented to not support bools, so not sure if this is right).
  2. Some corner cases like [[2,3], [3,4]] worked before but now fails (This is for: delete(arr, obj, axis=1) fails where when arr[:,obj,:] works since arr1d[obj] fails). I could probably work around this if you want.
  3. Changed the errors a bit so they are more similar to what np.take, etc. give. (ValueError -> IndexError for out of bounds index)

I mostly like this approach since it now is the exact inverse of arr[obj] for 1D arrays. But maybe it would be better to treat bools as ints at the moment (check explicitely for bool or (bool,)) and raise a DeprectionWarning then to change later?

@njsmith

View changes

numpy/lib/function_base.py
@@ -3379,13 +3379,14 @@ def meshgrid(*xi, **kwargs):
def delete(arr, obj, axis=None):
"""
- Return a new array with sub-arrays along an axis deleted.
+ Return a new array with sub-arrays along an axis deleted. This behaves much
+ like the inverse of arr[obj].

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Oct 11, 2012

Owner

The word "inverse" here is confusing -- this doesn't undo an indexing operation. Maybe something like "This is the opposite of arr[obj] -- it returns all of the items that arr[obj] would not return."

@njsmith

njsmith Oct 11, 2012

Owner

The word "inverse" here is confusing -- this doesn't undo an indexing operation. Maybe something like "This is the opposite of arr[obj] -- it returns all of the items that arr[obj] would not return."

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Oct 11, 2012

Owner

...though if comparing to arr[obj], we should make clear that this implements 1d indexing only, since that's a pretty substantial difference.

@njsmith

njsmith Oct 11, 2012

Owner

...though if comparing to arr[obj], we should make clear that this implements 1d indexing only, since that's a pretty substantial difference.

@njsmith

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Oct 11, 2012

Owner

Regarding bools: To make sure I understand, the behaviour right now is that bools are treated as 0, 1 ints? That does seem like a poor idea, so we should switch either now or later; question is whether anyone is depending on it. I don't have a strong intuition about whether this falls on the trivial change side of the line or not. It might be better to be cautious and just raise a FutureWarning for now. (Note DeprecationWarning is only for changes which go from working to raising an error; FutureWarning is for changes which alter working code to produce a different result.)

Owner

njsmith commented Oct 11, 2012

Regarding bools: To make sure I understand, the behaviour right now is that bools are treated as 0, 1 ints? That does seem like a poor idea, so we should switch either now or later; question is whether anyone is depending on it. I don't have a strong intuition about whether this falls on the trivial change side of the line or not. It might be better to be cautious and just raise a FutureWarning for now. (Note DeprecationWarning is only for changes which go from working to raising an error; FutureWarning is for changes which alter working code to produce a different result.)

@seberg

This comment has been minimized.

Show comment Hide comment
@seberg

seberg Oct 11, 2012

Member

@njsmith yes, they are treated as ints right now. Will wait a bit if more comes up, then do those changes. Just noticed that the slow path is taken for the correctly working [slice(1,3,1)] or a size 1 sequence (arr[[slice(1,3,1)]] works too), will think about it, but I don't think its a big issue.

Member

seberg commented Oct 11, 2012

@njsmith yes, they are treated as ints right now. Will wait a bit if more comes up, then do those changes. Just noticed that the slow path is taken for the correctly working [slice(1,3,1)] or a size 1 sequence (arr[[slice(1,3,1)]] works too), will think about it, but I don't think its a big issue.

@seberg

This comment has been minimized.

Show comment Hide comment
@seberg

seberg Oct 13, 2012

Member

Sorry for all that rebasing, but I noticed that insert is similarly broken and because of that wanted to add it here as well. I have done some small changes (but some reordering that makes it a bit bad readable) to delete but mostly I fixed up insert. This means allowing boolean indices there too. While boolean indices may not make too much sense for insert, I think that if we allow slice objects we should also allow bools. Other then that this fixes negative and unsorted indices as well as avoids the unnecessary set operation. Insert now enforces a 1D array (other dimensions simply do not make sense, but used to work as long as they were (1x1...xN)).

I will leave it to you to add FutureWarnings and/or the old behavior to the booleans which I think is the only possible pitfall (unless you think deleting out of range items should work). Or notes that it does not work for some cases on old versions? After running down the wrong road for fixing insert I am quite sick of it :).

Edit: This fixes a regression in 1.7 introduced in aed8fc5 and not fixed by 8460514 namely that it can give different results from before if axis!=0 instead of only working in new cases, since len(values) must be values.shape[axis] for consistency (after ndmin=arr.ndim).

Member

seberg commented Oct 13, 2012

Sorry for all that rebasing, but I noticed that insert is similarly broken and because of that wanted to add it here as well. I have done some small changes (but some reordering that makes it a bit bad readable) to delete but mostly I fixed up insert. This means allowing boolean indices there too. While boolean indices may not make too much sense for insert, I think that if we allow slice objects we should also allow bools. Other then that this fixes negative and unsorted indices as well as avoids the unnecessary set operation. Insert now enforces a 1D array (other dimensions simply do not make sense, but used to work as long as they were (1x1...xN)).

I will leave it to you to add FutureWarnings and/or the old behavior to the booleans which I think is the only possible pitfall (unless you think deleting out of range items should work). Or notes that it does not work for some cases on old versions? After running down the wrong road for fixing insert I am quite sick of it :).

Edit: This fixes a regression in 1.7 introduced in aed8fc5 and not fixed by 8460514 namely that it can give different results from before if axis!=0 instead of only working in new cases, since len(values) must be values.shape[axis] for consistency (after ndmin=arr.ndim).

seberg added a commit to seberg/numpy that referenced this pull request Oct 23, 2012

BUG: Avoid regression in np.insert for axis!=0 or None
This avoids a regression with insert failing where it worked
before when inserting a full array with a scalar and axis!=0.
See also Issue #378 and #452.
@charris

This comment has been minimized.

Show comment Hide comment
@charris

charris Nov 25, 2012

Owner

Re: FutureWarning, I'd be inclined to think this is more like a bug fix as current behavior is at odds with the usual use of booleans for indexing. However, it is possible that someone somewhere is actually using a boolean array as integer indices and they need to informed of the change. Almost no one reads release notes, so maybe raise a 'ChangedBehavior' warning and put a note in the documentation summary following a .. versionadded:: 1.8.0 flag.

Owner

charris commented Nov 25, 2012

Re: FutureWarning, I'd be inclined to think this is more like a bug fix as current behavior is at odds with the usual use of booleans for indexing. However, it is possible that someone somewhere is actually using a boolean array as integer indices and they need to informed of the change. Almost no one reads release notes, so maybe raise a 'ChangedBehavior' warning and put a note in the documentation summary following a .. versionadded:: 1.8.0 flag.

@charris

This comment has been minimized.

Show comment Hide comment
@charris

charris Nov 25, 2012

Owner

This is really the sort of thing that can only be tested in a release candidate. Thinking it over, I'm inclined to have a FutureWarning for boolean arrays in 1.7.0 so that this can go into 1.8.

Owner

charris commented Nov 25, 2012

This is really the sort of thing that can only be tested in a release candidate. Thinking it over, I'm inclined to have a FutureWarning for boolean arrays in 1.7.0 so that this can go into 1.8.

@seberg

This comment has been minimized.

Show comment Hide comment
@seberg

seberg Nov 28, 2012

Member

That sounds good to me. Ideally nobody will actually see the warning and then its unnecessary to worry about accidentally breaking something. Unless someone argues that it should not support boolean indexes, but as it also supports slices I think that is counter intuitive.

Member

seberg commented Nov 28, 2012

That sounds good to me. Ideally nobody will actually see the warning and then its unnecessary to worry about accidentally breaking something. Unless someone argues that it should not support boolean indexes, but as it also supports slices I think that is counter intuitive.

@charris

This comment has been minimized.

Show comment Hide comment
@charris

charris Dec 4, 2012

Owner

Do you want to put that warning in? I can do it if needed.

Owner

charris commented Dec 4, 2012

Do you want to put that warning in? I can do it if needed.

@seberg

This comment has been minimized.

Show comment Hide comment
@seberg

seberg Dec 4, 2012

Member

If needed :)... would be nice if you can, I will clean up this stuff and add documentation soon.

Member

seberg commented Dec 4, 2012

If needed :)... would be nice if you can, I will clean up this stuff and add documentation soon.

@seberg

View changes

numpy/lib/function_base.py
@@ -3439,35 +3451,28 @@ def delete(arr, obj, axis=None):
arr = arr.ravel()
ndim = arr.ndim;
axis = ndim-1;
- if ndim == 0:

This comment has been minimized.

Show comment Hide comment
@seberg

seberg Dec 4, 2012

Member

This seemed nonsense to me, you cannot delete something along an axis which is not there in the first place... why silently return the array in this case? But maybe I should document it, or someone knows that this makes sense for anyone... Similar goes for np.insert, though there the special case makes maybe a little more sense.

@seberg

seberg Dec 4, 2012

Member

This seemed nonsense to me, you cannot delete something along an axis which is not there in the first place... why silently return the array in this case? But maybe I should document it, or someone knows that this makes sense for anyone... Similar goes for np.insert, though there the special case makes maybe a little more sense.

@seberg

This comment has been minimized.

Show comment Hide comment
@seberg

seberg Dec 4, 2012

Member

Please feel free to rip the doc apart... I noticed that maybe the 1.7. doc or at least release should maybe mention that duplicate insertion is possible for scalars there. I did not mention fixes of unsorted arrays or negative slices for insert/delete since I consider that a bug fix. Correct?

Member

seberg commented Dec 4, 2012

Please feel free to rip the doc apart... I noticed that maybe the 1.7. doc or at least release should maybe mention that duplicate insertion is possible for scalars there. I did not mention fixes of unsorted arrays or negative slices for insert/delete since I consider that a bug fix. Correct?

@seberg

This comment has been minimized.

Show comment Hide comment
@seberg

seberg Jan 25, 2013

Member

OK, I cleaned this up mostly I think, though unfortunately the commit history was not useful, so its all squashed. I think this should maybe warn about negative indices not being ignored any more (I consider that a bug, but that does not mean someone thought it was a feature...). What would be the right warning for that? The most careful would be to check, discard them for now and emit a FutureWarning.

Other then that, here again the overview of changes from the commit message:

There were several smaller to larger problems for these two functions,
that this addresses:

  • delete did not handle out of bound values graciously (ignoring negative
    ones)
  • both were unnecessarily slow due to use of sets
  • insert did not handle unsorted indices correctly

Further changes:

  • Add FutureWarning for boolean obj, so it can be handled similar to a
    boolean mask with indexing.
  • Add FutureWarning to remove inconsistent special cases for 0-d arrays
    (neither insertion nor deletion along an axis make sense for a scalar)
  • Allow insertion of an array with more then one element along axis when
    obj is a sequence with a single item. (i.e. array([1])).
  • Reintroduce speed optimization for scalar in insert that existed in 1.6.
Member

seberg commented Jan 25, 2013

OK, I cleaned this up mostly I think, though unfortunately the commit history was not useful, so its all squashed. I think this should maybe warn about negative indices not being ignored any more (I consider that a bug, but that does not mean someone thought it was a feature...). What would be the right warning for that? The most careful would be to check, discard them for now and emit a FutureWarning.

Other then that, here again the overview of changes from the commit message:

There were several smaller to larger problems for these two functions,
that this addresses:

  • delete did not handle out of bound values graciously (ignoring negative
    ones)
  • both were unnecessarily slow due to use of sets
  • insert did not handle unsorted indices correctly

Further changes:

  • Add FutureWarning for boolean obj, so it can be handled similar to a
    boolean mask with indexing.
  • Add FutureWarning to remove inconsistent special cases for 0-d arrays
    (neither insertion nor deletion along an axis make sense for a scalar)
  • Allow insertion of an array with more then one element along axis when
    obj is a sequence with a single item. (i.e. array([1])).
  • Reintroduce speed optimization for scalar in insert that existed in 1.6.
@charris

This comment has been minimized.

Show comment Hide comment
@charris

charris Mar 2, 2013

Owner

Ping travisbot.

Owner

charris commented Mar 2, 2013

Ping travisbot.

@njsmith

View changes

doc/release/1.8.0-notes.rst
+Insert allows multiple insertions at single scalar since numpy 1.7. and now
+further allows this for a one item sequence. There are subtle differences
+because the scalar expects N arrays, while the sequence expects size N along
+the axis.

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Mar 6, 2013

Owner
Several changes to np.insert and np.delete:
* Previously, negative indices and indices that pointed past the end of the array were simply ignored. Now, they will be treated like normal indexing treats them -- negative indices will wrap around, and out-of-bound indices will generate an error.
* Previously, boolean indices were treated as if they were integers (always referring to either the 0th or 1st item in the array). In the future, they will be treated as masks. In this release, they raise a FutureWarning warning of this coming change.
* [I don't really understand the last point, maybe give an example?]

Also, is the first point actually true? Or are we raising a FutureWarning for negative and zero indices, and will do the actual change later? (That would probably be best.)

@njsmith

njsmith Mar 6, 2013

Owner
Several changes to np.insert and np.delete:
* Previously, negative indices and indices that pointed past the end of the array were simply ignored. Now, they will be treated like normal indexing treats them -- negative indices will wrap around, and out-of-bound indices will generate an error.
* Previously, boolean indices were treated as if they were integers (always referring to either the 0th or 1st item in the array). In the future, they will be treated as masks. In this release, they raise a FutureWarning warning of this coming change.
* [I don't really understand the last point, maybe give an example?]

Also, is the first point actually true? Or are we raising a FutureWarning for negative and zero indices, and will do the actual change later? (That would probably be best.)

This comment has been minimized.

Show comment Hide comment
@seberg

seberg Mar 6, 2013

Member

Yes, I will change it to a future warning for negative indices. What about out of bound indices, an error is OK in that case right?

@seberg

seberg Mar 6, 2013

Member

Yes, I will change it to a future warning for negative indices. What about out of bound indices, an error is OK in that case right?

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Mar 6, 2013

Owner

I guess that one's a judgement call. I lean towards it being okay to just
make those be an error, but others might disagree...

On Wed, Mar 6, 2013 at 10:20 PM, seberg notifications@github.com wrote:

In doc/release/1.8.0-notes.rst:

@@ -54,6 +54,13 @@ The function np.take now allows 0-d arrays as indices.

The separate compilation mode is now enabled by default.

+The functions np.insert and np.delete now handle out of bound indices like
+normal indexing instead of ignoring them, this strongly affects negative ones.
+FutureWarnings will be raised for boolean indices which will change behaviour.
+Insert allows multiple insertions at single scalar since numpy 1.7. and now
+further allows this for a one item sequence. There are subtle differences
+because the scalar expects N arrays, while the sequence expects size N along
+the axis.

Yes, I will change it to a future warning for negative indices. What about
out of bound indices, an error is OK in that case right?


Reply to this email directly or view it on GitHubhttps://github.com/numpy/numpy/pull/452/files#r3270944
.

@njsmith

njsmith Mar 6, 2013

Owner

I guess that one's a judgement call. I lean towards it being okay to just
make those be an error, but others might disagree...

On Wed, Mar 6, 2013 at 10:20 PM, seberg notifications@github.com wrote:

In doc/release/1.8.0-notes.rst:

@@ -54,6 +54,13 @@ The function np.take now allows 0-d arrays as indices.

The separate compilation mode is now enabled by default.

+The functions np.insert and np.delete now handle out of bound indices like
+normal indexing instead of ignoring them, this strongly affects negative ones.
+FutureWarnings will be raised for boolean indices which will change behaviour.
+Insert allows multiple insertions at single scalar since numpy 1.7. and now
+further allows this for a one item sequence. There are subtle differences
+because the scalar expects N arrays, while the sequence expects size N along
+the axis.

Yes, I will change it to a future warning for negative indices. What about
out of bound indices, an error is OK in that case right?


Reply to this email directly or view it on GitHubhttps://github.com/numpy/numpy/pull/452/files#r3270944
.

@njsmith

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Mar 6, 2013

Owner

Assuming we do add these FutureWarnings, we need to file a 1.9 bug reminding us to check on them.

Owner

njsmith commented Mar 6, 2013

Assuming we do add these FutureWarnings, we need to file a 1.9 bug reminding us to check on them.

@njsmith

View changes

numpy/lib/function_base.py
@@ -3381,7 +3380,8 @@ def meshgrid(*xi, **kwargs):
def delete(arr, obj, axis=None):
"""
- Return a new array with sub-arrays along an axis deleted.
+ Return a new array with sub-arrays along an axis deleted. For a one
+ dimensional array, this returns those entries not returned by `arr[obj,]`.

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Mar 6, 2013

Owner

Do you mean arr[obj,] or arr[obj]? (Aren't those the same? The , is confusing if so.)

@njsmith

njsmith Mar 6, 2013

Owner

Do you mean arr[obj,] or arr[obj]? (Aren't those the same? The , is confusing if so.)

This comment has been minimized.

Show comment Hide comment
@seberg

seberg Mar 6, 2013

Member

Dunno, back then I think, I thought about some weird list cases. Doesn't matter... (and probably doesn't even apply to the 1-d case)

@seberg

seberg Mar 6, 2013

Member

Dunno, back then I think, I thought about some weird list cases. Doesn't matter... (and probably doesn't even apply to the 1-d case)

@njsmith

View changes

numpy/lib/function_base.py
@@ -3440,34 +3448,35 @@ def delete(arr, obj, axis=None):
ndim = arr.ndim;
axis = ndim-1;
if ndim == 0:
+ warnings.warn("in the future the special handleing of scalars "

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Mar 6, 2013

Owner

Spelling: "handling"

This message is somewhat confusing as well, since most people won't know what "special handling" is being talked about. Maybe just say "In the future, passing a scalar or 0-d array as the first argument of delete() will be an error"?

@njsmith

njsmith Mar 6, 2013

Owner

Spelling: "handling"

This message is somewhat confusing as well, since most people won't know what "special handling" is being talked about. Maybe just say "In the future, passing a scalar or 0-d array as the first argument of delete() will be an error"?

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Mar 6, 2013

Owner

Also, if I understand right, this can just be a DeprecationWarning, since all it will do is turn currently valid code into an error.

@njsmith

njsmith Mar 6, 2013

Owner

Also, if I understand right, this can just be a DeprecationWarning, since all it will do is turn currently valid code into an error.

@njsmith

View changes

numpy/lib/function_base.py
@@ -3584,6 +3655,9 @@ def insert(arr, obj, values, axis=None):
ndim = arr.ndim
axis = ndim-1
if (ndim == 0):
+ warnings.warn("in the future the special handleing of scalars "
+ "will be removed from insert and raise an error",
+ FutureWarning)

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Mar 6, 2013

Owner

Same comments as above apply.

@njsmith

njsmith Mar 6, 2013

Owner

Same comments as above apply.

@njsmith

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Mar 6, 2013

Owner

We should forward-port the test case from #2697.

Owner

njsmith commented Mar 6, 2013

We should forward-port the test case from #2697.

@charris

This comment has been minimized.

Show comment Hide comment
@charris

charris Apr 1, 2013

Owner

@seberg There are test failures, but they look fixable.

Owner

charris commented Apr 1, 2013

@seberg There are test failures, but they look fixable.

@seberg

This comment has been minimized.

Show comment Hide comment
@seberg

seberg Apr 1, 2013

Member

OK, addressed those failures, added tests and made out of bound and negative index changes a Deprecation and FutureWarning respectively...

Member

seberg commented Apr 1, 2013

OK, addressed those failures, added tests and made out of bound and negative index changes a Deprecation and FutureWarning respectively...

@charris

This comment has been minimized.

Show comment Hide comment
@charris

charris Apr 1, 2013

Owner

@seberg Looks like some python3 problems.

Owner

charris commented Apr 1, 2013

@seberg Looks like some python3 problems.

@seberg

This comment has been minimized.

Show comment Hide comment
@seberg

seberg Apr 1, 2013

Member

Hmmm, I abused xrange to calculate its length/start/stop (the slice object doesn't fix stop for cases like range(10)[:5:100]). Is there a good way to get the iterator in 2.x and 3.x?

Member

seberg commented Apr 1, 2013

Hmmm, I abused xrange to calculate its length/start/stop (the slice object doesn't fix stop for cases like range(10)[:5:100]). Is there a good way to get the iterator in 2.x and 3.x?

@charris

This comment has been minimized.

Show comment Hide comment
@charris

charris Apr 1, 2013

Owner

You ran into the common code python2 python3 project, the xrange fixer is no longer applied. There is no xrange in python3, range is an iterator and replaces it, so just always use range. I doubt it makes much difference for most things. If you feel that you absolutely need xrange you can import it as range when python version < 3.

Owner

charris commented Apr 1, 2013

You ran into the common code python2 python3 project, the xrange fixer is no longer applied. There is no xrange in python3, range is an iterator and replaces it, so just always use range. I doubt it makes much difference for most things. If you feel that you absolutely need xrange you can import it as range when python version < 3.

@njsmith

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Apr 11, 2013

Owner

I think this is ready to merge, but it has conflicts?

Owner

njsmith commented Apr 11, 2013

I think this is ready to merge, but it has conflicts?

seberg added some commits Oct 11, 2012

ENH: larger fixes for np.delete and np.insert functions
There were several smaller to larger problems for these two functions,
that this addresses:
  * delete did not handle out of bound values graciously (ignoring negative
    ones)
  * both were unnecessarily slow due to use of sets
  * insert did not handle unsorted indices correctly

Further changes:
  * Add FutureWarning for boolean obj, so it can be handled similar to a
    boolean mask with indexing.
  * Add FutureWarning to remove inconsistent special cases for 0-d arrays
    (neither insertion nor deletion along an axis make sense for a scalar)
  * Allow insertion of an array with more then one element along axis when
    obj is a sequence with a single item. (i.e. array([1])).
  * Reintroduce speed optimization for scalar in insert that existed in 1.6.
FIX: rename xrange to range in python 2
np.delete abuses range to calculate start/stop/step and len. This
would create potentially large intermediates if it was a list, so
for numpy/lib/function_base.py and python < 3, use range = xrange.
@seberg

This comment has been minimized.

Show comment Hide comment
@seberg

seberg Apr 11, 2013

Member

Rebased.

Member

seberg commented Apr 11, 2013

Rebased.

njsmith added a commit that referenced this pull request Apr 11, 2013

Merge pull request #452 from seberg/enhdel
ENH: delete and insert generalization and speed improvements

@njsmith njsmith merged commit b9232f3 into numpy:master Apr 11, 2013

1 check passed

default The Travis build passed
Details

@seberg seberg deleted the seberg:enhdel branch Dec 3, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment