Re: set_par_fun behavior for derived parameter outside range

    John> Why not just enlarge the allowed range for the derived parameter?

I can sympathize with Maurice.  There have been instances where I had
independent parameters, fiddled with limits, did a fit, then decided to
impose a par_fun.  For example, in setting line centers to an offset
from one that is fit in a triplet:

isis> list_par;
gauss(1) + gauss(2) + gauss(3) + poly(1)
 idx  param        tie-to  freeze         value         min         max
  1  gauss(1).area     0     0     2.639159e-05           0        0.01  photons/s/cm^2
  2  gauss(1).center   0     0          9.16875     9.15875     9.17875  A
  3  gauss(1).sigma    0     0           0.0001           0        0.02  A
  4  gauss(2).area     0     0     8.797197e-07           0        0.01  photons/s/cm^2
  5  gauss(2).center   0     1         9.230667    9.228687    9.230687  A
#=>  gauss(1).center + 0.061
  6  gauss(2).sigma    3     0           0.0001           0        0.02  A
  7  gauss(3).area     0     0     8.797197e-06           0        0.01  photons/s/cm^2
  8  gauss(3).center   0     1          9.31475    9.313339    9.315339  A
#=>  gauss(1).center + 0.146
  9  gauss(3).sigma    3     0           0.0001           0        0.02  A
 10  poly(1).a0        0     0      0.002639159           0         0.1  
 11  poly(1).a1        0     1                0           0           0  
 12  poly(1).a2        0     1                0           0           0  

isis> () = fit_counts; 
Failed: computing derived parameter: gauss(1).center + 0.061
Failed: computing derived parameter: gauss(1).center + 0.061
Error: parameter gauss(3).center:  derived value=9.31567 ignored (violates limits min=9.31334 max=9.31534)

So this failed because now the min, max for the par_fun centers are more
restrictive than the feature they are tied to.  I can remedy this by doing:


isis> set_par("gauss(2).center"; min=0,max=0);
isis> set_par("gauss(3).center"; min=0,max=0);
isis> () = fit_counts; 
 Parameters[Variable] = 12[6]
            Data bins = 180
           Chi-square = 292.6529
   Reduced chi-square = 1.681913


But if it's feasible for ISIS, it might be nice if the limits for
par_fun parameters to be ignored altogether (though your answer below
implies not).  Otherwise, whenever I do a set_par_fun(s,...), I have to do the
set_par(s; min=0, max=0).  That's not hard, but then if I
set_par_fun(s,NULL), I might have to re-set my limits.  They make for
extra steps (and might lead me to "define my_set_par_fun() { ...}").

-- Dave

David Huenemoerder  617-253-4283 (o); -253-8084 (f); http://space.mit.edu/home/dph
MIT Kavli Institute for Astrophysics and Space Research
70 Vassar St., NE80-6065,
Cambridge, MA  02139
[Admin. Asst.: Elaine Tirrell, 617-253-7480, egt_at_email.domain.hidden

------------------------------------------------------------------------------------

    John> On Thu, Apr 12, 2012 at 19:11 -0400, Maurice Leutenegger wrote:
    >> Hi all,
    >> 
    >> the behavior of set_par_fun changed in 1.6.1-8,9:
    >> 
    >> 8.  Don't generate an error when a model parameter value,
    >> obtained from a function evaluation, falls outside the
    >> assigned min/max range (see set_par_fun). Instead, the out
    >> of range value will be ignored and a warning message will
    >> be printed if Isis_Verbose>0.
    >> 9.  Revise error handling introduced in #8 to interrupt
    >> model evaluation when derived parameters are out of range.
    >> 
    >> Is there any way to get a more forgiving behavior from set_par_fun?

    John> No.

    >> I would prefer to allow model evaluation even if the derived
    >> parameter falls outside the soft limit.
    >> 

    John> Why not just enlarge the allowed range for the derived parameter?

    John> If necessary, the hard-limit range could be increased as well
    John> (see __set_hard_limits). But if the hard limits represent
    John> fundamental limitations of the model, then violating the
    John> default hard limits may cause the model evaluation to fail.

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







----
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