8000 numpy.reshape return wrong strides information in master · Issue #2949 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

numpy.reshape return wrong strides information in master #2949

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.

Sign up for GitHub

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

Jump to bottom
Closed
nouiz opened this issue Jan 24, 2013 · 7 comments
Closed

numpy.reshape return wrong strides information in master #2949

nouiz opened this issue Jan 24, 2013 · 7 comments

Comments

@nouiz
Copy link
Contributor
nouiz commented Jan 24, 2013

On master in commit 2b4c9a6, I have this:

import numpy
numpy.asfortranarray(numpy.random.rand(3,6,1,1)).reshape(3,6,1).strides
(8, 24, 140247363096948)

With numpy 1.6.1, I have this output:
(8,24,144)

I expect the numpy 1.6.1 give the right outputs.

This cause problem in Theano tests as we do not support not aligned memory. In master, the ndarray isn't aligned due to the bad strides. We can work around in theano by checking the output of reshape, but maybe this can affect other people.

I think there was some discussion on strides for dimensions of shape 1, but I'm not sure and I probably didn't followed them closely. Do someone remember that?
@seberg
Copy link
Member
seberg commented Jan 24, 2013

@nouize thanks, I wondered if I should ask you about this... Yes this is something that has to be discussed. I personally think that this is correct (not the specific number of course), but it will have to be reverted in any case (possible with a new flag that keeps this behavior side by side). The PR, reverting is gh-2735, and if you have any opinion about it, or an idea on how to best handle this I would be interested. On the one hand code could break badly assuming things about strides, on the other hand doing copies etc. and not being able to signal how the memory really is layouted is a bit annoying. The 140247363096948 is odd, and probably should be fixed (whatever the reason, probably I messed something up, forgot a magic number I temporarly added to test things or whatnot), but master does not guarantee anything for these cases, that is true.

@seberg
Copy link
Member
seberg commented Jan 24, 2013

Ok, sorry, I am trying to wrap my head around this, I mean its a very silly stride (and I have not yet figured out where it comes from) but why is it not aligned (and should we/you even check alignment for 1-sized strides)?

@njsmith
Copy link
Member
njsmith commented Jan 24, 2013

@nouiz: Yes, can you clarify what you mean by "not aligned memory"? Both
the master and 1.6.1 strides are correct and equivalent; both are aligned.
Like @seberg says, in 1.8 we will probably have to revert to the (broken!)
definition of "contiguous" that earlier versions of numpy used, but I think
in the long run the fix is for downstream code to properly interpret
strides...

On Thu, Jan 24, 2013 at 10:25 AM, nouiz notifications@github.com wrote:

On master in commit 2b4c9a62b4c9a6,
I have this:

import numpy
numpy.asfortranarray(numpy.random.rand(3,6,1,1)).reshape(3,6,1).strides
(8, 24, 140247363096948)

With numpy 1.6.1, I have this output:
(8,24,144)

I expect the numpy 1.6.1 give the right outputs.

This cause problem in Theano tests as we do not support not aligned
memory. In master, the ndarray isn't aligned due to the bad strides. We can
work around in theano by checking the output of reshape, but maybe this can
affect other people.

I think there was some discussion on strides for dimensions of shape 1,
but I'm not sure and I probably didn't followed them closely. Do someone
remember that?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2949.

@seberg
Copy link
Member
seberg commented Jan 24, 2013

OK, wait. I am sorry, the code setting the strides in reshape seems to give uninitialized memory here, which when I tried happened to give aligned results. It used to work, because there was a special case of only adding/removing ones, which I removed, because the other code (with this exception) handled it already.

With the whole strides discussion I was wondering about adding a stride cleaning function to set these strides to reasonable values, maybe it is time to implement that to use here.

@seberg seberg mentioned this issue Jan 24, 2013
Merged
@seberg
Copy link
Member
seberg commented Jan 24, 2013

I did a take on fixing this in gh-2950 there are probably other ways to fill things, or you could take care about strides some more (considering the whole strides discussion), but that should fix it. @nouiz I would be very interested if you have any opinion about the strides of 1 dimensional axes thing in general...

@nouiz
Copy link
Contributor Author
nouiz commented Jan 25, 2013

@njsmith What I mean by not aligned memory, is that in the master the ndarray flag aligned is false, when it is true in 1.6.1. Theano do not support not aligned ndarray, so we automatically check this flag and automatically raise an error when we see one. I suppose the not initiailized strides cause a function that check if the ndarray is aligned or not to think it isn't aligned. This bring the question, should the function that compute the align flag be updated to ignore the strides of dimensions of 1?

@seberg I think gh-2950 should fix my problem.

thanks

This was referenced Feb 1, 2013
Closed
Closed
@seberg
Copy link
Member
seberg commented Feb 28, 2013

This is fixed in master.

@seberg seberg closed this as completed Feb 28, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@seberg @nouiz @njsmith
0