Coefficients

[ajl12504]

Currently, the command f[k] returns the x^(n-k+1) coefficient of a degree n polynomial, f. It seems more intuitive to return the x^k coefficient (which would also simplify comparing coefficients of polynomials of different degrees).

[vtjnash]

while true, it is interesting to note that both matlab and numpy use this ordering

[vtjnash]

I don't see anyway to reasonably support both API's in a single Package without incurring unnecessary confusion

[StefanKarpinski]

Oo, that seems rather unfortunate. I would be in favor of f[k] returning the coefficient of x^k only. Both seems unnecessary, but returning the x^(n-k+1) coefficient just seems perverse.

[vtjnash]

How do you propose to switch? Why did numpy use the same order?

[JeffBezanson]

+1 for this change.

I suspect numpy copied matlab, and matlab did it to make the coefficients match traditional notation when shown left-to-right in a vector. Really bad decision.

[Keno]

I'd be happy to implement this if people will take it. Right now I'm using my own Polynomial package for precisely this reason.

[vtjnash]

If you can convince me that it won't break someone's code, without at least a warning, then go for it.

[Keno]

I'm not sure if there's anyway to guarantee this. We could probably ping known users of this package and let them know. The other, more drastic, option is to clone the package somewhere else (JuliaLang?) with a slightly different name (e.g. Polynomials.jl) make this fork deprecated and do the switch on the other one.

[JeffBezanson]

Deprecating the whole package and adding an "s" seems like the safest option.

[StefanKarpinski]

Agreed. Just fork it (so you keep git history), change the name to Polynomials, maybe make the type it defines Polynomial, change the way it works and deprecate this package for being singular.

[Keno]

I've started on this here: https://github.com/loladiro/Polynomials.jl. The division and roots algorithm still need to be updated, but other than that it works (I'll get back to this over the weekend).

[Keno]

There is a remaining question of whether or not the storage and construction order should remain the same. I have no particular as to what way is better. Any preferences?

[StefanKarpinski]

Storage and construction order should all match: lowest order to highest. It's not the way these are written traditionally, but it's best to be completely consistent.

[vtjnash]

it's not consistent either way because of the off-by-one.

so it seems preferable to me to make them more visually pleasing in the constructor

[StefanKarpinski]

The off-by-one is not a big deal, having inconsistent order really is. The convention of writing polynomials form highest to lowest coefficient is just that – a convention. Mathematica even prints them in the other order by default. We should follow suit. This is how it should work:

julia> p = Polynomial(1,2,3)
1x^0 + 2x^1 + 3x^2

julia> p.coefficients
[1,2,3]

Printing the polynomial from lowest to highest order is not a big deal for reading it and clearly sets the expectation that you will get coefficients from lowest to highest when indexing.

[StefanKarpinski]

There should also probably be a Polynomial constructor that takes an iterable and gets its coefficients from it. You really don't want Polynomial(1,2,3) and Polynomial([1,2,3]) to do different things.

[jiahao]

fwiw, in just about all the mathematical references I can find, there is more or less a single conventional notation for polynomials, which is

for univariate polynomials and

for multivariate polynomials. (Note that the coefficients form a zero-based array.)

I think the principle of least surprise would say that we should go with the indexing convention of these coefficients.

[JeffBezanson]

100% agree with stefan.

[Keno]

Ok, I finally managed to get through the rest of it. loladiro/Polynomials.jl is now feature complete and with the correct coefficient indexing.

[daviddelaat]

Should this package be deprecated in favour of https://github.com/loladiro/Polynomials.jl ?

[vtjnash]

yes it is

[tkelman]

What's the status of registering (and enabling issues) on the replacement package? I'm about to write a bunch of code for piecewise polynomials and I'd like to base it on the new coefficient order.

[yakir12]

Shouldn't there be some message in Polynomial.jl stating that it's deprecated in favor of Polynomials.jl?

[goretkin]

I agree that this package needs some deprecation message.