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

[Feng Yu]

Hi,

Here is another example.

To write pix2ang (and similar functions) to a ufunc, one may want to have
implicit scalar broadcast on `nested` and `nsides` arguments.

The function is described here:

http://healpy.readthedocs.org/en/latest/generated/healpy.pixelfunc.pix2ang.html#healpy.pixelfunc.pix2ang


Yu

On Thu, Mar 17, 2016 at 2:04 AM, Travis Oliphant <travis at continuum.io>
wrote:

>
>
> 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
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20160317/fc2ae90c/attachment.html>