<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 3, 2018 at 12:11 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:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class="gmail-"><div dir="ltr">On Tue, Jul 3, 2018 at 7:13 AM Marten van Kerkwijk <<a href="mailto:m.h.vankerkwijk@gmail.com" target="_blank">m.h.vankerkwijk@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Overall, would one way to move forward be to merge the first PR (flexible and frozen) and defer the broadcastable dimensions?</div></div></blockquote><div><br></div></span><div>This would have my support.</div><div><br></div><div>I have similar misgivings about broadcastable dimensions to those raised by Nathaniel.</div><div><br></div><div>In particular, I wonder if there is some way to make use of this functionality internally in NumPy for functions like all_equal() without exposing it as part of the external gufunc API.<br><br></div></div></div></blockquote><div> </div><div>OK, so let me explicitly ask whether there are any objections to going forward with flexible and frozen dimensions, but deferring on broadcastable ones until more compelling use cases have been identified?<br><br></div><div>Thanks,<br><br></div><div>Marten<br><br></div><div>p.s. I adjusted the "acceptance PR" to reflect this: <a href="https://github.com/numpy/numpy/pull/11429">https://github.com/numpy/numpy/pull/11429</a><br></div></div></div></div>