On Wed, Mar 16, 2016 at 3:07 PM, Charles R Harris <charlesr.har...@gmail.com > wrote:
> > > On Wed, Mar 16, 2016 at 1: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. >> >> 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@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@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
