Hi All,
Matti asked me to make a PR accepting my own NEP -
https://github.com/numpy/numpy/pull/11429
Any objections?
As noted in my earlier summary of the discussion, in principle we can
choose to accept only parts, although I think it became clear that the most
contentious is also the one
Hi All,
The discussion on the gufunc signature enhancements seems to have stalled a
bit, but while it was going I've tried to update the NEP correspondingly.
The NEP is now merged, so can viewed more easily, at
http://www.numpy.org/neps/nep-0020-gufunc-signature-enhancement.html
My own quite
On Tue, Jun 12, 2018 at 2:35 AM, Eric Wieser
wrote:
> Frozen dimensions:
>
> I started with just making every 3-vector and 3x3-matrix structured arrays
> with the relevant single sub-array entry
>
> I was actually suggesting omitting the structured dtype (ie, field names)
> altogether, and just
I don’t understand your alternative here. If we overload np.matmul using
*array_function*, then it would not use *ether* of these options for
writing the operation in terms of other gufuncs. It would simply look for
an *array_function* attribute, and call that method instead.
Let me explain that
In Sun, Jun 10, 2018 at 4:31 PM Eric Wieser
wrote:
> Thanks for the writeup Marten,
>
Indeed, thank you Marten!
> This hits on an interesting alternative to frozen dimensions - np.cross
> could just become a regular ufunc with signature np.dtype((float64, 3)),
> np.dtype((float64, 3))
Thanks for the writeup Marten,
Nathaniel:
Output shape feels very similar to
output dtype to me, so maybe the general way to handle this would be
to make the first callback take the input shapes+dtypes and return the
desired output shapes+dtypes?
This hits on an interesting alternative to
Rendered here:
https://github.com/mhvk/numpy/blob/nep-gufunc-signature-enhancement/doc/neps/nep-0020-gufunc-signature-enhancement.rst
Eric
On Sun, 10 Jun 2018 at 09:37 Marten van Kerkwijk
wrote:
> OK, I spent my Sunday morning writing a NEP. I hope this can lead to some
> closure...
> See
Hi Nathaniel,
On Matt's prompting, I added release notes to the frozen/flexible PR [1];
see text attached below.
Having done that, I felt the examples actually justified the frozen
dimensions quite well. Given that you're the who expressed most doubts
about them, could you have a look? Ideally,
Stephan, good point about use cases. I think its still an odd fit. For
example I think np.array_equal(np.zeros((3,3)), np.zeros((2,2))) or
np.array_equal([1], ['foo']) would be difficult or impossible to replicate
with a potential all_equal gufunc
On Thu, May 31, 2018 at 2:00 PM, Stephan Hoyer
On Thu, May 31, 2018 at 4:20 AM, Marten van Kerkwijk
wrote:
> Hi Nathaniel,
>
> I think the case for frozen dimensions is much more solid that just
> `cross1d` - there are many operations that work on size-3 vectors.
> Indeed, as I noted in the PR, I have just been wrapping a
>
On 05/31/2018 04:14 PM, Marten van Kerkwijk wrote:
> I am -1 on multiple signatures. We may revisit this in time, but for
> now I find the minimal intrusiveness of the current changes
> appealing, especially as it requires few to no changes whatsoever to
> the inner loop function.
On Wed, May 30, 2018 at 5:01 PM Matthew Harrigan
wrote:
> "short-cut to automatically return False if m != n", that seems like a
> silent bug
>
I guess it depends on the use-cases. This is how np.array_equal() works:
https://docs.scipy.org/doc/numpy/reference/generated/numpy.array_equal.html
On Thu, May 31, 2018 at 4:21 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> I think the case for frozen dimensions is much more solid that just
> `cross1d` - there are many operations that work on size-3 vectors.
> Indeed, as I noted in the PR, I have just been wrapping a
>
On Thu, May 31, 2018 at 10:39 AM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> p.p.s. Your multiple dispatch signature for broadcasted dimensions is
> actually not quite right: should be
> (n|1),(n|1)->() ===>
>
> (n),(n)->() | (n),(1)->() | (1),(n)->() | (n),() -> () | (),(n)->()
>
p.p.s. Your multiple dispatch signature for broadcasted dimensions is
actually not quite right: should be
(n|1),(n|1)->() ===>
(n),(n)->() | (n),(1)->() | (1),(n)->() | (n),() -> () | (),(n)->()
This is becoming quite verbose... (and perhaps become somewhat slow).
Though arguably one could
p.s. While my test case of `cube_equal` in the PR is perhaps not
super-realistic, I don't know if one really wants to do multiple dispatch
on something like "(o|1,n|1,m|1),(o|1,n|1,m|1)->()"... -- Marten
___
NumPy-Discussion mailing list
Hi Allan,
Seeing it written out like that, I quite like the multiple dispatch
signature: perhaps verbose, but clear.
It does mean a different way of changing the ufunc structure, but I
actually think it has the advantage of being possible without extending the
structure (though that might still
On 05/31/2018 12:10 AM, Nathaniel Smith wrote:
On Wed, May 30, 2018 at 11:14 AM, Marten van Kerkwijk
- When it comes to the core ufunc machinery, we have a limited
complexity budget. I'm nervous that if we add too many bells and
whistles, we'll end up writing ourselves into a corner where we
On 05/31/2018 09:53 AM, Sebastian Berg wrote:
>
Also, I do not imagine these as free-floating ufuncs, I think we can
arrange them in a logical way in a gufunc ecosystem. There would be
some
"core ufuncs", with "associated gufuncs" accessible as attributes.
For
instance, any_less_than will be
Hi Sebastian,
This is getting a bit far off-topic (which is whether it is a good
idea to allow the ability to set frozen dimensions and broadcasting),
but on `all_equal`, I definitely see the point that a method might be
better, but that needs work: to expand the normal ufunc mechanism to
allow
While "on average" short-circuiting only gives a speedup of 2x, in many
situations you can arrange your algorithm so short circuiting will
happen early, eg usually in the first 10 elements of a 10^6 element
array, giving enormous speedups.
Also, I do not imagine these as free-floating ufuncs, I
> Incidentally, once we make reduce/accumuate/... into "associated gufuncs", I
> propose completely removing the "method" argument of __array_ufunc__, since
> it is no longer needed and adds a lot
> of complexity which implementors of an __array_ufunc__ are forced to
> account for.
For Quantity
> >
> > I'm currently -0.5 on both fixed dimensions and this broadcasting
> > dimension idea. My reasoning is:
> >
> > - The use cases seem fairly esoteric. For fixed dimensions, I guess
> > the motivating example is cross-product (are there any others?).
> > But
> > would it be so bad for a
On 05/31/2018 12:10 AM, Nathaniel Smith wrote:
On Wed, May 30, 2018 at 11:14 AM, Marten van Kerkwijk
wrote:
Hi All,
Following on a PR combining the ability to provide fixed and flexible
dimensions [1] (useful for, e.g., 3-vector input with a signature like
`(3),(3)->(3)`, and for `matmul`,
Hi Nathaniel,
I think the case for frozen dimensions is much more solid that just
`cross1d` - there are many operations that work on size-3 vectors.
Indeed, as I noted in the PR, I have just been wrapping a
Standards-of-Astronomy library in gufuncs, and many of its functions
require size-3
On Wed, May 30, 2018 at 11:14 AM, Marten van Kerkwijk
wrote:
> Hi All,
>
> Following on a PR combining the ability to provide fixed and flexible
> dimensions [1] (useful for, e.g., 3-vector input with a signature like
> `(3),(3)->(3)`, and for `matmul`, resp.; based on earlier PRs by Jaime
> [2]
Hi Stephan, Matt,
My `n|1` was indeed meant to be read as `n or 1`, but with the
(implicit) understanding that any array can have as many ones
pre-pended as needed.
The signature `(n?),(n?)->()` is now set aside for flexible
dimensions: this would allow the constant, but not the trailing shape
"short-cut to automatically return False if m != n", that seems like a
silent bug
AFAICT there are 3 possibilities:
1) current behavior
2) a scalar or size 1 array may be substituted, ie a constant
3) a scalar or array with shape[-1] == 1 may be substituted and broadcasted
I am fond of using
On Wed, May 30, 2018 at 11:15 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> My PR provides the ability to indicate in the signature that a core
> dimension can be broadcast, by using a suffix of "|1". Thus, the
> signature of `all_equal` would become:
>
> ```
> (n|1),(n|1)->()
>
Hi All,
Following on a PR combining the ability to provide fixed and flexible
dimensions [1] (useful for, e.g., 3-vector input with a signature like
`(3),(3)->(3)`, and for `matmul`, resp.; based on earlier PRs by Jaime
[2] and Matt (Picus) [3]), I've now made a PR with a further
enhancement,
30 matches
Mail list logo
