[Top][All Lists]
[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