On Wed, Oct 22, 2014 at 12:28 PM, Julian Taylor < jtaylor.debian@googlemail.com> wrote:

On 22.10.2014 20:00, Charles R Harris wrote:

...

On Wed, Oct 22, 2014 at 11:32 AM, Neil Girdhar <mistersheik@gmail.com <mailto:mistersheik@gmail.com>> wrote:

Hello,

Is this desired behaviour or a regression or a bug?

http://stackoverflow.com/questions/26497656/how-do-i-align-a-numpy-record-ar...

...

Thanks,

I'd guess that the definition of aligned may have become stricter, that's the only thing I think has changed. Maybe Julian can comment on

that.

...

structured dtypes have not really a well defined alignment, e.g. the stride of this is 12, so when element 0 is aligned element 1 is always unaligned.

Before 1.9 structured dtype always had the aligned flag set, even if they were unaligned. Now we require a minimum alignment of 16 for strings and structured types so copying which sometimes works on the whole compound type instead of each item always works. This was the easiest way to get the testsuite running on sparc after fixing a couple of code paths not updating alignment information which forced some functions to always take super slow unaligned paths (e.g. ufunc.at) But the logic could certainly be improved.

The stackexchange example: In [9]: a = np.zeros(4, dtype=dtype([('x', '<f8'), ('y', '<i4')], align=False)) In [10]: a.data Out[10]: <read-write buffer for 0x2f94440, size 48, offset 0 at 0x2f8caf0> In [11]: a = np.zeros(4, dtype=dtype([('x', '<f8'), ('y', '<i4')], align=True)) In [12]: a.data Out[12]: <read-write buffer for 0x2f94030, size 64, offset 0 at 0x2f8c5b0> Note that using an aligned dtype yields a different size on my 64 bit system and 64 / 4 = 16. Chuck