gnuplot-beta

Prescaling fit parameters

[Carl M. <mi...@ph...>]

Hello,

I am hoping to drum up a little support to get a small patch accepted.

My issue is with the scaling of fit parameters in gnuplot's 'fit' command.

Fit is pretty robust, but if you have a function like:

f(x) = a * exp(-b*x*x) + c

where the values of the parameters differ by many orders of magnitude (eg a,c = 
1e7 and b = 1e-7) the fit command will fail badly.  One solution is to redefine 
the function so the parameters are of similar size, but it's easy to have 
gnuplot do this internally based on the initial values of the parameters.

I've written a tiny patch to do this:
http://sourceforge.net/tracker/?func=detail&aid=3106206&group_id=2055&atid=302055

I've tested this against test cases such as the one above, and also all of the 
fits in fit.dem.

The patch actually makes most of the fits converge in fewer iterations, and for 
fits where the parameters are very different in size, it now converges where it 
didn't at all before.

The patch is very non-invasive.  It adds 13 lines and modifies 7 others, all in 
fit.c

We use gnuplot in undergraduate teaching labs a lot, and this solves one of the 
most common problems we see with students using it for fitting.

Carl

Prescaling fit parameters

[Carl M. <mi...@ph...>]

Hi,

A couple of years ago (March 2011) I submitted a very small patch against fit.c 
to improve the way gnuplot's fit function works in cases where fit parameters 
vary in size dramatically. The problem is that if you are doing fits where some 
parameters are, say 10^7, but others are 10^-7, the fit routine basically 
collapses.

The patch does a trivial rescaling of the parameters by their initial guess 
values before the meat of the fitting routine is called. With this rescaling 
these cases don't cause any problems.

The patch and a description are here:
http://sourceforge.net/p/gnuplot/patches/507/
and this still applies cleanly to gnuplot 4.6.

After applying this patch, most of the examples in fit.dem actually converge in 
fewer iterations than without it.

Is there any hope of having this tiny patch (it touches a total of 20 lines) 
accepted?

Thanks,

Carl

Re: Prescaling fit parameters

[sfeam (E. Merritt) <eam...@gm...>]

On Friday, 08 March 2013, Carl Michal wrote:
> Hi,
> 
> A couple of years ago (March 2011) I submitted a very small patch against fit.c 
> to improve the way gnuplot's fit function works in cases where fit parameters 
> vary in size dramatically. The problem is that if you are doing fits where some 
> parameters are, say 10^7, but others are 10^-7, the fit routine basically 
> collapses.
> 
> The patch does a trivial rescaling of the parameters by their initial guess 
> values before the meat of the fitting routine is called. With this rescaling 
> these cases don't cause any problems.
> 
> The patch and a description are here:
> http://sourceforge.net/p/gnuplot/patches/507/
> and this still applies cleanly to gnuplot 4.6.
> 
> After applying this patch, most of the examples in fit.dem actually converge in 
> fewer iterations than without it.
> 
> Is there any hope of having this tiny patch (it touches a total of 20 lines) 
> accepted?

The code in the patch does not do what it is described as doing.

1)
The test of this form will never be true:   (foo == NEARLY_ZERO) 
You would have to test  (favs(foo) <= NEARLY_ZERO)

2)
The description/comment says
 "If any variables were 0, then don't do it, since it causes more harm than
  good then."
But the actual code applies scaling to all parameters except ones
with (foo == NEARLY_ZERO), which aside from being the wrong test is
not what is described ("if any ...").

Also, do you have any reason to believe the current definition of 
NEARLY_ZERO as 10^{-30} is the right place to make a cutoff?  

3)
Please make this an option, probably
   set fit [no]prescale

	Ethan


> Thanks,
> 
> Carl