 Phil Steitz <phil@steitz.com> 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 deloperatorbased 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 timehonored tradition of
> treating R>R functions specially, exploiting the nice closure property
> that the derivative of a realvalued 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 often. "Grad, div, curl, and all that" [1]
was everywhere dense, though.
I agree the multidimensional considerations are not really leading anywhere
useful fast. The 1D special case is so prevalent as to demand the usual
special treatment, as you say.
Al
[1] _Div, Grad, Curl, and All That: An Informal Text on Vector Calculus_, Harry
M. Schey, ISBN 0393969975.
__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center  File online. File on time.
http://taxes.yahoo.com/filing.html

To unsubscribe, email: commonsdevunsubscribe@jakarta.apache.org
For additional commands, email: commonsdevhelp@jakarta.apache.org
