c2_functions first submission materials uploaded
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. Marcus Mendenhall
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. (I also note that the code is all very C-style and some (mea culpa) are sniffy about this! However this is a matter of form not content and can be fairly easily, if tediously, changed.) Paul -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Marcus Mendenhall | Sent: 24 March 2006 16:37 | To: boost@lists.boost.org | Subject: [boost] c2_functions first submission materials uploaded | | 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 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.
That's interesting, although I have to admit I think of a particular use case at present. 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? 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? 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. 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? 4) The library probably needs some concrete use cases to get people interested :-) 5) Boost has a tuple class, so there's no need to restrict the tuple interface to python only as suggested in the white paper :-) That's all I can think of for now, John.
John Maddock wrote:
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?
Does sinh really belong to the class of c2 functions? sinh has an infinite number of derivatives, and AFAIK is not representable within this class. It might be approximated however. Roland
Roland Schwarz wrote:
Does sinh really belong to the class of c2 functions? sinh has an infinite number of derivatives, and AFAIK is not representable within this class. It might be approximated however.
I was too fast. Should have had a look at the docs first. Shame on me. I was exited by the idea of this library however. In the past I needed to do a lot of calculations with splines (and this triggered me), but at this time only the (yet unmaintained?) ublas was available. I used this to handle the splines at this time. 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. 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 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. ) 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? Did you consider extending the library to multivalued functions too? Regards, Roland
1. Generic data types instead of hard-coded 'double' 2. Generic container types instead of hard-coded 'std::vector' 3. Does support of complex make any sense here?
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?
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.
Roland
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? 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? 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. 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!). 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. Just what I think... Roland
Roland Schwarz wrote:
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?
I was thinking of any float-like type, but that's an interesting question. I'm afraid I don't have enough expertise to answer it - do any of these algorithms make sense for other numeric fields, (e.g., finite fields)?
Neal Becker wrote:
Roland Schwarz wrote:
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?
I was thinking of any float-like type, but that's an interesting question. I'm afraid I don't have enough expertise to answer it - do any of these algorithms make sense for other numeric fields, (e.g., finite fields)?
Rational numbers? -Jason
participants (6)
-
Jason Hise -
John Maddock -
Marcus Mendenhall -
Neal Becker -
Paul A Bristow -
Roland Schwarz