Re: [math] Some changes to Polynomial
Al Chou wrote:
--- Phil Steitz [EMAIL PROTECTED] 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.
Phil
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).
Phil
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.
http://taxes.yahoo.com/filing.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Some changes to Polynomial
Al Chou wrote:
Have we considered a design for the general derivative case (i.e. for
UnivariateRealFunction objects)? I was thinking about a
Differentiable interface that either extends from URF or is a base
interface. It would have a single derivative method with a URF return
value.
Specialized URF types, like PolynomialFunction, could implement and
general derivative method and could provide their own specialized
derivative methods. Much like java.util.List with iterator and
listIterator.
With this approach, the derivative impl for PolynomialFunction could
be:
public PolynomialFunction polynomialDerivative() {
return new PolynomialFunction(differentiate(coefficients));
}
public UnivariateRealFunction derivative() {
return polynomialDerivative();
}
I like this. If there are no objections, I will make these changes to
Polynomial and add DURF extending URF (unless others feel that a base
interface would be better??)
I have a couple more questions on this, actually for URF in general:
1. Should we throw MathException, IllegalArgumentException or some new
exception if value() is invoked with an argument outside of the domain of
the function? I would expect function implementations (including
derivatives) to be able to distinguish convergence / computation problems
from bad arguments and my inclination is to add something like
DomainException to throw when arguments are not in the domain of the function.
2. Should URF provide information about the domain of the function? Two
possibilites come to mind: (a) a boolean isTotal() property that just
determines whether the domain = R; and/or (b) a boolean isDefined(double)
method that determines whether or not the argument is in the domain of the
function. I think that it is reasonable to expect all implementations to
provide these; though (b) might be a challenge for some.
That seems pretty reasonable. Should we at least briefly explore what
multivariable differentiation would look like and see if that makes it clearer
what it should look like with a single variable?
For instance, a UnivariateRealFunction can be considered a special case of a
ScalarRealFunction (I thought about writing MultivariateRealFunction there, but
semantically it seems wrong to call Univariate... a special case of
Multivariate...). For a RealFunction of n variables, the quintessential
derivatives are the first partial derivatives with respect to each of the n
variables, from which the gradient and other del-operator-based vector
functions spring. For second derivatives we quickly generate the matrix of all
mixed partial derivatives.
Where is this leading? I guess one direction might be an interface containing
a differentiate() method that calculates a first derivative, which in n
dimensions would require the user to specify which of the n variables to
differentiate with respect to, but in one dimension would not, for obvious
reasons. So I guess the Brent's suggestion holds, and the generalization to
more dimensions would be
public ScalarRealFunction derivative(Variable x) {
// implementation of first derivative with respect to x
}
I don't care to tackle vector functions of any number of variables at the
moment. g
I think that things change fundamentally when you consider the
multivariate case -- even for scalar functions. The derivative becomes
the Jacobian matrix.
I agree that it is a good idea to think about these things now; but I
guess my feeling is that things will get matrix / transformation oriented
when we start representing differentiable transformations and I don't
think it is a good idea to start by modeling univariate real functions as
1x1 transformations. Of course, we can always add a
DifferentiableTransformation interface that DURFs could implement by
returning 1x1 Jacobians ;-)
I think it will be best for us to follow the time-honored tradition of
treating R-R functions specially, exploiting the nice closure property
that the derivative of a real-valued real function is another R-R
function. Good idea to raise this now, though.
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Some changes to Polynomial
--- Phil Steitz [EMAIL PROTECTED] wrote: Al Chou wrote: --- Phil Steitz [EMAIL PROTECTED] 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. Yes, you're right. +1 Al __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Some changes to Polynomial
--- Phil Steitz [EMAIL PROTECTED] wrote:
Al Chou wrote:
Have we considered a design for the general derivative case (i.e. for
UnivariateRealFunction objects)? I was thinking about a
Differentiable interface that either extends from URF or is a base
interface. It would have a single derivative method with a URF return
value.
Specialized URF types, like PolynomialFunction, could implement and
general derivative method and could provide their own specialized
derivative methods. Much like java.util.List with iterator and
listIterator.
With this approach, the derivative impl for PolynomialFunction could
be:
public PolynomialFunction polynomialDerivative() {
return new PolynomialFunction(differentiate(coefficients));
}
public UnivariateRealFunction derivative() {
return polynomialDerivative();
}
I like this. If there are no objections, I will make these changes to
Polynomial and add DURF extending URF (unless others feel that a base
interface would be better??)
I have a couple more questions on this, actually for URF in general:
1. Should we throw MathException, IllegalArgumentException or some new
exception if value() is invoked with an argument outside of the domain of
the function? I would expect function implementations (including
derivatives) to be able to distinguish convergence / computation problems
from bad arguments and my inclination is to add something like
DomainException to throw when arguments are not in the domain of the
function.
DomainException (or some similar name) as a descendant of
IllegalArgumentException, maybe?
2. Should URF provide information about the domain of the function? Two
possibilites come to mind: (a) a boolean isTotal() property that just
determines whether the domain = R; and/or (b) a boolean isDefined(double)
method that determines whether or not the argument is in the domain of the
function. I think that it is reasonable to expect all implementations to
provide these; though (b) might be a challenge for some.
A great idea. Part of me wants to make this information live in an optionally
implemented interface, for those cases where it's too difficult to implement.
However, another part of me says that if you write a function evaluation
algorithm, you really ought to know what its domain of validity is. Chances
are you're having to handle different regions of that domain differently
anyway, to provide good accuracy or convergence rate throughout the domain, so
it's not a stretch to say you should know what the whole domain is.
That seems pretty reasonable. Should we at least briefly explore what
multivariable differentiation would look like and see if that makes it
clearer
what it should look like with a single variable?
For instance, a UnivariateRealFunction can be considered a special case of
a
ScalarRealFunction (I thought about writing MultivariateRealFunction there,
but
semantically it seems wrong to call Univariate... a special case of
Multivariate...). For a RealFunction of n variables, the quintessential
derivatives are the first partial derivatives with respect to each of the n
variables, from which the gradient and other del-operator-based vector
functions spring. For second derivatives we quickly generate the matrix of
all
mixed partial derivatives.
Where is this leading? I guess one direction might be an interface
containing
a differentiate() method that calculates a first derivative, which in n
dimensions would require the user to specify which of the n variables to
differentiate with respect to, but in one dimension would not, for obvious
reasons. So I guess the Brent's suggestion holds, and the generalization
to
more dimensions would be
public ScalarRealFunction derivative(Variable x) {
// implementation of first derivative with respect to x
}
I don't care to tackle vector functions of any number of variables at the
moment. g
I think that things change fundamentally when you consider the
multivariate case -- even for scalar functions. The derivative becomes
the Jacobian matrix.
I agree that it is a good idea to think about these things now; but I
guess my feeling is that things will get matrix / transformation oriented
when we start representing differentiable transformations and I don't
think it is a good idea to start by modeling univariate real functions as
1x1 transformations. Of course, we can always add a
DifferentiableTransformation interface that DURFs could implement by
returning 1x1 Jacobians ;-)
I think it will be best for us to follow the time-honored tradition of
treating R-R functions specially, exploiting the nice closure property
that the derivative of a real-valued real function is another R-R
function. Good idea to raise this now, though.
I did think about the Jacobian, though my personal experience in mathematical
physics didn't encounter it very
[math] Some changes to Polynomial
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?
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?
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).
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Some changes to Polynomial
On Tue, 30 Mar 2004 21:29:42 -0700, 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. Add protected static double evaluate(double[] coefficients,
double
argument) implementing Horner to get the function value; and change
value(double) to just call this.
+1
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.
+1 on the differntiate method.
Are the firstDerivate and secondDerivative methods needed anymore with
the addition of your derivative method below? I would favor removing
the prior two methods if possible.
3. I would also like to add
public PolynomialFunction derivative() {
return new PolynomialFunction(differentiate(coefficients));
}
Have we considered a design for the general derivative case (i.e. for
UnivariateRealFunction objects)? I was thinking about a
Differentiable interface that either extends from URF or is a base
interface. It would have a single derivative method with a URF return
value.
Specialized URF types, like PolynomialFunction, could implement and
general derivative method and could provide their own specialized
derivative methods. Much like java.util.List with iterator and
listIterator.
With this approach, the derivative impl for PolynomialFunction could
be:
public PolynomialFunction polynomialDerivative() {
return new PolynomialFunction(differentiate(coefficients));
}
public UnivariateRealFunction derivative() {
return polynomialDerivative();
}
Counter thoughts?
Brent Worden
http://www.brent.worden.org/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Some changes to Polynomial
--- Phil Steitz [EMAIL PROTECTED] 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.
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).
Phil
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.
http://taxes.yahoo.com/filing.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [math] Some changes to Polynomial
--- [EMAIL PROTECTED] wrote:
On Tue, 30 Mar 2004 21:29:42 -0700, 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. Add protected static double evaluate(double[] coefficients,
double
argument) implementing Horner to get the function value; and change
value(double) to just call this.
+1
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.
+1 on the differntiate method.
Are the firstDerivate and secondDerivative methods needed anymore with
the addition of your derivative method below? I would favor removing
the prior two methods if possible.
+1 to Brent's suggestion. These methods seem very redundant now, and I never
really liked naming these explicitly, as they seem to beg for derivatives of
all orders to then be named explicitly as well.
3. I would also like to add
public PolynomialFunction derivative() {
return new PolynomialFunction(differentiate(coefficients));
}
Have we considered a design for the general derivative case (i.e. for
UnivariateRealFunction objects)? I was thinking about a
Differentiable interface that either extends from URF or is a base
interface. It would have a single derivative method with a URF return
value.
Specialized URF types, like PolynomialFunction, could implement and
general derivative method and could provide their own specialized
derivative methods. Much like java.util.List with iterator and
listIterator.
With this approach, the derivative impl for PolynomialFunction could
be:
public PolynomialFunction polynomialDerivative() {
return new PolynomialFunction(differentiate(coefficients));
}
public UnivariateRealFunction derivative() {
return polynomialDerivative();
}
Counter thoughts?
Brent Worden
http://www.brent.worden.org/
That seems pretty reasonable. Should we at least briefly explore what
multivariable differentiation would look like and see if that makes it clearer
what it should look like with a single variable?
For instance, a UnivariateRealFunction can be considered a special case of a
ScalarRealFunction (I thought about writing MultivariateRealFunction there, but
semantically it seems wrong to call Univariate... a special case of
Multivariate...). For a RealFunction of n variables, the quintessential
derivatives are the first partial derivatives with respect to each of the n
variables, from which the gradient and other del-operator-based vector
functions spring. For second derivatives we quickly generate the matrix of all
mixed partial derivatives.
Where is this leading? I guess one direction might be an interface containing
a differentiate() method that calculates a first derivative, which in n
dimensions would require the user to specify which of the n variables to
differentiate with respect to, but in one dimension would not, for obvious
reasons. So I guess the Brent's suggestion holds, and the generalization to
more dimensions would be
public ScalarRealFunction derivative(Variable x) {
// implementation of first derivative with respect to x
}
I don't care to tackle vector functions of any number of variables at the
moment. g
Al
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
