Re: [boost] c2_functions suggestions commentary

From: Marcus Mendenhall (marcus.h.mendenhall_at_[hidden])
Date: 2006-03-25 12:30:09

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_at_[hidden]>
> Subject: Re: [boost] c2_functions first submission materials uploaded
> To: <boost_at_[hidden]>
> Message-ID: <E1FN5C4-0003Dl-3s_at_[hidden]>
> 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_at_[hidden]>
> Subject: Re: [boost] c2_functions first submission materials uploaded
> To: <boost_at_[hidden]>
> Message-ID: <056001c65014$215da0f0$4ee70c52_at_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_at_[hidden]>
> Subject: Re: [boost] c2_functions first submission materials uploaded
> To: boost_at_[hidden]
> Message-ID: <e03nv2$j99$1_at_[hidden]>
> 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_at_[hidden]>
> Subject: Re: [boost] c2_functions first submission materials uploaded
> To: boost_at_[hidden]
> Message-ID: <442565E7.8000006_at_[hidden]>
> 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_at_[hidden]>
> Subject: Re: [boost] c2_functions first submission materials uploaded
> To: boost_at_[hidden]
> Message-ID: <44256A9F.1010700_at_[hidden]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Neal Becker wrote:
>> 1. Generic data types instead of hard-coded 'double'
> Hmm, generic? int's won't make any sense would they?
> 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_at_[hidden]>
> Subject: Re: [boost] c2_functions first submission materials uploaded
> To: boost_at_[hidden]
> Message-ID: <44257328.9020909_at_[hidden]>
> 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.