On Thu, May 31, 2018 at 4:50 PM, Matti Picus wrote:
> At the recent NumPy sprint at BIDS (thanks to those who made the trip) we
> spent some time brainstorming about a roadmap for NumPy, in the spirit of
> similar work that was done for Jupyter. The idea is that a document with
> wide community a
At the recent NumPy sprint at BIDS (thanks to those who made the trip)
we spent some time brainstorming about a roadmap for NumPy, in the
spirit of similar work that was done for Jupyter. The idea is that a
document with wide community acceptance can guide the work of the
full-time developer(s)
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
> Standards-of-Astron
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. M
>
> 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.
> Multiple dispatch could easily break that model by allowing very d
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
We
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
> Standards
On 31/05/18 08:23, Allan Haldane wrote:
Re: implenetation complexity, I just want to bring up multiple-dispatch
signatures again, where the new signature syntax would just be to join
some signatures together with "|", and try them in order until one works.
I'm not convinced it's better myself, I
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 always
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
NumPy-Discussion@
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 b
On Tue, May 29, 2018 at 9:24 AM, Charles R Harris wrote:
>
>
> On Tue, May 29, 2018 at 9:46 AM, Stephan Hoyer wrote:
>
>> Reviving this discussion --
>> I don't really care what our policy is, but can we make a decision one
>> way or the other about where we discuss NEPs? We've had a revival of
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 have
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 a
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 th
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 th
> 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 a
> >
> > 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 c
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`, res
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 vectors
21 matches
Mail list logo
