<p dir="ltr">On 23 Jul 2013 16:03, "Pauli Virtanen" <<a href="mailto:pav@iki.fi">pav@iki.fi</a>> wrote:<br>
><br>
> 23.07.2013 17:51, Nathaniel Smith kirjoitti:<br>
> [clip: conjcomplex dtype]<br>
> > Because this latter cast is safe, all the existing ufuncs would<br>
> > automatically work fine on conjcomplex arrays. But we could also<br>
> > define conjcomplex-specific ufunc loops for cases like dot() where a<br>
> > more efficient implementation is possible (using the above-mentioned<br>
> > BLAS flags).<br>
> ><br>
> > Don't know if we want to actually do this, but it's doable.<br>
><br>
> There's somewhat a lot of 3rd party code that doesn't do automatic<br>
> casting (e.g. all of Cython code interfacing with Numpy, C extensions,<br>
> f2py I think), but rather fails for incompatible input dtypes. Having<br>
> arrays with a new complex dtype around would require changes in this<br>
> sort of code.<br>
><br>
> In this sense having an iterator of some sort with an __array__<br>
> attribute would work. However, an iterator doesn't support (without a<br>
> lot of work) the various ndarray attributes which would be confusing.</p>
<p dir="ltr">Surely there's more code that handles unusual but correctly castable dtypes dtypes than there is code that handles custom iterator objects that are missing ndarray attributes?</p>
<p dir="ltr">-n</p>