From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-03-25 13:19:44
Marcus Mendenhall wrote:
> For example, for
> bessel functions, one gets derivatives out of the same recursion
> relation (when recurring over the order) used to generate the
> function itself.
True. But why stop at order 2 ? Wouldn't one rather like to be able to
evaluate a function to arbitrary order say n? (y, y_1, y_2, ...y_n )
Then you would supply a
1) framework of function evaluation that returns a vector of derivatives
whose size is user specifiable or automatically selected by the algorithm
2) a set of algorithms that can make use of derivatives of up to order n.
3) a set of functions that are able to efficiently calculate not only
the function value but also the required number of derivatives.
E.g.:
sin(Pi/2,5) would return a vector (1,0,-1,0,1)
The 5 could be hidden when sin indeed is a functor e.g
boost:sin sin_5(5); (the return vector would need an appropriate
signature, so also vector valued functions are possible. )
So cn_functions would be more appropriate, since everything you said
about 2 can be said for n in general. You can get derivatives of
composed functions by recursively applying the rule for 2 can't you?
Or take multiplication: Simply apply the binomial formula to derivation.
It would be a nice exercise, to let the compiler do this at compile time
too. (Maybe by making use of the spirit library?)
This could lay out the ground for a framework to deal with non-linear
functions more efficiently while keeping the interface tidy.
The splines still being a special case of 3) to adhere to this
interface, but having also a very different interface too since you
would expect to be able to work on the inner representation of the
splines, i.e. getting access to the tables of function values and
derivatives. At least you will need to be able to calculate the spline
somehow.
Roland