-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
dtype "aligned" flag not respected by recarray. #5224
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
Comments
occurs in my setup. v1.9.0 on win7 x64. |
v1.9.1 doesn't work either v1.8.2 DOES work |
Can confirm this is affecting my PyOpenGL code when using complex dtypes. |
Some preliminary notes: This isn't a bug in recarray, but in ndarray. (recarray happens to have a completely duplicate format_parser, but that isn't what is being used here). First of all, according to the docs, "align" has no effect in this line:
since this uses the "list" form of dtype specification, for which the docs say:
I'm not sure exactly what this means yet. Second, the line
does not do anything because np.require currently ignores the "ALIGNED" flag. This is a bug. I hope to look into it further. |
Thanks for looking into this! If align is not accepted with an array interface description, then the Best, Neil On Mon, Jan 26, 2015 at 5:34 PM, ahaldane notifications@github.com wrote:
|
This appears to be fixed now! Should we close this? (Might be nice to link to the changelist if someone knows it.) |
I don't see any obvious candidates for the fix PR, but there are a number of recarray fixups. I'll close this now, thanks for the heads up. |
I'd guess @ahaldane may be responsible. |
I'm looking into it. I believe there is a bug here: Now the alignment flag gets set when it should not be. Eg, try the first example here without I don't remember touching alignment though. 8000 I'm running git bisect right now to figure it out.. |
Git bisect says 3351dbf is the first bad commit, in PR #5316. I haven't investigated much, but @juliantaylor may be able to help! The bisect test was
|
@ahaldane Would you mind showing me how you did this bisect? |
Sure. Actually my technique is a homemade cobbled thing, maybe somebody knows something better. But in summary I have a bash script
Then I have a python script
Then I look through git log to a point I guess is probably ok, in this case a0ea059, check that commit out, and run
and waited. It took about 8 builds, or 20 minutes, to finish. |
@ahaldane Awesome, thanks!! |
I looked a little more at this case. While #5316 introduced new behavior, it might be that the new behavior is OK. There is still a bug to fix here, but it is different from what's going on in #5316. I think the bug is that the What may not be a bug is the behavior change in 1.9.2, where structured dtypes now have I think the way to interpret this is:
So, in the example given in this issue, it used to be that the 'align' keyword was ignored , and the ALIGNED flag defaulted to False, but now the 'align' keyword is still ignored, but ALIGNED defaults to True. Also, in this comment @njsmith suggests that dtype('i2,i2') should have alignment of 2, although it currently has alignment of 1. It possibly makes sense to me that alignment of 1 is right: We did not ask for |
It's possible the dtype constructor should have both an |
@ahaldane Wouldn't you be able to accomplish that by setting |
I'm not sure how that would work. Currently fields do have alignments: |
@ahaldane Maybe it would be good to start by making a list of use cases? My use case is OpenGL vertex data. See: e.g. https://developer.apple.com/library/ios/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/TechniquesforWorkingwithVertexData/TechniquesforWorkingwithVertexData.html#//apple_ref/doc/uid/TP40008793-CH107-SW7 Each record must be aligned to 4 bytes. The fields within a record do not need to be aligned; they can start anywhere. |
Interesting. This is a use-case where we might indeed want to separate the two effects of
Normally setting (Although, I have trouble imagining a real-world case where |
This appears to be fixed now. |
As per my stackoverflow question:
prints
[False, False]
!@charris writes that "The
recarray
class accepts an aligned parameter, but looks to lose it informat_parser
".This bug breaks usage of PyOpenGL as per my other stackoverflow question.
As an aside why does "c-contiguous" imply "aligned" for recarray?
The text was updated successfully, but these errors were encountered: