Re: [Help-gsl] GSL, C++, and function pointers

[eknecronzontas]

Hello!

     If you use the function wrapper, you can write a
second function wrapper to call the GSL derivative
routine again to generate the second derivative. I use
this from time to time with moderate success (but I'd
love to hear if someone has a better approach for
higher derivatives...I don't think CERNLIB has a
function to do this either). This is analogous to what
I do in my code (which, for posterity, I'll point out
that I have compiled and tested it on Cygwin, MacOSX,
and Linux)
     Paulo's approach is probably generally fine.
However, I'd strongly discourage naming a local
variable "this", for obvious reasons.

Good luck,
Andrew 


--- Jordi Gutierrez Hermoso <address@hidden> wrote:

> On 05/03/07, eknecronzontas
> <address@hidden> wrote:
> > [T]he easiest solution is to write a global (or
> static member)
> > function wrapper with the same form as GSL expects
> and then calling
> > your function instead.
> 
> I think this is what I'll do.
> 
> >      My solution to this problem is usually to
> rewrite
> > the GSL routines as templates so they call
> > type::operator() instead of using a function
> pointer.
> 
> [snip]
> 
> > I should note the GSL derivative function is quite
> > simple and probably not to difficult to
> rewrite...in
> > case you decide you want to do that instead.
> 
> I would prefer to not do this, as I am hoping that
> my code will be
> "portable" or as portable as the GSL itself. There
> are a number of
> machines on which this will compile, and I don't
> have root access to
> all of them. They already have the GSL installed on
> them, and I'd
> rather not modify the GSL itself.
> 
> I would send patches instead ;-) but it seems that
> operator() is a
> strictly C++ construct.
> 
> Thank you for your thoughts.
> 
> As for Sr. Jabardo's thoughts....
> 
> On 05/03/07, Paulo Jabardo <address@hidden>
> wrote:
> > If I understand you correctly, you need to write a
> > wrapper class.
> 
> Yes, I think this is what I'll do. But doesn't the
> STL already have
> wrapper classes precisely for situations like this?
> I don't really
> understand how to use the STL classes defined in
> <functional>, so I'm
> not sure if they really solve my problem or not.
> 
> > a function pointer to a function that accepts a
> double
> > and a void* and returns a double and a second
> field
> > that is a void*.
> 
> Void pointers scare me. They're too much like
> unprotected C. :-)
> 
> > The params field is a pointer to user data. It can
> be
> > anything you want so you can define a
> structure/class
> > that contains every information necessary. Then
> you
> > write a global function (as defined by GSL) that
> knows
> > how to use this structure/class you defined.
> 
> I don't understand how this is supposed to work, so
> I'll avoid it. My
> wrapper class will take care of the param fields by
> having them as
> data members.
> 
> One final question for the floor. Why doesn't the
> GSL have
> higher-order differentiation routines? Am I supposed
> to repeatedly
> call the first order derivative in some way, or
> what? That seems a
> little odd; almost "all" of the interesting
> differentiation occurs at
> least with second derivatives. How am I supposed to
> procure those with
> the GSL?
> 
> Thanks again,
> - Jordi G. H.
> 
> 
> _______________________________________________
> Help-gsl mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-gsl
>