_dtype_from_pep3118 is non-deterministic given zero-sized elements #9053
Labels
Comments
|
Thanks for the report. Combined with #9049, it seems like perhaps the function should just be thrown out and rewritten I've made a start on a patch, and got as far as some cleanup - but am struggling to understand the padding rules, since the only specification I can find is the implementation |
eric-wies
8000
er
added a commit
to eric-wieser/numpy
that referenced
this issue
May 5, 2017
Adding padding fields means that dtypes with the same fields cannot necessarily be cast to one another. Padding shouldn't prevent casting. Partially fixes numpy#9053
eric-wieser
added a commit
to eric-wieser/numpy
that referenced
this issue
May 5, 2017
mherkazandjian
pushed a commit
to mherkazandjian/numpy
that referenced
this issue
May 30, 2017
Adding padding fields means that dtypes with the same fields cannot necessarily be cast to one another. Padding shouldn't prevent casting. Partially fixes numpy#9053
mherkazandjian
pushed a commit
to mherkazandjian/numpy
that referenced
this issue
May 30, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In numpy 1.12.1, this code gives non-deterministic results, I'm guessing because the original field order is not preserved (the
fieldslocal variable is a dict rather than an OrderedDict):In some cases the output is
[('a', '<u4', (0,)), ('f', '<f4')], in others it is{'names':['f','a'], 'formats':['<f4',('<u4', (0,))], 'offsets':[0,0], 'itemsize':4}.These dtypes are at least equal to each other, but it gets worse: given
f:f:(0)Iempty:4x, the padding is sometimes anonymous, and sometimes a field calledpad0. These dtypes aren't the same and can't be cast between each other with the 'safe' or 'equiv' rules.The text was updated successfully, but these errors were encountered: