On Sat, May 11, 2019 at 4:04 AM Stephan Hoyer wrote:
> On Sat, May 4, 2019 at 12:29 PM Ralf Gommers
> wrote:
>
>> We seem to have run out of steam a bit here.
>>
>
> We discussed this today in person at the NumPy sprint.
>
> The consensus was to go for a name like __skip_array_function__. Ufuncs
On Sat, May 4, 2019 at 12:29 PM Ralf Gommers wrote:
> We seem to have run out of steam a bit here.
>
We discussed this today in person at the NumPy sprint.
The consensus was to go for a name like __skip_array_function__. Ufuncs
don't have very good use-cases for a function that skips dispatch:
We seem to have run out of steam a bit here.
On Tue, Apr 30, 2019 at 7:24 AM Stephan Hoyer wrote:
> On Mon, Apr 29, 2019 at 5:49 AM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>> The uses that I've seen so far (in CuPy and JAX), involve a handful of
>>> functions that are direc
On Mon, Apr 29, 2019 at 5:49 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> The uses that I've seen so far (in CuPy and JAX), involve a handful of
>> functions that are directly re-exported from NumPy, e.g.,
>> jax.numpy.array_repr is the exact same object as numpy.array_repr:
>>
>>
On Sun, Apr 28, 2019 at 9:20 PM Stephan Hoyer wrote:
> On Sun, Apr 28, 2019 at 8:42 AM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>> In summary, I think the guarantees should be as follows:
>> 1.If you call np.function and
>> - do not define __array_function__, changes happen o
On Sun, Apr 28, 2019 at 8:42 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> In summary, I think the guarantees should be as follows:
> 1.If you call np.function and
> - do not define __array_function__, changes happen only via the usual
> cycle.
> - define __array_function__, you
Hi Nathaniel,
Thanks, I now see your point. I think I can weasel my way partially out:
the default *output* from `np.concatenate` is an ndarray, so in that
respect it is not that strange that when no input defines
__array_function__, one would call `ndarray.__array_function__` (I realize
this is s
On Sun, Apr 28, 2019 at 1:38 PM Marten van Kerkwijk
wrote:
>
> Hi Nathaniel,
>
> I'm a bit confused why` np.concatenate([1, 2], [3, 4])` would be a problem.
> In the current model, all (numpy) functions fall back to
> `ndarray.__array_function__`, which does know what to do with anything that
>
Hey Stephan,
After some discussion with Ralf, I feel that the best way forward would be to
add the __numpy_implementation__ (which is my preferred name for it). While I
consider the interface final (or at least to the point where we would only add
functionality and not remove it), I would prefe
Hi Nathaniel,
I'm a bit confused why` np.concatenate([1, 2], [3, 4])` would be a problem.
In the current model, all (numpy) functions fall back to
`ndarray.__array_function__`, which does know what to do with anything that
doesn't have `__array_function__`: it just coerces it to array. Am I
missin
On Sun, Apr 28, 2019, 02:22 Ralf Gommers wrote:
> One other thought: the proposal in this thread is about skipping the
> override mechanism for numpy functions. NEP 18 reserves the freedom to swap
> out __array_function__ with __array_ufunc__ if we make something a ufunc.
> So __skipping_array_fu
On Sun, Apr 28, 2019, 08:41 Marten van Kerkwijk
wrote:
> Hi Ralf,
>
> Thanks for the comments and summary slides. I think you're
> over-interpreting my wish to break people's code! I certainly believe - and
> think we all agree - that we remain as committed as ever to ensure that
> ```
> np.funct
On Sun, Apr 28, 2019 at 7:43 PM Evgeni Burovski
wrote:
> Hi Ralf,
>
> Would it be much hassle for you to duplicate your slides somewhere else,
> too?
>
Oh fun, SlideShare is blocked in Russia I see. So is
https://speakerdeck.com/. I just sent you the slides, will think about a
more structural so
Hi Ralf,
Would it be much hassle for you to duplicate your slides somewhere else,
too?
Cheers,
Evgeni
вс, 28 апр. 2019 г., 15:38 Ralf Gommers :
>
>
> On Sat, Apr 27, 2019 at 8:10 PM Ralf Gommers
> wrote:
>
>>
>> It seems like we all have a different mental model of what NEP 18
>> actually doe
On Sun, Apr 28, 2019 at 6:57 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> Agreed that the coercion right now is *not* generic, with some doing
> `asarray`, others `asanyarray` and yet others nothing. There are multiple
> possible solutions, with one indeed being that f
Hi Ralf,
Agreed that the coercion right now is *not* generic, with some doing
`asarray`, others `asanyarray` and yet others nothing. There are multiple
possible solutions, with one indeed being that for each function one moves
the coercion bits out to an associated intermediate function. In princi
On Sun, Apr 28, 2019 at 5:41 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> Thanks for the comments and summary slides. I think you're
> over-interpreting my wish to break people's code! I certainly believe - and
> think we all agree - that we remain as committed as ever
Hi Ralf,
Thanks for the comments and summary slides. I think you're
over-interpreting my wish to break people's code! I certainly believe - and
think we all agree - that we remain as committed as ever to ensure that
```
np.function(inputs)
```
continues to work just as before. My main comment is t
On Sat, Apr 27, 2019 at 8:10 PM Ralf Gommers wrote:
>
> It seems like we all have a different mental model of what NEP 18 actually
> does. I'm going to try to put mine on a few slides with diagrams/examples
> to see if that helps, since mailing list threads are hard to process.
>
Here is my atte
On Sun, Apr 28, 2019 at 5:02 AM Nathaniel Smith wrote:
> On Sat, Apr 27, 2019 at 7:46 PM Stephan Hoyer wrote:
> > Worst, "__wrapped__" would be difficult to search for, because it
> already means something in Python (referring to functools.wrapped). At
> least "__numpy_implementation__" and "__s
On Sat, Apr 27, 2019 at 4:39 PM Hameer Abbasi
wrote:
> On Saturday, Apr 27, 2019 at 6:21 PM, Stephan Hoyer
> wrote:
> Are there aspects of your uarray proposal that are relevant to the current
> proposed revisions to NEP 18? If so, please restate them :).
>
>
> Of course, here’s my proposal:
>
>
On Sat, Apr 27, 2019 at 7:46 PM Stephan Hoyer wrote:
> Worst, "__wrapped__" would be difficult to search for, because it already
> means something in Python (referring to functools.wrapped). At least
> "__numpy_implementation__" and "__skipping_array_function__" are both unique
> tokens without
On Sat, Apr 27, 2019 at 11:44 AM Ralf Gommers
wrote:
> On Sat, Apr 27, 2019 at 7:05 PM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>> Hi All,
>>
>> I agree with Ralf that there are two discussions going on, but also with
>> Hameer that they are related, in that part of the very pu
On Sat, Apr 27, 2019 at 4:38 PM Hameer Abbasi
wrote:
> Of course, here’s my proposal:
>
> We leave NEP-18 as-is for now, and instead of writing separate protocols
> for coercion, dtypes and ufuncs (which will be needed somewhere down the
> line), we have a discussion about uarray and see if it ca
Hi Stephan,
> On Saturday, Apr 27, 2019 at 6:21 PM, Stephan Hoyer (mailto:sho...@gmail.com)> wrote:
> On Fri, Apr 26, 2019 at 9:16 AM Hameer Abbasi (mailto:einstein.edi...@gmail.com)> wrote:
> > > That said, please save it a separate discussion thread, given that the
> > > design of uarray is (
Hi Ralf,
[snip]
> If I'm missing something that's actually in NEP 18, can you please point out
> the actual text?
NEP-22 is the high-level overview of the goals, but NEP-18 is the concrete
proposal for __array_function__. Quoting that NEP, right under “Implementation":
> The __array_function_
On 27/4/19 6:51 am, Marten van Kerkwijk wrote:
Maybe it is best to just stick with __wrapped__
+1 for simplicity, clarity (since __wrapped__ is part of the |documented
@functools.wraps() interface)|, and lowering expectations.
Matti
___
NumPy-
Hi All,
I agree with Ralf that there are two discussions going on, but also with
Hameer that they are related, in that part of the very purpose of
__array_function__ was to gain freedom to experiment with implementations.
And in particular the freedom to *assume* that inputs are arrays so that we
On Sat, Apr 27, 2019 at 7:05 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi All,
>
> I agree with Ralf that there are two discussions going on, but also with
> Hameer that they are related, in that part of the very purpose of
> __array_function__ was to gain freedom to experiment
On Fri, Apr 26, 2019 at 9:16 AM Hameer Abbasi
wrote:
> That said, please save it a separate discussion thread, given that the
> design of uarray is (wisely) orthogonal to NEP-18.
>
>
> I disagree, I don’t consider it orthogonal: I’m presenting a way to avoid
> the very protocols being discussed,
Hi Stephan,
> Hameer, it's great that you are exploring these problems with a fresh
> approach! I'm excited to see how dispatching problems could be solved without
> the constraint of compatibility with NumPy's legacy approaches.
>
> When you have a prototype and/or design documents ready for re
On Fri, Apr 26, 2019 at 3:10 AM Hameer Abbasi
wrote:
> Here’s how `uarray` solves each of these issues:
>
>1. Backends… There is no default implementation.
>2. This is handled by (thread-safe) context managers, which make
>switching easy.
>3. There’s one coercion function per type
On Fri, Apr 26, 2019 at 1:24 AM Ralf Gommers wrote:
> Thanks, this helped clarify what's going on here. This example is clear.
> The problem seems to be that there's two separate discussions in this
> thread:
> 1. your original proposal, __numpy_implementation__. it does not have the
> problem of
Here’s my take on it: The goal is basically “separation of interface from
implementation”, NumPy reference becomes just one (reference) implementation
(kind of like CPython is today). The idea is that unumpy/NumPy drive the
interface, while there can be many implementations.
To make duck-arrays
On Fri, Apr 26, 2019 at 1:02 AM Stephan Hoyer wrote:
> On Thu, Apr 25, 2019 at 3:39 PM Ralf Gommers
> wrote:
>
>>
>> On Fri, Apr 26, 2019 at 12:04 AM Stephan Hoyer wrote:
>>
>>> I do like the look of this, but keep in mind that there is a downside to
>>> exposing the implementation of NumPy fun
On Thu, Apr 25, 2019 at 3:39 PM Ralf Gommers wrote:
>
> On Fri, Apr 26, 2019 at 12:04 AM Stephan Hoyer wrote:
>
>> I do like the look of this, but keep in mind that there is a downside to
>> exposing the implementation of NumPy functions -- now the implementation
>> details become part of NumPy'
On Thu, Apr 25, 2019 at 6:04 PM Stephan Hoyer wrote:
> On Thu, Apr 25, 2019 at 12:46 PM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>
> It would be nice, though, if we could end up with also option 4 being
>> available, if only because code that just can assume ndarray will be
On Fri, Apr 26, 2019 at 12:04 AM Stephan Hoyer wrote:
> On Thu, Apr 25, 2019 at 12:46 PM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>> It seems we are adding to the wishlist! I see four so far:
>> 1. Exposed in API, can be overridden with __array_ufunc__
>> 2. One that converts
On Thu, Apr 25, 2019 at 12:46 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> It seems we are adding to the wishlist! I see four so far:
> 1. Exposed in API, can be overridden with __array_ufunc__
> 2. One that converts everything to ndarray (or subclass); essentially the
> current i
> What's __array_dtype__? That string doesn't seem to appear in the
> numpy source, and google has no hits…
This was a proposed protocol for dispatching over user-defined dtype objects, I
think Stephan and a few others wrote up a mock at SciPy 2018.
Best Regards,
Hameer Abbasi
signature.asc
D
On Thu, Apr 25, 2019 at 1:30 PM Hameer Abbasi wrote:
> Although, in general, I agree with Stephan’s design goals, I agree with
> Marten that the number of protocols are getting larger and may get out of
> hand if not handled properly. There’s even one Marten forgot to mention:
> __array_dtype__
On Thu, Apr 25, 2019 at 10:10 AM Stephan Hoyer wrote:
>
> On Wed, Apr 24, 2019 at 9:56 PM Nathaniel Smith wrote:
>>
>> When you say "numpy array specific" and
>> "__numpy_(nd)array_implementation__", that sounds to me like you're
>> trying to say "just step 3, skipping steps 1 and 2"? Step 3 is t
> On Thursday, Apr 25, 2019 at 9:45 PM, Marten van Kerkwijk
> mailto:m.h.vankerkw...@gmail.com)> wrote:
> It seems we are adding to the wishlist! I see four so far:
> 1. Exposed in API, can be overridden with __array_ufunc__
> 2. One that converts everything to ndarray (or subclass); essentially t
It seems we are adding to the wishlist! I see four so far:
1. Exposed in API, can be overridden with __array_ufunc__
2. One that converts everything to ndarray (or subclass); essentially the
current implementation;
3. One that does asduckarray
4. One that assumes all arguments are arrays.
Maybe h
On Wed, Apr 24, 2019 at 9:56 PM Nathaniel Smith wrote:
> When you say "numpy array specific" and
> "__numpy_(nd)array_implementation__", that sounds to me like you're
> trying to say "just step 3, skipping steps 1 and 2"? Step 3 is the one
> that operates on ndarrays...
>
My thinking was that if
On Wed, Apr 24, 2019 at 9:45 PM Stephan Hoyer wrote:
> With "__numpy_implementation__" I was hoping to evoke "the implementation
> used by numpy.ndarray.__array_function__" and "the implementation for NumPy
> arrays" rather than "the implementation found in the NumPy library." So it
> would sti
On Tue, Apr 23, 2019 at 12:27 AM Nathaniel Smith wrote:
> On Mon, Apr 22, 2019 at 11:13 PM Stephan Hoyer wrote:
> >
> >> On Mon, Apr 22, 2019 at 9:26 PM Nathaniel Smith wrote:
> >>>
> >>> Your last email didn't really clarify anything for me. I get that
> np.func.__numpy_implementation__ is int
On Tue, Apr 23, 2019 at 4:31 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi All,
>
> Reading the discussion again, I've gotten somewhat unsure that it is
> helpful to formalize a way to call an implementation that we can and
> hopefully will change. Why not just leave it at __wrap
Hi All,
Reading the discussion again, I've gotten somewhat unsure that it is
helpful to formalize a way to call an implementation that we can and
hopefully will change. Why not just leave it at __wrapped__? I think the
name is no worse and it is more obvious that one relies on something
private.
On Mon, Apr 22, 2019 at 11:13 PM Stephan Hoyer wrote:
>
>> On Mon, Apr 22, 2019 at 9:26 PM Nathaniel Smith wrote:
>>>
>>> Your last email didn't really clarify anything for me. I get that
>>> np.func.__numpy_implementation__ is intended to have the semantics of
>>> numpy's implementation of fun
On Mon, Apr 22, 2019 at 2:20 PM Ralf Gommers wrote:
>
>
> On Mon, Apr 22, 2019 at 9:26 PM Nathaniel Smith wrote:
>
>> Your last email didn't really clarify anything for me. I get that
>> np.func.__numpy_implementation__ is intended to have the semantics of
>> numpy's implementation of func, but
On Mon, Apr 22, 2019 at 9:26 PM Nathaniel Smith wrote:
> Your last email didn't really clarify anything for me. I get that
> np.func.__numpy_implementation__ is intended to have the semantics of
> numpy's implementation of func, but that doesn't tell me much :-). And
> also, that's exactly the de
Your last email didn't really clarify anything for me. I get that
np.func.__numpy_implementation__ is intended to have the semantics of
numpy's implementation of func, but that doesn't tell me much :-). And
also, that's exactly the definition of np.func, isn't it?
You're talking about ~doubling th
Are there still concerns here? If not, I would love to move ahead with
these changes so we can get this into NumPy 1.17.
On Tue, Apr 16, 2019 at 10:23 AM Stephan Hoyer wrote:
> __numpy_implementation__ is indeed simply a slot for third-parties to
> access NumPy's implementation. It should be con
__numpy_implementation__ is indeed simply a slot for third-parties to
access NumPy's implementation. It should be considered "NumPy's current
implementation", not "NumPy's implementation as of 1.14". Of course, in
practice these will remain very similar, because we are already very
conservative abo
I somewhat share Nathaniel's worry that by providing
`__numpy_implementation__` we essentially get stuck with the
implementations we have currently, rather than having the hoped-for freedom
to remove all the `np.asarray` coercion. In that respect, an advantage of
using `_wrapped` is that it is clea
I thought this was simply a slot to store the NumPy version of the
dispatched method, so that you could see easily call through to it and
extend it.
Stephan, was there a deeper intent here that I missed?
Best regards,
Stéfan
On April 15, 2019 20:32:35 Nathaniel Smith wrote:
On Mon, Apr 15,
On Mon, Apr 15, 2019 at 4:39 PM Stephan Hoyer wrote:
>
> On Mon, Apr 15, 2019 at 1:21 PM Nathaniel Smith wrote:
>>
>> What's the difference between
>>
>> np.concatenate.__numpy_implementation__(...)
>>
>> and
>>
>> np.ndarray.__array_function__(np.concatenate, ...)
>>
>> ?
>
>
> I can answer this
On Mon, Apr 15, 2019 at 1:21 PM Nathaniel Smith wrote:
> What's the difference between
>
> np.concatenate.__numpy_implementation__(...)
>
> and
>
> np.ndarray.__array_function__(np.concatenate, ...)
>
> ?
>
I can answer this technically, though this doesn't seem to be quite what
you're looking f
What's the difference between
np.concatenate.__numpy_implementation__(...)
and
np.ndarray.__array_function__(np.concatenate, ...)
?
More generally, I guess I'm not quite clear on how to think about what the
"no dispatch" version does, because obviously it doesn't make sense to have
*no* dispat
On Mon, 15 Apr 2019 08:30:06 -0700, Stephan Hoyer wrote:
> We have a proposed a revision to NEP-18 (__array_function__). The proposal
> is for an adding an alias to the non-dispatched version of NumPy array
> functions in the __numpy_implementation__ function attribute:
> https://github.com/numpy/n
61 matches
Mail list logo
