As the author of Polynomial.jl, I'll say that being "a bit
unsatisfied" is a good reason to make pull requests for any and all
improvements :)
While loladiro is now the official maintainer of Polynomials.jl (since
he volunteered to do the badly-needed work to switch the coefficient
order), if I had access, I would accept a pull request for additional
roots() methods (parameterized by an enum type, for overloading, and
possibly also a realroots function), horner method functions, polyfit,
etc.
I would not accept a pull request for allowing a vector instead of a
Polynomial in any method, however. IMHO, this is a completely
unnecessary "optimization", which encourages the user to conflate the
concept of a Vector and a Polynomial without benefit. It could even
potentially lead to subtle bugs (since indexing a polynomial is
different from indexing a vector), or passing in the roots instead of
the polynomial.
I think merging your proposal for a polyfit function with
StatsBase.fit makes sense. You could use a tuple parameter to combine
the Polynomial parameter with the degrees information:
function fit((T::(Type{Polynomial},Int), data)
P, deg = T
return Poly( pfit(deg, data) ) #where pfit represents the
calculation of the polynomial-of-best fit, and may or may not be a
separate function
end
fit((Polynomial,3), data)
David de Laat put together a pull request to add his content to
Polynomial: https://github.com/vtjnash/Polynomial.jl/pull/25. He also
indicated he would update it for Polynomials.jl so that it could be
merged.
On Thu, May 8, 2014 at 8:23 AM, Hans W Borchers <hwborch...@gmail.com> wrote:
> Because I was a (tiny) bit unsatisfied with the Polynomial package,
> I wrote my own polynomial functions, like
>
> - polyval() to be applied to vectors as well as polynomial types
> - roots() that uses the Matlab order in constructing the companion
> matrix and finding all roots
> - horner() that utilizes the Horner scheme to compute the value
> and the derivative of the polynomial at the same time
> (useful for a specialized version of Newton's algorithm)
> - a deflated Horner function to return p(x) = (x - x0)*q(x) when
> x is a root of polynomial p
> - polyfit() for fitting polynomials to data, etc.
>
> I think a polyfit() function should in any case be a part of a polynomial
> package. (Is such a function contained in any other package?)
>
> Besides that an implementation of the Muller algorithm for computing zeros
> of
> polynomials might be helpful. Or the calculation of the number of real roots
> of a polynomial in an interval (Descartes' and Sturm's rules). There is more
> interesting numerical stuff that could be part of such a polynomial package.
>
>
> On Thursday, May 8, 2014 3:42:03 AM UTC+2, Tony Kelman wrote:
>>
>> Yes, Polynomial is using a different convention than Matlab or what you
>> used below in how it constructs the companion matrix. Polynomials.jl uses
>> yet another convention. Both produce more accurate (comparable to Matlab)
>> results for the roots of the Wilkinson polynomial if you just switch the
>> indices during construction of the companion matrix. See
>> https://github.com/vtjnash/Polynomial.jl/blob/master/src/Polynomial.jl#L350-L353
>> for Polynomial, or
>> https://github.com/loladiro/Polynomials.jl/blob/master/src/Polynomials.jl#L324-L325
>> for Polynomials.
>>
>> I think the intent (see https://github.com/vtjnash/Polynomial.jl/issues/5)
>> is to deprecate Polynomial and switch the coefficient order by developing
>> under the Polynomials name going forward, but Keno's probably been too busy
>> to register the new package, turn on issues, etc. I'm doing some work on
>> piecewise stuff in a branch of Polynomials, I might just adopt the package.
>> I know David de Laat has put together packages for sparse multivariate
>> polynomials https://github.com/daviddelaat/MultiPoly.jl and orthogonal
>> polynomials https://github.com/daviddelaat/Orthopolys.jl, don't think
>> they're registered but it might make sense to eventually unify all of these
>> into the same package.
>
>
