Re: [Numpy-discussion] rackspace ssl certificates

2018-06-30 Thread Matthew Brett
On Sat, Jun 30, 2018 at 12:36 AM, Charles R Harris wrote: > > > On Fri, Jun 29, 2018 at 4:35 PM, Matthew Brett > wrote: >> >> On Fri, Jun 29, 2018 at 11:31 PM, Charles R Harris >> wrote: >> > >> > >> > On Tue, Jun 26, 2018 at 3:55 PM, Matthew Brett >> > wrote: >> >> >> >> Hi, >> >> >> >> On Tue

[Numpy-discussion] Fwd: Allowing broadcasting of code dimensions in generalized ufuncs

2018-06-30 Thread Marten van Kerkwijk
Hi All, In case it was missed because people have tuned out of the thread: Matti and I proposed last Tuesday to accept NEP 20 (on coming Tuesday, as per NEP 0), which introduces notation for generalized ufuncs allowing fixed, flexible and broadcastable core dimensions. For one thing, this will all

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

2018-06-30 Thread Marten van Kerkwijk
On Fri, Jun 29, 2018 at 9:54 PM, Eric Wieser wrote: > Good catch, > > I think the latter failing is because np.add.reduce ends up calling > np.ufunc.reduce.__get__(np.add), and builtin_function.__get__ doesn’t > appear to do any caching. I suppose caching bound methods would just be a > waste of

Re: [Numpy-discussion] rackspace ssl certificates

2018-06-30 Thread Charles R Harris
Not to worry, I'll just wait on the daily. On Sat, Jun 30, 2018 at 2:32 AM, Matthew Brett wrote: > On Sat, Jun 30, 2018 at 12:36 AM, Charles R Harris > wrote: > > > > > > On Fri, Jun 29, 2018 at 4:35 PM, Matthew Brett > > wrote: > >> > >> On Fri, Jun 29, 2018 at 11:31 PM, Charles R Harris > >>

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

2018-06-30 Thread Marten van Kerkwijk
Hi Hameer, It is. The point of the proposed feature was to handle array generation > mechanisms, that don't take an array as input in the standard NumPy API. > Giving them a reference handles both the dispatch and the decision about > which implementation to call. > Sorry, I had clearly misunder

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

2018-06-30 Thread Hameer Abbasi
Hi Marten, Sorry, I had clearly misunderstood. It would indeed be nice for overrides to work on functions like `zeros` or `arange` as well, but it seems strange to change the signature just for that. As a possible alternative, should we perhaps generally check for overrides on `dtype`? While thi

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-30 Thread Maxwell Aifer
Thanks, that explains a lot! I didn't realize the reverse ordering actually originated with matlab's polyval, but that makes sense given the one-based indexing. I see why it is the way it is, but I still think it would make more sense for np.polyval() to use conventional indexing (c[0] * x^0 + c[1]

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

2018-06-30 Thread Marten van Kerkwijk
Hi Hameer, I think the override on `dtype` would work - after all, the override is checked before anything is done, so one can just pass in `self` if one wishes (or some helper class that contains both `self` and any desired further information. But, as you note, it would not cover everything, an

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-30 Thread Eric Wieser
> if a single program uses both np.polyval() and np.polynomail.Polynomial, it seems bound to cause unnecessary confusion. Yes, I would recommend definitely not doing that! > I still think it would make more sense for np.polyval() to use conventional indexing Unfortunately, it's too late for "ma

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-30 Thread Charles R Harris
On Sat, Jun 30, 2018 at 12:09 PM, Eric Wieser wrote: > > if a single program uses both np.polyval() and > np.polynomail.Polynomial, it seems bound to cause unnecessary confusion. > > Yes, I would recommend definitely not doing that! > > > I still think it would make more sense for np.polyval() t

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

2018-06-30 Thread Hameer Abbasi
Hi Marten, Still, I'm not sure whether this should be included in the present NEP or is best done separately after, with a few concrete examples of where it would be useful. There already are concrete examples from Dask and CuPy, and this is currently a blocker for them, which is part of the rea

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

2018-06-30 Thread Stephan Hoyer
On Sat, Jun 30, 2018 at 11:59 AM Hameer Abbasi wrote: > Hi Marten, > > Still, I'm not sure whether this should be included in the present NEP or > is best done separately after, with a few concrete examples of where it > would be useful. > > > There already are concrete examples from Dask and CuP

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-30 Thread Ilhan Polat
I think restricting polynomials to time series is not a generic way and quite specific. Apart from the series and certain filter design actual usage of polynomials are always presented with decreasing order (control and signal processing included because they use powers of s and inverse powers of

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-30 Thread Charles R Harris
On Sat, Jun 30, 2018 at 1:08 PM, Ilhan Polat wrote: > I think restricting polynomials to time series is not a generic way and > quite specific. > I think more of complex analysis and it's use of series. > Apart from the series and certain filter design actual usage of > polynomials are always

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-30 Thread Eric Wieser
“the intuitive way” is the decreasing powers. An argument against this is that accessing the ith power of x is spelt: - x.coeffs[i] for increasing powers - x.coeffs[-i-1] for decreasing powers The former is far more natural than the latter, and avoids a potential off-by-one error If I ask

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-30 Thread Maxwell Aifer
Interesting, I wasn't aware that both conventions were widely used. Speaking of series with inverse powers (i.e. Laurent series), I wonder how useful it would be to create a class to represent expressions with integral powers from -m to n. These come up in my work sometimes, and I usually represe

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-30 Thread Eric Wieser
Since the one of the arguments for the decreasing order seems to just be textual representation - do we want to tweak the repr to something like Polynomial(lambda x: 2*x**3 + 3*x**2 + x + 0) (And add a constructor that calls the lambda with Polynomial(1)) Eric ​ On Sat, 30 Jun 2018 at 14:30 Eri

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-30 Thread Maxwell Aifer
Oh, clever... yeah I think that would be very cool. But shouldn't it call the constructor with Polynomial([0,1])? On Sat, Jun 30, 2018 at 5:41 PM, Eric Wieser wrote: > Since the one of the arguments for the decreasing order seems to just be > textual representation - do we want to tweak the repr

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-30 Thread Maxwell Aifer
*shouldn't the constructor call the lambda with Polynomial([0,1[) On Sat, Jun 30, 2018 at 6:05 PM, Maxwell Aifer wrote: > Oh, clever... yeah I think that would be very cool. But shouldn't it call > the constructor with Polynomial([0,1])? > > On Sat, Jun 30, 2018 at 5:41 PM, Eric Wieser > wrote:

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-30 Thread Eric Wieser
Good catch, it would do that On Sat, 30 Jun 2018 at 15:07 Maxwell Aifer wrote: > *shouldn't the constructor call the lambda with Polynomial([0,1[) > > On Sat, Jun 30, 2018 at 6:05 PM, Maxwell Aifer > wrote: > >> Oh, clever... yeah I think that would be very cool. But shouldn't it call >> the co

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-30 Thread Charles R Harris
On Sat, Jun 30, 2018 at 4:42 PM, Charles R Harris wrote: > > > On Sat, Jun 30, 2018 at 3:41 PM, Eric Wieser > wrote: > >> Since the one of the arguments for the decreasing order seems to just be >> textual representation - do we want to tweak the repr to something like >> >> Polynomial(lambda x:

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

2018-06-30 Thread Charles R Harris
On Sat, Jun 30, 2018 at 3:41 PM, Eric Wieser wrote: > Since the one of the arguments for the decreasing order seems to just be > textual representation - do we want to tweak the repr to something like > > Polynomial(lambda x: 2*x**3 + 3*x**2 + x + 0) > > (And add a constructor that calls the lamb

Re: [Numpy-discussion] Revised NEP-18, __array_function__ protocol

2018-06-30 Thread Robert Kern
On Sat, Jun 30, 2018 at 12:14 PM Stephan Hoyer wrote: > I’d love to see a generic way of doing random number generation, but I > agree with Martin that I don’t see it fitting a naturally into this NEP. An > invasive change to add an array_reference argument to a bunch of functions > might indeed