| Bug in CURVEFIT [message #9316] |
Tue, 24 June 1997 00:00 |
Wayne Landsman
Messages: 117
Registered: January 1997
|
Senior Member |
|
|
CURVEFIT currently (IDL V5.0 and V4.0.1) contains a line of code which
was not in the original BEVINGTON, but which was added as an
"improvement"
; If a good fit, no need to iterate
all_done = chisq1 lt total(abs(y))/1e7/NFREE
I'm not sure why this code was added (speed?), but it can cause a
serious problem when equal weighting is used (W = 1) for data with
large negative exponents (e.g. 1e-9). For such data, CURVEFIT will
mistakenly think that it does not need to iterate, and will return to
the user with what it thinks is a good fit. (There is a secondary
problem in that the returned parameters will not be the ones actually
used to compute the output YFIT.)
The problem was originally discovered with GAUSSFIT() which calls
CURVEFIT() using equal weighting. I have sample data in an IDL XDR save
set to illustrate the GAUSSFIT() problem, available at
ftp://idlastro.gsfc.nasa.gov/landsman/curvefit/
I was told that in V5.0, the use of CURVEFIT() was disparaged in favor
of LMFIT() which is the "Numerical Recipes" version of the
Levenberg-Marquadt algorithm. (I posted a complaint a while back
about how LMFIT() requires a user-supplied function in a different and
less flexible format than CURVEFIT(). ) But GAUSSFIT() still calls
CURVEFIT() and not LMFIT().
--Wayne Landsman landsman@mpb.gsfc.nasa.gov
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
