Repository navigation
_dtype_from_pep3118 is non-deterministic given zero-sized elements #9053
Description
In numpy 1.12.1, this code gives non-deterministic results, I'm guessing because the original field order is not preserved (the fields local variable is a dict rather than an OrderedDict):
>>> print(np.core._internal._dtype_from_pep3118("(0)I:a:f:f:"))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 called pad0. These dtypes aren't the same and can't be cast between each other with the 'safe' or 'equiv' rules.
Activity
eric-wieser commentedon May 5, 2017
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
ENH: Pad with itemsize, not padding fields
BUG: Fix non-determinism in order of fields created from pep3118 formats
ENH: Pad with itemsize, not padding fields
BUG: Fix non-determinism in order of fields created from pep3118 formats