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

Travis Oliphant travis at continuum.io
Thu Mar 17 04:04:11 EDT 2016


On Wed, Mar 16, 2016 at 3:07 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> On Wed, Mar 16, 2016 at 1:48 PM, Travis Oliphant <travis at continuum.io>
> wrote:
>
>>
>>
>> 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.
>>
>> 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.
>>
>
> The `@` operator doesn't allow that.
>
>
>>
>> It used to automatically happen and a few people depended on it in
>> several companies and so the 1.10 release broke their code.
>>
>> I can appreciate that in the general case, allowing arbitrary
>> broadcasting on the internal core dimensions can create confusion.  But,
>> scalar broadcasting still makes sense.
>>
>
> Mixing array multiplications with scalar broadcasting is looking for
> trouble. Array multiplication needs strict dimensions and having stacked
> arrays and vectors was one of the prime objectives of gufuncs. Perhaps what
> we need is a more precise notation for broadcasting, maybe `*` or some such
> addition to the signaturs to indicate that scalar broadcasting is
> acceptable.
>

I think that is a good idea.    Let the user decide if scalar broadcasting
is acceptable for their function.

Here is a simple concrete example where scalar broadcasting makes sense:

A 1-d dot product (the core of np.inner)   (k), (k) -> ()

A user would assume they could call this function with a scalar in either
argument and have it broadcast to a 1-d array.    Of course, if both
arguments are scalars, then it doesn't make sense.

Having a way for the user to allow scalar broadcasting seems sensible and a
nice compromise.

-Travis



>  <snip>
>
> Chuck
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>


-- 

*Travis Oliphant, PhD*
*Co-founder and CEO*


@teoliphant
512-222-5440
http://www.continuum.io
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20160317/9fb8e7f7/attachment.html>


More information about the NumPy-Discussion mailing list