<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 12, 2018 at 2:35 AM, Eric Wieser <span dir="ltr"><<a href="mailto:wieser.eric+numpy@gmail.com" target="_blank">wieser.eric+numpy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="m_-1008241591095893649markdown-here-wrapper" style="font-size:1em;font-family:Helvetica,arial,freesans,clean,sans-serif;color:rgb(34,34,34);background-color:rgb(255,255,255);border:none;line-height:1.2"><p style="margin:1em 0px">Frozen dimensions:</p><span class="">
<blockquote style="margin:1em 0px;border-left:4px solid rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none">
<p style="margin:1em 0px">I started with just making every 3-vector and 3x3-matrix structured arrays with the relevant single sub-array entry</p>
</blockquote>
</span><p style="margin:1em 0px">I was actually suggesting omitting the structured dtype (ie, field names) altogether, and just using the subarray dtypes (which exist alone, but not in arrays).</p><span class="">
<blockquote style="margin:1em 0px;border-left:4px solid rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none">
<p style="margin:1em 0px">Another (small?) advantage is that I can use `axis</p>
</blockquote>
</span><p style="margin:1em 0px">This is a fair argument against my proposal - at any rate, I think we’d need a better story for subarray dtypes before trying to add support to them for ufuncs</p></div></div></blockquote><div>Yes, I've been wondering about the point of the sub-arrays... They seem interesting but in arrays just disappear. Their possible use would be to change the shape as seen by the outside world (as happens if one does define that sub-array as a 1-part structured array).<br><br></div><div>Anyway, for another discussion!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="m_-1008241591095893649markdown-here-wrapper" style="font-size:1em;font-family:Helvetica,arial,freesans,clean,sans-serif;color:rgb(34,34,34);background-color:rgb(255,255,255);border:none;line-height:1.2">
<hr>
<p style="margin:1em 0px">Broadcasting dimensions</p>
<blockquote style="margin:1em 0px;border-left:4px solid rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none">
<p style="margin:1em 0px">But perhaps a putative weighted_mean … is a decent example</p>
</blockquote>
<p style="margin:1em 0px">That’s fairly convincing as a non-chained ufunc case. Can you add an example like that to the NEP?</p></div></div></blockquote><div>Done.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="m_-1008241591095893649markdown-here-wrapper" style="font-size:1em;font-family:Helvetica,arial,freesans,clean,sans-serif;color:rgb(34,34,34);background-color:rgb(255,255,255);border:none;line-height:1.2"><span class="">
<blockquote style="margin:1em 0px;border-left:4px solid rgb(221,221,221);padding:0px 1em;color:rgb(119,119,119);quotes:none">
<p style="margin:1em 0px">Also, it has the benefit of being clear what the function can handle by inspection of the signature</p>
</blockquote>
</span><p style="margin:1em 0px">Is <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">broadcasting (n),(n)->(),()</code> less clear that <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:nowrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">(n|1),(n|1)->(),()</code>? Can you come up with an example where only some dimensions make sense to broadcast?</p></div></div></blockquote><div>Not a super-convincing one, though I guess one could think of a similar function for 3-vectors (which somehow must care about those being three-dimensional, because, say, it calculates the average direction of the cross product in spherical angles...), then, in the signature `(n,3),(n,3)->(),(),(),()` one would like to indicate that the `n` could be broadcast, but the `3` could not.<br><br></div><div>As I now write in the NEP, part of the reason of doing it by distinct dimension is that I already need a flag for flexible, so it is easy to add one for broadcastable; similarly, in the actual code, there is quite a bit of shared stuff.<br><br></div><div>-- Marten<br></div></div></div></div>