Mon, 07 Mar 2011 11:23:33 -0600, Robert Kern wrote: [clip] > Can someone explain exactly what changed? Or point to the changeset that > made it? It's not clear to me what operations are different under Mark's > changes.
Mark mentioned three points here: http://permalink.gmane.org/gmane.comp.python.numeric.general/42753 Below, first two. 1) Structured array copying copies by field name. Commit 22d96096bf7d5fb199ca80f2fcd04e8d27815476 Before: >>> x = np.array([(0, 1)], dtype=[('a', int), ('b', int)]) >>> y = np.array([(2, 3)], dtype=[('a', int), ('b', int)]) >>> y = np.array([(2, 3)], dtype=[('b', int), ('a', int)]) >>> x[:] = y >>> x array([(2, 3)], dtype=[('a', '<i4'), ('b', '<i4')]) After: >>> x = np.array([(0, 1)], dtype=[('a', int), ('b', int)]) >>> y = np.array([(2, 3)], dtype=[('b', int), ('a', int)]) >>> x[:] = y >>> x array([(3, 2)], dtype=[('a', '<i4'), ('b', '<i4')]) This seems like a pretty hazardous change. Granted, it's in a bit of a grey area, but people may rely on this. 2) Ufuncs don't necessarily return arrays in C-order, but instead try to keep the memory layout of the original if it seems advantageous vs. memory access. Before: >>> np.sin(np.zeros((5,5,5)).transpose(1,2,0)).strides (200, 40, 8) After: >>> np.sin(np.zeros((5,5,5)).transpose(1,2,0)).strides (40, 8, 200) This gets +1 from me; the drawbacks to this are mostly in code that makes too much assumptions and makes no checks. -- Pauli Virtanen _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion