On Wed, Mar 16, 2016 at 12:48 PM, Travis Oliphant <tra...@continuum.io> wrote:
> > > On Wed, Mar 16, 2016 at 12:55 PM, Nathaniel Smith <n...@pobox.com> wrote: > >> Hi Travis, >> >> On Mar 16, 2016 9:52 AM, "Travis Oliphant" <tra...@continuum.io> wrote: >> > >> > Hi everyone, >> > >> > Can you help me understand why the stricter changes to generalized >> ufunc argument checking no now longer allows scalars to be interpreted as >> 1-d arrays in the core-dimensions? >> > >> > Is there a way to specify in the core-signature that scalars should be >> allowed and interpreted in those cases as an array with all the elements >> the same? This seems like an important feature. >> >> Can you share some example of when this is useful? >> > > Being able to implicitly broadcast scalars to arrays is the core-function > of broadcasting. This is still very useful when you have a core-kernel > an want to pass in a scalar for many of the arguments. It seems that at > least in that case, automatic broadcasting should be allowed --- as it > seems clear what is meant. > It isn't at all obvious what matrix_multiply(some_arr, 3) should mean, and the behavior you're proposing is definitely not what most people would expect when seeing that call. (I guess most people reading this would expect it to be equivalent to do a scalar multiplication like some_arr * 3, but in numpy 1.9 and earlier it did... I'm not quite sure what, actually, maybe np.sum(some_arr * 3, axis=1)?) Again, can you share some example(s) of a gufunc where this is what is wanted, so that we have a more concrete basis for discussion? > > While you can use the broadcast* features to get the same effect with the > current code-base, this is not intuitive to a user who is used to having > scalars interpreted as arrays in other NumPy operations. > > It used to automatically happen and a few people depended on it in several > companies and so the 1.10 release broke their code. > That's certainly unfortunate -- I think one of the reasons we elected to push the change through directly instead of going through a deprecation cycle was that as far as we could tell, this feature was both broken and unused and was only noticed recently because gufunc usage was only just starting to increase -- so we wanted to get rid of it quickly before people started inadvertently depending on it. (And clear the ground for any more-carefully-thought-through option that might arise in the future.) Sounds like a real deprecation cycle would have been better. For reference: Mailing list discussion: http://thread.gmane.org/gmane.comp.python.numeric.general/58824 Pull request: https://github.com/numpy/numpy/pull/5077 -n -- Nathaniel J. Smith -- https://vorpus.org <http://vorpus.org>
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
