help-gsl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gsl] Implementing float gsl_multifit_nlin


From: eknecronzontas
Subject: Re: [Help-gsl] Implementing float gsl_multifit_nlin
Date: Fri, 10 Aug 2007 07:27:23 -0700 (PDT)

Hello,

    Short answer: I have looked into class implementations a little bit, but my 
interest was not so much in double -> float as in allowing the GSL routines to 
operate on member functions and more generic vector types. 
    The longer answer is that I do have a generic version of gsl_vector which 
is templated in a way which you might like (though the template structure is a 
bit contorted in order to create maximum compatibility with GSL), but my class 
versions of the fitting routines have template types for the functions but not 
for the basic numeric data type. (See 
http://tharkad.pa.msu.edu/~asteiner/hal/html/index.html ) It would be quite a 
bit of work to templatize the basic numeric data type. In regards to the 
functions you asked about, start with multiroots/dogleg.c. You'll notice that 
many of these kind of functions are included using include statements like 
"#include "dogleg.c"" and are defined statically.
   Now that I look at the code also, my version of the fitting routine 
(hal::gsl_fit) isn't so advanced yet. My preference is to do what I did, for 
example, in hal::gsl_mroot_hybrids, but that's more work.

Take care,
Andrew

----- Original Message ----
From: Gordan Bobic <address@hidden>
To: address@hidden
Sent: Thursday, August 9, 2007 4:15:47 PM
Subject: [Help-gsl] Implementing float gsl_multifit_nlin

Hi,

I sort of bit this off in the hope that it's not more than I can chew, 
but it looks like the support for the majority of the required 
components for non-linear fitting are only implemented for gsl_vector 
and gsl_matrix types, rather than gsl_vector_float and gsl_matrix_float.

Is this really the case, or am I missing something?
I'm about a thousand lines into the patch, and more and more stuff keeps 
coming up. :-(

Where are:
compute_diag()
compute_gradient_direction()
compute_trial_step()
compute_rptdx()
scaled_enorm()
enorm()

defined?

I don't suppose anyone else would be interested in this, BTW (or if the 
maintainers are reading this, if they'd be interested in a patch)? My 
motivation us purely speed, as discussed earlier re: float vs. double 
performance. If there isn't much interest, I probably won't bother 
finishing this, as it seems to be heading in the epic direction.

If I do continue with it, then there's possibly APIs to discuss, e.g. 
overloading vs. new functions. At the moment I did everything with new 
functions with _float in the name, but maybe it would be better to 
overload the relevant functions instead.

Finally, has anybody thought about wrapping any of GSL in some classes 
for more sensible organization? Far fetched, I know, but it would likely 
make adding handling of another type considerably easier...

Thanks.

Gordan


_______________________________________________
Help-gsl mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/help-gsl







reply via email to

[Prev in Thread] Current Thread [Next in Thread]