more on c2_function discussion
Message: 2 Date: Sat, 25 Mar 2006 12:02:50 -0500 From: Neal Becker <ndbecker2@gmail.com> Subject: Re: [boost] c2_functions first submission materials uploaded To: boost@lists.boost.org Message-ID: <e03t3p$2ok$1@sea.gmane.org> Content-Type: text/plain; charset=us-ascii
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)?
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?
Actually, if by this one means a complex function of a real argument, the extension is trivial since one can spline the real & imaginary parts separately. Otherwise, it is a bit murky. From: Roland Schwarz <roland.schwarz@chello.at> Subject: Re: [boost] c2_functions suggestions commentary To: boost@lists.boost.org Message-ID: <442589C0.8060006@chello.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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) This is a bang-for-the-buck issue. In real numerical computations,
That's for another package... This one needs to be kept very focused on plain floating types. the manipulations get more complex rapidly for higher derivatives, but the yield gets less. Especially since this is aimed significantly at physical data, two derivatives is about all one has reason to believe in. I think a general C(N) package is really something for theorists to use, but then one can just use Mathematica for that kind of calculation any. Let's not try to rewrite Mathematica with this package. I would rather contribute a package which does a focused task perfectly and compactly, than a big fuzzy package that no one can use because it does too many things halfway.
Message: 6 Date: Sat, 25 Mar 2006 19:29:10 +0100 From: Roland Schwarz <roland.schwarz@chello.at> Subject: Re: [boost] c2_functions suggestions commentary To: boost@lists.boost.org Message-ID: <44258BF6.6000203@chello.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Marcus Mendenhall wrote:
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.
Hmm, whether a spline is interpolating or approximating only has to do with how you calculated its pivot values. I am not sure if I understand you correctly here.
Roland
If you look at the source for splint (which derives, a long ways back from the code in Numerical Recipes, but is heavily modified), you will see the forced continuity at the boundaries, including a way of expanding which (I hope) should result in good roundoff behavior at the boundary. Anyway, the root finder uses a numerical tolerance which should prevent it from having convergence issues due to the last bit anyway.
------------------------------
Message: 10 Date: Sat, 25 Mar 2006 15:03:44 -0500 From: Jason Hise <chaos@ezequal.com> Subject: Re: [boost] c2_functions first submission materials uploaded To: boost@lists.boost.org Message-ID: <4425A220.4070900@ezequal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Rational numbers?
The concept of a continuous function on the rationals is suspect to me. Also, this is focused on numerical computation, not number theory. Everything is a float of some sort, to me!
One tricky area is the need to infer the types of functions, for example, when functions are composed. Various approaches have been used, but the most flexible approaches are those that are not intrusive in the sense of not imposing restrictions on the functions being composed. Fortunately, I think we now can use boost::result_of to help. I noticed that in c2 that compose was lacking gerericity (is that a word?). Here is a demonstration that I think you may find helpful. ,----[ /home/nbecker/Test.cc ] | #include <boost/utility/result_of.hpp> | #include <cmath> | | template<typename T> | struct Sqr { | T operator () (T x) { return x * x; } | }; | | template<typename T> | struct Sin { | T operator () (T x) { return ::sin (x); } | }; | | template<typename F_type, typename G_type> | struct Compose { | F_type f; | G_type g; | | Compose (F_type _f, G_type _g) : f (_f), g (_g) {} | | template<typename arg_t> | typename boost::result_of<G_type (F_type (arg_t))>::type operator() | (arg_t x) { | return g (f (x)); | } | | }; | | int main() { | Compose<Sqr<double>,Sin<double> > C (Sqr<double>(), Sin<double>()); | } `----
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Neal Becker | Sent: 26 March 2006 05:06 | To: boost@lists.boost.org | Subject: Re: [boost] more on c2_function discussion | | I noticed that in c2 that compose was lacking gerericity | (is that a word?). Is is about decay of grey matter as one ages? Or do you have something more generic in mind ;-) 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
Marcus Mendenhall wrote:
Actually, if by this one means a complex function of a real argument, the extension is trivial since one can spline the real & imaginary parts separately.
To my knowledge this is a useless thing. This will not yield an analytic function in general. Real and imaginary parts are are strongly dependent one upon the other. This is what makes them analytic. What really would make sense is to have 2 (or more dimensional) functions. Roland
participants (4)
-
Marcus Mendenhall -
Neal Becker -
Paul A Bristow -
Roland Schwarz