I just tried roots in the Polynomial package
here's what happened
@time roots(Poly([randn(100)]));
LAPACKException(99)
while loading In[10], in expression starting on line 44
in geevx! at linalg/lapack.jl:1225
in eigfact! at linalg/factorization.jl:531
in eigfact at linalg/factorization.jl:554
in roots at /Users/julia/.julia/v0.3/Polynomial/src/Polynomial.jl:358
my first question would be why are we calling geevx for a matrix
known to be Hessenberg?
I'd be happy to have a time comparable to matlab's though i'm sure there
are faster algorithms out there as well
On Friday, May 9, 2014 11:21:11 PM UTC-4, Tony Kelman wrote:
>
> By default GitHub doesn't enable issue tracking in forked repositories,
> the person who makes the fork has to manually go do that under settings.
>
>
> On Friday, May 9, 2014 9:39:56 AM UTC-7, Hans W Borchers wrote:
>>
>> @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.
>>>>
>>>>
