[Numpy-discussion] Changes to generalized ufunc core dimension checking

Nathaniel Smith njs at pobox.com
Wed Mar 16 18:28:14 EDT 2016

On Wed, Mar 16, 2016 at 12:48 PM, Travis Oliphant <travis at continuum.io>

> On Wed, Mar 16, 2016 at 12:55 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> Hi Travis,
>> On Mar 16, 2016 9:52 AM, "Travis Oliphant" <travis at 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:
  Pull request: https://github.com/numpy/numpy/pull/5077


Nathaniel J. Smith -- https://vorpus.org <http://vorpus.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20160316/1e6ec438/attachment.html>

More information about the NumPy-Discussion mailing list