Skip to content

BUG: Fix strides of trailing 1s when reshaping #2950

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 28, 2013

Conversation

seberg
Copy link
Member

@seberg seberg commented Jan 24, 2013

When adding ones to the shape for non contiguous arrays reshapes
(i.e. either the first array is not contiguous or the the reshape
order does not match it). The strides of trailing ones were not
set. For example reshape of (6,) to (6,1,1). Previously this occured
rarely because of removed special handleing when only ones were
added or removed.

Fix for gh-2949, this does not attempt to set strides in a beautiful way to conserve the contiguity of the input array, but that is maybe a bigger matter anyway (and here only interesting in corner cases I guess).

@seberg
Copy link
Member Author

seberg commented Jan 24, 2013

There is always something you forget... fixed handling of size 1 arrays. Also added a second commit that would just manually fix the 0-sized array special case, just so one does not have to worry about it, since it means that _attempt_nocopy_reshape should handle all cases. This means it could be used in array_set_shape to avoid the copy directly (compare gh-145), though of course that would not expose it on the C-Api level.

@charris
Copy link
Member

charris commented Jan 25, 2013

The travis error looks legit:

numpy/core/src/multiarray/shape.c:408:24: error: ‘newdim’ undeclared (first use in this function)

@seberg seberg closed this Jan 25, 2013
@seberg seberg reopened this Jan 25, 2013
When adding ones to the shape for non contiguous arrays reshapes
(i.e. either the first array is not contiguous or the the reshape
order does not match it). The strides of trailing ones were not
set. For example reshape of (6,) to (6,1,1). Previously this occured
rarely because of removed special handleing when only ones were
added or removed.
@seberg
Copy link
Member Author

seberg commented Jan 25, 2013

OK, failures should be fixed...

@seberg
Copy link
Member Author

seberg commented Jan 25, 2013

Since the comment is invisible here due to rebase... I did add some better tests for the second commit (extending the old regression ones) and checked it locally. It is not checked by Travis because PyArray_NewReshape has a special case for contiguous arrays (skipping the function) and this is always triggered for 0-sized arrays.

@nouiz
Copy link
Contributor

nouiz commented Jan 29, 2013

I ran all Theano's tests and all passed with this fix.

thanks

@nouiz
Copy link
Contributor

nouiz commented Feb 26, 2013

Now that NumPy 1.7 is released, is there something that prevent the merge of this PR? As it fix a bug introduced in the master, I would be great that is get merged.

I read the full function and I'm convinced that this PR is good and fix the bug introduced.

thanks

@njsmith
Copy link
Member

njsmith commented Feb 26, 2013

Probably I am just being stupid, but I have read the description and skimmed the code and I'm still a little unclear on what the actual change is. Is the point that we had a bug where in certain cases, parts of the new strides array were left uninitialized? And then a further bug (not fixed here) where we were paying attention to those bits of the stride array that were left uninitialized (even though the value actually shouldn't have mattered), and setting the ALIGNED flag incorrectly? And finally, this PR takes the trouble to preserve the traditional C or F contiguity constraints as necessary?

I support the initialization of memory even if we do manage to stop caring about strides for 1-length axes -- it makes tools like valgrind better able to do their job.

@seberg
Copy link
Member Author

seberg commented Feb 26, 2013

That is just how I write descriptions, utterly impossible to understand... To all of your questions: yes.

The one other thing I will just mention again, is that this "size <= 1" code block is currently unused, but makes the function work in all cases. I don't particularly like it, but on the other hand I also don't like the trap of having a function that almost always works as expected. So if someone prefers that currently unused code block away, no problem.

@njsmith
Copy link
Member

njsmith commented Feb 26, 2013

I'm not a big fan of duplicate or unused code blocks either, though you're
right that taking it out would be leaving quite a trap for later. Can we
either: remove the other special case and use this function in all cases,
or, remove the unused block and replace it with some kind of explicit
check-and-raise for the unhandled case?
On 26 Feb 2013 22:25, "seberg" notifications@github.com wrote:

That is just how I write descriptions, utterly impossible to understand...
To all of your questions: yes.

The one other thing I will just mention again, is that this "size <= 1"
code block is currently unused, but makes the function work in all cases. I
don't particularly like it, but on the other hand I also don't like the
trap of having a function that almost always works as expected. So if
someone prefers that currently unused code block away, no problem.


Reply to this email directly or view it on GitHubhttps://github.com//pull/2950#issuecomment-14143798
.

@seberg
Copy link
Member Author

seberg commented Feb 28, 2013

OK, I just removed the second commit. Removing the special case in NewShape did not seem useful. If anyone ever wants to use the attempt_reshape_nocopy for something else, it is easy enough to add this again. np.reshape and array.shape = ... have regression tests in place anyway I believe.

@njsmith
Copy link
Member

njsmith commented Feb 28, 2013

Yeah, I took a closer look, and PyArray_Newshape could definitely be cleaner, but eh. (Why do we have "fast paths" to save a few dozen integer operations in a function that is generally called from Python and always allocates memory? Rhetorical question I know...) This seems like a fine fix for the main issue to me, so merging.

njsmith added a commit that referenced this pull request Feb 28, 2013
BUG: Fix strides of trailing 1s when reshaping
@njsmith njsmith merged commit 0934653 into numpy:master Feb 28, 2013
@nouiz
Copy link
Contributor

nouiz commented Feb 28, 2013

Thanks,

now Theano work without problem with master.

@seberg seberg deleted the issue-2949 branch February 28, 2013 22:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants