Hi Ralf,
Thanks for the clarification. I think in your terms the bottom line was
that I thought we had a design B for the case where a function was really
"just a ufunc". But the nanfunctions show that even if logically they are a
ufunc (which admittedly uses another ufunc or two for `where`), it
On Fri, Jun 14, 2019 at 2:21 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> Thanks both for the reply and sharing the link. I recognize much (from
> both sides!).
>
>
>
>>
>> More importantly, I think we should not even consider *discussing*
>> removing`
On Thu, Jun 13, 2019 at 6:21 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> Thanks both for the reply and sharing the link. I recognize much (from
> both sides!).
>
>
>
>>
>> More importantly, I think we should not even consider *discussing*
>> removing`
Hi Ralf,
Thanks both for the reply and sharing the link. I recognize much (from both
sides!).
>
> More importantly, I think we should not even consider *discussing*
> removing` __array_function__` from np.isposinf (or any similar one off
> situation) before there's a new bigger picture design.
On Thu, Jun 13, 2019 at 9:43 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
>
>>> I guess the one immediate question is whether `np.sum` and the like
>>> should be overridden by `__array_function__` at all, given that what should
>>> be the future recommended override
Hi Ralf,
>> I guess the one immediate question is whether `np.sum` and the like
>> should be overridden by `__array_function__` at all, given that what should
>> be the future recommended override already works.
>>
>
> I'm not sure I understand the rationale for this. Design consistency
>
On Thu, Jun 13, 2019 at 7:07 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
>
>
> On Thu, Jun 13, 2019 at 12:46 PM Stephan Hoyer wrote:
>
>
>>
>>
>>> But how about `np.sum` itself? Right now, it is overridden by
>>> __array_function__ but classes without __array_function__ support
On Thu, Jun 13, 2019 at 12:46 PM Stephan Hoyer wrote:
>
>
>> But how about `np.sum` itself? Right now, it is overridden by
>> __array_function__ but classes without __array_function__ support can also
>> override it through the method lookup and through __array_ufunc__.
>>
>> Would/should there
On Thu, Jun 13, 2019 at 9:35 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf, others,
>
>
>>> Anyway, I guess this is still a good example to consider for how we
>>> should go about getting to a new implementation, ideally with just a
>>> single-way to override?
>>>
>>>
Hi Ralf, others,
>> Anyway, I guess this is still a good example to consider for how we
>> should go about getting to a new implementation, ideally with just a
>> single-way to override?
>>
>> Indeed, how do we actually envisage deprecating the use of
>> `__array_function__` for a given part of
On Thu, Jun 13, 2019 at 2:51 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi All,
>
> `nanfunctions` use `asanyarray` currently, which as Ralf notes scuppers
> the plan to use `asarray` - sorry to have been sloppy with stating they
> "convert to array".
>
> And, yes, I'll admit to
Hi All,
`nanfunctions` use `asanyarray` currently, which as Ralf notes scuppers the
plan to use `asarray` - sorry to have been sloppy with stating they
"convert to array".
And, yes, I'll admit to forgetting that we are introducing `where` only in
1.17 - clearly we cannot rely on other classes to
On Thu, Jun 13, 2019 at 3:16 AM Stephan Hoyer wrote:
> On Wed, Jun 12, 2019 at 5:55 PM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
>
>> Hi Ralf,
>>
>> You're right, the problem is with the added keyword argument (which would
>> appear also if we did not still have to support the
On Wed, Jun 12, 2019 at 5:55 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> You're right, the problem is with the added keyword argument (which would
> appear also if we did not still have to support the old .sum method
> override but just dispatched to __array_ufunc__
Hi Ralf,
You're right, the problem is with the added keyword argument (which would
appear also if we did not still have to support the old .sum method
override but just dispatched to __array_ufunc__ with `np.add.reduce` -
maybe worse given that it seems likely the reduce method has seen much less
On Wed, Jun 12, 2019 at 12:02 AM Stefan van der Walt
wrote:
> On Tue, 11 Jun 2019 15:10:16 -0400, Marten van Kerkwijk wrote:
> > In a way, I brought it up mostly as a concrete example of an internal
> > implementation which we cannot change to an objectively cleaner one
> because
> > other
> In a way, I brought it up mostly as a concrete example of an internal
> implementation which we cannot change to an objectively cleaner one because
> other packages rely on an out-of-date numpy API.
>
> Should have added: rely on an out-of-date numpy API where we have multiple
ways for packages
On Tue, 2019-06-11 at 10:56 +0200, Ralf Gommers wrote:
>
>
> On Mon, Jun 10, 2019 at 7:47 PM Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote:
> > Hi All,
> >
> > In https://github.com/numpy/numpy/pull/12801, Tyler has been trying
> > to use the new `where` argument for reductions to
On Mon, Jun 10, 2019 at 7:47 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi All,
>
> In https://github.com/numpy/numpy/pull/12801, Tyler has been trying to
> use the new `where` argument for reductions to implement `nansum`, etc.,
> using simplifications that boil down to
On Mon, 2019-06-10 at 13:47 -0400, Marten van Kerkwijk wrote:
> Hi All,
>
> In https://github.com/numpy/numpy/pull/12801, Tyler has been trying
> to use the new `where` argument for reductions to implement `nansum`,
> etc., using simplifications that boil down to `np.sum(...,
>
Hi All,
In https://github.com/numpy/numpy/pull/12801, Tyler has been trying to use
the new `where` argument for reductions to implement `nansum`, etc., using
simplifications that boil down to `np.sum(..., where=~isnan(...))`.
A problem that occurs is that `np.sum` will use a `.sum` method if
21 matches
Mail list logo
