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. >>> >>>