<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 12, 2014 at 5:57 AM, Sebastian Berg <span dir="ltr"><<a href="mailto:sebastian@sipsolutions.net" target="_blank">sebastian@sipsolutions.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fr, 2014-12-12 at 05:48 -0800, Jaime Fernández del Río wrote:<br>
> On Thu, Dec 11, 2014 at 10:53 AM, Stephan Hoyer <<a href="mailto:shoyer@gmail.com">shoyer@gmail.com</a>><br>
> wrote:<br>
>         On Thu, Dec 11, 2014 at 8:17 AM, Sebastian Berg<br>
>         <<a href="mailto:sebastian@sipsolutions.net">sebastian@sipsolutions.net</a>> wrote:<br>
>                 One option<br>
>                 would also be to have something like:<br>
><br>
>                 np.common_shape(*arrays)<br>
>                 np.broadcast_to(array, shape)<br>
>                 # (though I would like many arrays too)<br>
><br>
>                 and then broadcast_ar rays could be implemented in<br>
>                 terms of these two.<br>
><br>
><br>
>         It looks like np.broadcast let's us write the common_shape<br>
>         function very easily;<br>
><br>
><br>
>         def common_shape(*args):<br>
>             return np.broadcast(*args).shape<br>
><br>
><br>
>         And it's also very fast:<br>
>         1000000 loops, best of 3: 1.04 µs per loop<br>
><br>
>         So that does seem like a feasible refactor/simplification for<br>
>         np.broadcast_arrays.<br>
><br>
><br>
>         Sebastian -- if you're up for writing np.broadcast_to in C,<br>
>         that's great! If you're not sure if you'll be able to get<br>
>         around to that in the near future, I'll submit my PR with a<br>
>         Python implementation (which will have tests that will be<br>
>         useful in any case).<br>
><br>
><br>
> np.broadcast is the Python object of the old iterator. It may be a<br>
> better idea to write all of these functions using the new one,<br>
> np.nditer:<br>
><br>
><br>
> def common_shape(*args):<br>
>     return np.nditer(args).shape[::-1]  # Yes, you do need to reverse<br>
> it!<br>
><br>
><br>
> And in writing 'broadcast_to', rather than rewriting the broadcasting<br>
> logic, you could check the compatibility of the shape with something<br>
> like:<br>
><br>
><br>
> np.nditer((arr,), itershape=shape)  # will raise ValueError if shapes<br>
> incompatible<br>
><br>
><br>
><br>
> After that, all that would be left is some prepending of zero strides,<br>
> and some zeroing of strides of shape 1 dimensions before calling<br>
> as_strided<br>
><br>
<br>
</div></div>Hahaha, right there is the 32 limitation, but you can also (ab)use it:<br>
<br>
np.nditer(np.arange(10), itershape=(5, 10)).itviews[0]</blockquote><div><br></div><div>That's neat! But itviews is not even listed in the attributes of nditer in the docs, we should fix that.</div><div><br></div><div>Is the 32 argument limitation really a concern? Because that aside, it seems that all the functionality that has been discussed are one-liners using nditer: do we need new functions, or better documentation?</div></div><div class="gmail_extra"><br></div>Jaime<br clear="all"><div><br></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>