<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 1:56 PM, Stephan Hoyer <span dir="ltr"><<a href="mailto:shoyer@gmail.com" target="_blank">shoyer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 25, 2015 at 1:24 PM, Jaime Fernández del Río <span dir="ltr"><<a href="mailto:jaime.frio@gmail.com" target="_blank">jaime.frio@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">1. When converting these objects to arrays using <font face="monospace, monospace">PyArray_Converter,</font> if the arrays returned by any of the array interfaces is not C contiguous, aligned, and writeable, a copy that is will be made. Proper arrays and subclasses are passed unchanged. This is the source of the error reported above.<br></div></blockquote><div> </div><div><span class=""><div> </div>When converting these objects to arrays using PyArray_Converter, if the arrays returned by any of the array interfaces is not C contiguous, aligned, and writeable, a copy that is will be made. Proper arrays and subclasses are passed unchanged. This is the source of the error reported above.<div><br></div></span><div>I'm not entirely sure I understand this -- how is PyArray_Convert used in numpy? For example, if I pass a non-contiguous array to your class Foo, np.asarray does not do a copy:</div></div></div></div></div></blockquote><div><br></div><div>It is used by many (all?) C functions that take an array as input. This follows a different path than what <font face="monospace, monospace">np.asarray</font> or <font face="monospace, monospace">np.asanyarray</font> do, which are calls to <font face="monospace, monospace">np.array</font>, which maps to the C function <font face="monospace, monospace">_array_fromobject</font> which can be found here:</div><div><br></div><div><a href="https://github.com/numpy/numpy/blob/maintenance/1.9.x/numpy/core/src/multiarray/multiarraymodule.c#L1592">https://github.com/numpy/numpy/blob/maintenance/1.9.x/numpy/core/src/multiarray/multiarraymodule.c#L1592</a><br></div><div><br></div><div>And ufuncs have their own conversion code, which doesn't really help either. Not sure it would be possible to have them all use a common code base, but it is certainly well worth trying.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div><div><div>In [25]: orig = np.zeros((3, 4))[:2, :3]</div><div><br></div><div>In [26]: orig.flags</div><div>Out[26]:</div><div> C_CONTIGUOUS : False</div><div> F_CONTIGUOUS : False</div><div> OWNDATA : False</div><div> WRITEABLE : True</div><div> ALIGNED : True</div><div> UPDATEIFCOPY : False</div><div><br></div><div>In [27]: subclass = Foo(orig)</div><div><br></div><div>In [28]: np.asarray(subclass)</div><div>Out[28]:</div><div>array([[ 0., 0., 0.],</div><div> [ 0., 0., 0.]])</div><div><br></div><div>In [29]: np.asarray(subclass)[:] = 1</div><div><br></div><div>In [30]: np.asarray(subclass)</div><div>Out[30]:</div><div>array([[ 1., 1., 1.],</div><div> [ 1., 1., 1.]])</div></div></div><div><br></div><div><br></div><div>But yes, this is probably a bug.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>2. When converting these objects using PyArray_OutputConverter, as well as in similar code in the ufucn machinery, anything other than a proper array or subclass raises an error. This means that, contrary to what the docs on subclassing say, see below, you cannot use an object exposing the array interface as an output parameter to a ufunc</div></div></blockquote><div><br></div><div>Here it might be a good idea to distinguish between objects that define __array__ vs __array_interface__/__array_struct__. A class that defines __array__ might not be very ndarray-like at all, but rather be something that can be *converted* to an ndarray. For example, objects in pandas define __array__, but updating the return value of df.__array__() in-place will not necessarily update the DataFrame (e.g., if the frame had inhomogeneous dtypes).</div></div></div></div></blockquote><div><br></div><div>I am not really sure what the behavior of <font face="monospace, monospace">__array__</font> should be. The link to the subclassing docs I gave before indicates that it should be possible to write to it if it is writeable (and probably pandas should set the writeable flag to False if it cannot be reliably written to), but the obscure comment I mentioned seems to point to the opposite, that it should never be written to. This is probably a good moment in time to figure out what the proper behavior should be and document it.</div><div><br></div><div>Jaime</div><div><br></div></div>-- <br><div class="gmail_signature">(\__/)<br>( O.o)<br>( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.</div>
</div></div>