commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] Some changes to Polynomial
Date Wed, 31 Mar 2004 16:21:46 GMT
Al Chou wrote:
> --- Phil Steitz <> wrote:
>>0. To help debug the SplineInterpolater (PR #28019 et al), I need to 
>>expose the coefficients in o.a.c.m.analysis.Polynomial as a read-only 
>>property (returning an array copy). Any objections to adding this?
> +1 if you do it by adding a package-level-accessible (i.e., no access modifier
> keyword; the JUnit test would be able to access it by being in the same
> package) getter method -- which sounds like what you're proposing.
I actually intended to make this public, but read-only and using copy 
semantics. Any client should have (read-only) access to this basic 
property of the Polynomial, IMHO.


>>While reviewing the code, I also noticed that the current impl uses 
>>"naive" evaluation (using Math.pow, etc.).  I would like to change this to 
>>use Horner's Method.  Here is what I have ready to commit:
>>1. Add protected static double evaluate(double[] coefficients, double 
>>argument) implementing Horner to get the function value; and change 
>>value(double) to just call this.
>>2. Add protected static double[] differentiate(double[] coefficients) to 
>>return the coefficients of the derivative of the polynomial with 
>>coefficients equal to the actual parameter.  Then change 
>>firstDerivative(x) to just return
>>evaluate(differentiate(coefficients), x).  Similar for secondDerivative.
>>I could adapt Horner for the derivatives, but that seems messy to me and 
>>the slight memory cost to create the temp arrays seems worth it.
>>3. I would also like to add
>>public PolynomialFunction derivative() {
>>   return new PolynomialFunction(differentiate(coefficients));
>>Any objections to this?
> +1, these sound reasonable.
>>Interestingly, while Horner's method should give better numerics, it 
>>actually fails to get within 1E-15 for one of the quintic test cases, 
>>performing worse than the "naive" impl. The error is in the 16th 
>>significant digit, which is not surprising.  I would like to change the 
>>tolerance to 1E-12 (current tests actually succeed at 1E-14).
> I wonder why that is?  Does Math.pow() use higher-than-double precision and
> then cast down to double?  I think we should consider carefully what is implied
> by the fact that Horner's method has worse precision.  Also, I would in
> principle like to leave the tolerance as tight as possible, 1E-14 in this case.
> Al
> __________________________________
> Do you Yahoo!?
> Yahoo! Finance Tax Center - File online. File on time.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message