@Jameson
I am writing a small report on scientific programming with Julia. I changed
the section on polynomials by now basing it on the newer(?) Polynomials.jl.
This works quite fine, and roots() computes the zeros of the Wilkinson
polynomial to quite satisfying accuracy.
It's a bit irritating that the README file still documents the old order of
sequence of coefficients while the code already implements the coefficients
in increasing order of exponents. I see there is a pull request for an
updated README, but this is almost 4 weeks old.
Testing one of my examples,
julia> using Polynomials
julia> p4 = poly([1.0, 1im, -1.0, -1im])
Poly(--1.0 + 1.0x^4)
which appears to indicate a bug in printing the polynomial. The stored
coefficient is really and correctly -1.0 as can be seen from
julia> p4[0]
-1.0 + 0.0im
I wanted to report that as an issue on the project page, but I did not find
a button for starting the issue tracker. Does this mean the Polynomial.jl
project is still 'private' in some sense?
I know there have been long discussions on which is the right order for the
coefficients of a polynomial. But I feel it uneasy that the defining order
in MATLAB and other numerical computing systems has been changed so
drastically. Well, we have to live with it.
On Friday, May 9, 2014 7:53:30 AM UTC+2, Hans W Borchers wrote:
>
> Thanks a lot. Just a few minutes ago I saw here on the list an announcement
> of the "Least-squares curve fitting package" with poly_fit, among others.
> I think this is good enough for me at the moment.
>
> I will come back to your suggestion concerning polynomials when I have a
> better command of the type system. For polynomials there is surprisingly
> many more interesting functionality than is usually implemented.
>
>
> On Friday, May 9, 2014 6:30:06 AM UTC+2, Jameson wrote:
>>
>> 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.
>>
>>
