I received a lot of useful suggestions for the c2_functions package I am working on. This includes some replies & discussion to those comments. Thanks for the interest!

------------------------------

Message: 9 Date: Sat, 25 Mar 2006 09:36:23 -0000 From: "Paul A Bristow" <pbristow@hetp.u-net.com> Subject: Re: [boost] c2_functions first submission materials uploaded To: <boost@lists.boost.org> Message-ID: <E1FN5C4-0003Dl-3s@he303war.uk.vianw.net> Content-Type: text/plain; charset="us-ascii"

My knowledge in this field is only sufficient that I can tell that this shows some serious expertise in function fitting!

Boost is thin in support for important parts of numerical analysis that have wide, if sometimes apparently niche, potential application, and not just in 'rocket science' physics.

But in order to sell this to Boosters (as I know from experience with trying to promote widely used mathemetical functions), some better (and some simpler and gentler) real-life examples will be needed as well your erudite whitepaper.

Yes, I know I need a lot more examples. I am working on this. The predecessor to this package was written for internal use at Vanderbilt, inside my own code, so it was not well documented, other than by my own use. It appears now that interest is high enough that I will pursue fleshing out the docs.

------------------------------

Message: 12 Date: Sat, 25 Mar 2006 13:57:33 -0000 From: "John Maddock" <john@johnmaddock.co.uk> Subject: Re: [boost] c2_functions first submission materials uploaded To: <boost@lists.boost.org> Message-ID: <056001c65014$215da0f0$4ee70c52@fuji> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original

...

I have uploaded c2_functions.zip to the file vault. It contains the code for c2_functions (header & source), an html folder with Doxygen documentation, and a white paper describing the theory of this package. Anyone who is interested, look over this and let me know how the group wishes to proceed.

I particularly like the idea that the library is effectively doing symbolic math internally, could the library be adapted to output symbolic derivative information: so given a formula for f(x) tell you what the derivatives are?

I think that is what Mathematic is for! Really, I want to keep this a light-weight package.

With regard to the interface, it looks quite reasonable to me, questions likely to crop up during a review are:

1) Why restrict the library to double precision, could it made into a template that works at arbitrary precision? Yes, I could templatize the whole thing, I suppose. 2) Would it be possible to make c2function a handle-body class? The classes that currently inherit from c2function would then all become implementation details, and c2function would become a smart ptr to the actual representation. The advantage is that you can pass c2functions around without worrying about it's actual type (a lot like Boost.Function). Composition of primitives could be handled by non-member free functions, or by operators:

so given:

c2function a, b;

then:

c2function c = a*b; // does the right thing internally.

This is already supported by the package. I will have to investigate handle-body classes and see if they help. The c2_binary_function (and children) and c2_composed_function already allow what you describe.

3) How easy is the library to extend to new primitives, for example if someone wanted to add sinh or something would that be straightforward?

Very easy. Look at c2_sin(). Just provide a value_with_derivatives virtual function, and everything else happens automatically.

4) The library probably needs some concrete use cases to get people interested :-)

Agreed.

------------------------------

Message: 15 Date: Sat, 25 Mar 2006 10:34:59 -0500 From: Neal Becker <ndbecker2@gmail.com> Subject: Re: [boost] c2_functions first submission materials uploaded To: boost@lists.boost.org Message-ID: <e03nv2$j99$1@sea.gmane.org> Content-Type: text/plain; charset=us-ascii

1. Generic data types instead of hard-coded 'double'

I'm thinking about it... shouldn't be hard.

2. Generic container types instead of hard-coded 'std::vector'

Same

3. Does support of complex make any sense here?

Maybe, although a lot of the most useful things (interpolating functions & root finding) have very different meanings in the complex domain, so I think this probably belogs in son_of_c2_functions.

------------------------------

Message: 16 Date: Sat, 25 Mar 2006 16:46:47 +0100 From: Roland Schwarz <roland.schwarz@chello.at> Subject: Re: [boost] c2_functions first submission materials uploaded To: boost@lists.boost.org Message-ID: <442565E7.8000006@chello.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I have seen from the doc's that c2_functions will also deal with root finding of splines. From my experience with this topic I found that this is a numerically hard problem when interested in the number of roots, if the spline is being evaluated at it's splicing points. I.e. the number of roots might be different depending whether evaluated on the right or left side. As far as I remember the value of the root(s) could also differ slightly. I tried to cure this by defining the elementary functions on half open intervals, but besides forcing the end "interval" being a single point, I also found the asymmetry somewhat unsatisfying (which end should be open, based on what rationale?) I would be very interested if you have some findings in this area.

The cubic splines (as opposed to piecewise cubic interpolators) are very smooth at the boundaries, so I think there is not a problem there. It has worked for me with no difficulties.

Al tough it might sound stupid to ask for inversion of a non monotonic function it might be valuable to get it's main branch, the number of branches or even an array filled with c2_functions one of each represents one of the side branches. @Mendenhall: What do you think?

I think this is addressed by setting the domain (using set_domain) before root-finding or inversion. The global function need not be monotonic, only on the specified domain. Does this solve the problem?

I came across this type of problem when I tried to do "inverse- sampling" of a spline function. I.e. find the abscissa values that correspond to equal sized ordinate steps. (Finding the time instances when to apply impulses to a stepper motor, given the ordinate is the step number, to control time dependent position of the motor. The spline was the result of some algorithm where it turned out to be very handy to view it as a function. )

This is exactly the kind of thing I use splines and inverse_functions of splines for.

Do you also intend to build into the library the ability to construct the splines from the different possible data sets e.g x,y tables and various boundary conditions?

There is no reason not to do this, given manpower.

Did you consider extending the library to multivalued functions too?

That is a more complex issue, probably also for son_of_c2_functions.

Regards, Roland

Message: 17 Date: Sat, 25 Mar 2006 17:06:55 +0100 From: Roland Schwarz <roland.schwarz@chello.at> Subject: Re: [boost] c2_functions first submission materials uploaded To: boost@lists.boost.org Message-ID: <44256A9F.1010700@chello.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed

...

1. Generic data types instead of hard-coded 'double' Hmm, generic? int's won't make any sense would they?

Neal Becker wrote: perhaps double or float but what else?

long doubles, I assume is the interest.

...

3. Does support of complex make any sense here? I would rather like to see multivalued functions. But complex of course could also turn out to be handy at times.

Sometime! Since this is unfunded work for the moment, it will have to grow slowly. Given the level of interest expressed on this list, I may seek NSF funding (or some such) to give me some time to proceed with this effort.

Roland

------------------------------

Message: 19 Date: Sat, 25 Mar 2006 17:43:20 +0100 From: Roland Schwarz <roland.schwarz@chello.at> Subject: Re: [boost] c2_functions first submission materials uploaded To: boost@lists.boost.org Message-ID: <44257328.9020909@chello.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Roland Schwarz wrote:

...

But complex of course could also turn out to be handy at times. Too fast again (._.) A complex function AFAIK is indefinitely differentiable by definition.

So it obviously belongs to the class of C2 but is there such a thing as complex valued splines?

Right. extending this to complex is a new can of worms, suitable for the future.

Then what about function composition? For the equivalence of complex differentiation rules with real valued ones you need that the complex function is identical to its real valued counterpart when evaluated on a part of the real line (sloppy speaking). So this will force the function class to be C_infinite. Or am I missing something?

Again, right. Lots more complexities as to what these operations mean when moved out of 1-dimensional real functions.

I think c2_functions are not so much interesting because they are carrying their derivatives with them, but because they are a handsome tool to deal with splines in a very readable manner.

The main reason for the rest of the package is, indeed, to provide a lot of very useful operations on splines, although there may be some occasional reasons to use them as freestanding object, especially for root-finding. I also see a future in which I develop a larger special-functions class to go with it. One of the features of most special functions is that it is very inexpensive to generate the derivatives at the same time as the main function. 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. Thus, this the adaptive integrator in this can potentially be used to great effect to compute integrals of special functions multiplied by (for example) interpolating functions for use in wave function, etc.

Having said this, I think c2_functions should not be used for hiding the algorithm developers laziness to modify his/her algorithm to make use of whatever is known about the functions (in case of analytic funtions you know all derivatives!).

Actually, I disagree here. In a lot of cases, for numerical analysis, hiding further information is enough! It provides a lot of efficieny

c2_functions in my opinion is a want-to-have tool to deal with splines numerically, while still focusing on it's appearance as a function.

Other directions deviate from numerical use and extend to symbolic systems. This would also be desirable to have, but I think it should go to a different library. my feelings exactly.