<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Aug 29, 2014 at 2:55 AM Jaime Fernández del Río <<a href="mailto:jaime.frio@gmail.com">jaime.frio@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 28, 2014 at 5:40 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.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><div><span style="color:rgb(34,34,34)">Some thoughts:</span><br></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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">
<br>
But, for your computed dimension idea I'm wondering if what we should<br>
do instead is just let a gufunc provide a C callback that looks at the<br>
input array dimensions and explicitly says somehow which dimensions it<br>
wants to treat as the core dimensions and what its output shapes will<br>
be. There's no rule that we have to extend the signature mini-language<br>
to be Turing complete, we can just use C :-).<br>
<br>
It would be good to have a better motivation for computed gufunc<br>
dimensions, though. Your "all pairwise cross products" example would<br>
be *much* better handled by implementing the .outer method for binary<br>
gufuncs: pairwise_cross(a) == cross.outer(a, a). This would make<br>
gufuncs more consistent with ufuncs, plus let you do<br>
all-pairwise-cross-products between two different sets of cross<br>
products, plus give us all-pairwise-matrix-products for free, etc.<br></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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"></blockquote><div><br></div><div>The outer for binary gufuncs sounds like a good idea. A reduce for binary gufuncs that allow it (like square matrix multiplication) would also be nice. But going back to the original question, the pairwise whatevers were just an example: one could come up with several others, e.g.:</div>
<div><br></div><div> (m),(n)->($p),($q) with $p = m - n and $q = n - 1, could be (I think) the signature of a polynomial division gufunc</div>
<div> (m),(n)->($p), with $p = m - n + 1, could be the signature of a convolution or correlation gufunc</div><div> (m)->($n), with $n = m / 2, could be some form of downsampling gufunc</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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">
While you're messing around with the gufunc dimension matching logic,<br>
any chance we can tempt you to implement the "optional dimensions"<br>
needed to handle '@', solve, etc. elegantly? The rule would be that<br>
you can write something like<br>
(n?,k),(k,m?)->(n?,m?)<br>
and the ? dimensions are allowed to take on an additional value<br>
"nothing at all". If there's no dimension available in the input, then<br>
we act like it was reshaped to add a dimension with shape 1, and then<br>
in the output we squeeze this dimension out again. I guess the rules<br>
would be that (1) in the input, you can have ? dimensions at the<br>
beginning or the end of your shape, but not both at the same time, (2)<br>
any dimension that has a ? in one place must have it in all places,<br>
(3) when checking argument conformity, "nothing at all" only matches<br>
against "nothing at all", not against 1; this is because if we allowed<br>
(n?,m),(n?,m)->(n?,m) to be applied to two arrays with shapes (5,) and<br>
(1, 5), then it would be ambiguous whether the output should have<br>
shape (5,) or (1, 5).<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I definitely do not mind taking a look into it. I need to think a little more about the rules to convince myself that there is a consistent set of them that we can use. I also thought there may be a performance concern, that you may want to have different implementations when dimensions are missing, not automatically add a 1 and then remove it. It doesn't seem to be the case with neither `np.dot` nor `np.solve`, so maybe I am being overly cautious.</div>
<div><br></div><div>Thanks for your comments and ideas. I have a feeling there are some nice features hidden in here, but I can't seem to figure out what should they be on my own.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Jaime</div>
<div>
<br></div></div></div></div><div dir="ltr"><div class="gmail_extra">-- <br>(\__/)<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>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org" target="_blank">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a></blockquote><div><br></div><div>I'm not sure where this is at, given the current amount of work that is</div><div>coming from the 1.10 release, but this sounds like a really great idea.</div><div>Computed/fixed dimensions would allow gufuncs for things like:</div><div>- polynomial multiplication, division, differentiation, and integration</div><div>- convolutions</div><div>- views of different types (see the corresponding discussion at</div><div><a href="http://permalink.gmane.org/gmane.comp.python.numeric.general/59847">http://permalink.gmane.org/gmane.comp.python.numeric.general/59847</a>).</div><div>Some of these examples would work better with gufuncs that can construct views and have an axes keyword, but this is exactly the kind of functionality that would be really great to have.</div><div>Thanks for the great work!</div><div>-Ian Henriksen</div></div></div>