Re: voigt error... followup

From: <rgibson_at_email.domain.hidden>
Date: Fri, 16 Nov 2007 15:09:13 -0500
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 
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, 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

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.  Setting a negative redshift or absorbing
column doesn't seem to generate exceptions from zphabs... maybe I'm not 
it right, though.


Quoting John Houck <houck_at_email.domain.hidden
> On Fri, Nov 16, 2007 at 13:50 -0500, rgibson_at_email.domain.hidden>> I think I found the problem.  The voigt.vtherm parameter goes
>> negative during the fits (because I allowed for a minimum value
>> < 0 in set_par).  I think it wasn't obvious because fit_counts
>> would crash before updating the vtherm parameter when it went
>> negative.
> In this case, "crash" is the wrong word isn't it?
> For example, if a car's "check engine" light came on, it
> wouldn't normally be called a "crash".
>> Suggest robustifying voigt.vtherm and voigt.fwhm to not halt
>> ISIS if evaluated when negative?
>> Thanks,
>> Rob
> I don't think this would be an improvement.
> When an attempt is made to evaluate a function outside its
> valid domain, I think the function should generate a fairly
> severe error.
> For example, when computing a real-valued expression involving
> sqrt(x), I think a severe error (an "exception") should be
> generated when x<0. The exception serves as a warning that
> something has gone very wrong.
> For what it's worth, you can use slang's try/catch/finally
> construct to handle exceptions of this nature.  For example,
> see:
> 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:
Received on Fri Nov 16 2007 - 15:09:22 EST

This archive was generated by hypermail 2.3.0 : Fri May 02 2014 - 08:35:45 EDT