Add atol and rtol to Poly constructor

[jverzani]

This is a different way to address issue #38 than PR #39. It adds tolerances to the Poly constructor that propagate through the basic operations on polynomials (with rtol growing based on the operation). The advantages here over #39 are the default behaviour is unchanged. The use case of treating floating point coefficients as exact is easily done by setting atol to 0 in the constructor. The drawback is a possible speed hit. Benchmarking might help here.

[jverzani]

A few things. There aren't really that many functions like polyfit where a call to Poly is used. Adding arguments atol and rtol is not unrealistic. Adding rtol seemed like a good idea, as it allows one to reason about the error in the coefficients as one manipulates the polynomials. Your point about evaluation is apt, but this package provides a bit more than an efficient polyval and to me #39 makes those other parts much less user friendly. As pointed out, simple additions or subtractions lead to the wrong degree. Whereas, in your example the polyfit call works with atol=0 as desired for the leading coefficient, other coefficients are off by 2ulps. Expecting the result of some floating point calculation which produces the coefficients of interest to be so precise seems to be the exceptional case, not the default one.

As for memory, the memory footprint isn't much larger, but some benchmarking might be warranted.

[pwl]

I don't really like this PR, it bloats the API, makes adding other functions a chore (the package surely is not complete at its current state) and any other package using Polynomials would have to add the keyword arguments to keep the truncation away. And, if it gets adopted, changing it in the future would be difficult.

If this is all about the degree being ill defined for floating point coefficients, why not redefine it for the exact polynomials? This might be a crazy idea but more plausible to me then artificial truncation in the constructor:-).

degree{T}(p::Poly{T})=length(p)-1   # as before
degree{T<:AbstractFloat}(p::Poly{T})=NaN   # can be set to Inf alternatively

giving degree(Poly([0,1])) -> 1 and degree(Poly([0.0,1.0])) -> NaN. This way the degree is preserved through arithmetic operations and it propagates when mixing exact and inexact polynomials. Also degree is never used internally so its redefinition doesn't break anything.

Alternatively, less eccentrically, we could have

degree{T<:AbstractFloat}(p::Poly{T})=length(truncate(p))-1

although this would be sweeping the dust under the rug.

All in all the point about being user friendly really depends on what the users need. And I doubt that doing something mathematically shaky (truncation) under the hood is a good idea in numerical packages like this one. After all, users of numerical software should expect that floating point operations lead to errors.

[KlausC]

Couldn't express it better, thanks Pawel