Re: set_par_fun behavior for derived parameter outside range

On Fri, Apr 13, 2012 at 11:36 -0400, David P. Huenemoerder wrote:
>
>     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> () = 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

Do you want to ignore the hard limits as well, or just the
soft limits?

What happens when you remove the par_fun, leaving the
parameter's value outside the specified soft limits?

I don't see how isis can automatically fix such an
inconsistency, so the user would have to specify new parameter
ranges before doing anything more with that parameter
configuration.

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

I suspect that such a re-set of limits will always be necessary
and will always require user input. If the derived parameter
moved outside the original min/max limits, isis has no way of
knowing what reasonable new limits ought to be. If the derived
parameter stayed inside the original min/max limits, then the
current implementation is fine.

> They make for extra steps (and might lead me to "define
> my_set_par_fun() { ...}").
>

What would my_set_par_fun do?  It could automatically do:
   set_par (s; min=0, max=0);
but I don't think that should be the default behavior of
set_par_fun.  

Since the previous parameter limits can't always be restored
(e.g. if the parameter value now lies outside that range) I'm
not sure what good it would to to have a my_set_par_fun attempt
to preserve them.

For what it's worth, set_par_fun is actually a redundant
command.  You can actually use set_par to define the function
and set new parameter limits simulteously.
For example:
  set_par ("gauss(1).center", "gauss(2).center + 1.23"; min=8, max=15);
Since set_par can do this, it can equally well do
  set_par ("gauss(1).center", "gauss(2).center + 1.23"; min=0,  max=0);

I'm open to making the sort of change that you're suggesting,
but I don't yet see how to make it reliable as a general
feature.

Maybe a problem-specific implementation of my_set_par_fun is
the best solution(?).

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