Re: [Numpy-discussion] Polynomial evaluation inconsistencies

Ok I see what you mean. If people really want math-like symbolic representations for everything it’s probably better to use sympy or something On Mon, Jul 2, 2018 at 2:59 AM Eric Wieser wrote: > I think the `x` is just noise there, especially if it's ignored (that is, > `T[0](x*2)` doesn't do any

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

I think the `x` is just noise there, especially if it's ignored (that is, `T[0](x*2)` doesn't do anything reasonable). Chebyshev.literal(lambda T: 1*T[0] + 2*T[1] + 3*T[2]) Would work, but honestly I don't think that provides much clarity. I think the value here is mainly for "simple" polynom

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

Say we add a constructor to the polynomial base class that looks something like this: --- @classmethod def literal(cls, f): def basis_function_getter(self, deg): coefs = [0]*deg + [1

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

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] Polynomial evaluation inconsistencies

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

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

*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

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

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

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

“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

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

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

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] Polynomial evaluation inconsistencies

> 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

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] Polynomial evaluation inconsistencies

Here's my take on this, but it may not be an accurate summary of the history. `np.poly` is part of the original matlab-style API, built around `poly1d` objects. This isn't a great design, because they represent: p(x) = c[0] * x^2 + c[1] * x^1 + c[2] * x^0 For this reason, among others, the `

Re: [Numpy-discussion] Polynomial evaluation inconsistencies

On Fri, Jun 29, 2018 at 8:21 PM, Maxwell Aifer wrote: > Hi, > I noticed some frustrating inconsistencies in the various ways to evaluate > polynomials using numpy. Numpy has three ways of evaluating polynomials > (that I know of) and each of them has a different syntax: > >- > >numpy.poly

[Numpy-discussion] Polynomial evaluation inconsistencies

Hi, I noticed some frustrating inconsistencies in the various ways to evaluate polynomials using numpy. Numpy has three ways of evaluating polynomials (that I know of) and each of them has a different syntax: - numpy.polynomial.polynomial.Polynomial