BUG: handle length-0 axes correctly in ufunc.reduce without identity #323

Merged
merged 1 commit into from Jul 6, 2012

Conversation

Projects
None yet
3 participants
@njsmith
Member

njsmith commented Jun 27, 2012

In numpy 1.6, reduction operations with no identity
(e.g. numpy.maximum) gave an error iff they were asked to reduce a
0-element dimension. This regressed during the 1.7 development cycle,
so that they started giving an error if any dimension had 0
elements, even ones that were not reduced over. Fixes bug #2078.

BUG: handle length-0 axes correctly in ufunc.reduce without identity
In numpy 1.6, reduction operations with no identity
(e.g. numpy.maximum) gave an error iff they were asked to reduce a
0-element dimension. This regressed during the 1.7 development cycle,
so that they started giving an error if *any* dimension had 0
elements, even ones that were not reduced over. Fixes bug #2078.
@travisbot

This comment has been minimized.

Show comment Hide comment
@travisbot

travisbot Jun 27, 2012

This pull request fails (merged 15738e1 into e15d0bd).

This pull request fails (merged 15738e1 into e15d0bd).

@njsmith

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Jun 27, 2012

Member

WTF? The one failure reported by Travis-CI is with Python 2.5, it's a test unrelated to this change, and I can't reproduce it here.

The failing test is:

  a = np.arange(5)
  a[:3] = a[2:]
  assert_equal(a, [2, 3, 4, 3, 4])

and what we're getting for a is [4, 3, 4, 3, 4], which is what you'd expect if the assignments were performed in backwards order (a[2] = a[4], a[1] = a[3], a[0] = a[2]).

I suspect that what this is saying is that numpy is in fact buggy in how it handles these assignments, but that this test has mostly been accidentally passing by chance.

Member

njsmith commented Jun 27, 2012

WTF? The one failure reported by Travis-CI is with Python 2.5, it's a test unrelated to this change, and I can't reproduce it here.

The failing test is:

  a = np.arange(5)
  a[:3] = a[2:]
  assert_equal(a, [2, 3, 4, 3, 4])

and what we're getting for a is [4, 3, 4, 3, 4], which is what you'd expect if the assignments were performed in backwards order (a[2] = a[4], a[1] = a[3], a[0] = a[2]).

I suspect that what this is saying is that numpy is in fact buggy in how it handles these assignments, but that this test has mostly been accidentally passing by chance.

@njsmith

This comment has been minimized.

Show comment Hide comment
@njsmith

njsmith Jun 27, 2012

Member

Re: the test failure: http://mail.scipy.org/pipermail/numpy-discussion/2012-June/063010.html

Anyway, I think this PR itself is fine.

Member

njsmith commented Jun 27, 2012

Re: the test failure: http://mail.scipy.org/pipermail/numpy-discussion/2012-June/063010.html

Anyway, I think this PR itself is fine.

@stefanv

This comment has been minimized.

Show comment Hide comment
@stefanv

stefanv Jul 1, 2012

Contributor

Looks good to me.

Contributor

stefanv commented Jul 1, 2012

Looks good to me.

njsmith added a commit that referenced this pull request Jul 6, 2012

Merge pull request #323 from njsmith/zero-size-reductions
BUG: handle length-0 axes correctly in ufunc.reduce without identity

@njsmith njsmith merged commit dd86cb3 into numpy:master Jul 6, 2012

@thouis thouis referenced this pull request in thouis/numpy-trac-migration Sep 27, 2012

Open

min/max/mean of empty arrays (migrated from Trac #2078) #3625

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