Re: voigt error... followup

On Fri, Nov 16, 2007 at 15:09 -0500, rgibson_at_email.domain.hidden> I think we're getting into programming philosophy here.  In
> that vein, I offer my two cents.
> 
> Re: "crash," my "application-layer" scripts running in ISIS
> would crash because fit_counts() would halt, often after long
> hours of running.  I would at least suggest improving the error
> message to indicate the params are bad, 

I'll provide a more informative error message.

> especially since (is this right?) "list_par" doesn't
> necessarily show the offending params after fit_count() exits.
> (Hence it took a while to determine the underlying problem.)
> 

Right.  If something goes terribly wrong, the minimizer should
restore the parameters to their last known good state, which is
presumably the initial state. This is useful for interactive
work because it keeps you from losing the (presumably sensible)
initial parameter values.

> As to what action the model should take, I guess it's a
> philosophical layering issue.  (And, of course, it's your
> product, not mine.) "voigt" is a couple of layers below my
> scripts, and you want to have a general interface that allows
> "fit_counts" to explore the entire parameter space specified by
> the app.  On the other hand, one might expect the model to
> handle unphysical parameters by simply throwing back a huge
> chi^2.  

Depending on the minimizer, this approach could waste a vast
amount of cpu time.

The minimizer is free to search the parameter space that you
specify.  Some algorithms may choose to begin their search by
examining the function value on the boundary of this region.

In that case, allowing variables like energy and FWHM to take
values in the range [-1e100, 1e100] can lead to trouble.  

Suppose the minimizer tries energy = -1e100 and gets some big
chi^2 value.  What next?  Maybe it tries E=-0.5e100.  Oops, bad
chi^2.  Well, maybe -0.25e100. Hmmm.  Still bad....

You can see how this could lead to quite a lot of waste --
especially if this logic is applied to an N dimensional space
spanning 200 orders of magnitude in scale.

> Setting a negative redshift or absorbing column doesn't seem to
> generate exceptions from zphabs... maybe I'm not testing it
> right, though.

That could very well be true -- it depends entirely on who
implemented that particular model function.  In this case,
zphabs is an xspec function -- I did not write it.  The person
who implemented zphabs may have simply assumed that nobody
would ever provide crazy parameter values.  I haven't looked at
the code, so I cannot say for sure.

In any case, some people code spectral model functions
defensively and some do not.  For this reason, I think it's
safer to restrict the fit parameters to values that are
physically reasonable.

Thanks,
-John
----
You received this message because you are
subscribed to the isis-users list.
To unsubscribe, send a message to
isis-users-request_at_email.domain.hiddenwith the first line of the message as:
unsubscribe