Feature Suggestion: Parameters.eval() method

[Nicholas Zobrist]

Hello,

I recently was writing some code where I needed to evaluate an expression containing the user defined symbols in a model Parameters object. In my case, the user symbols were no longer easily accessible in the current scope. This could be chalked up to a workflow issue, but is understandable since model results are often used long after their creation.

My solution was to use params._asteval.eval(expression), but this involves using a protected member of the Parameters class. Since the asteval keyword in Parameters has been deprecated, it seems reasonable to worry that this method may break in the future.

Exposing eval as a direct method of Parameters might make it more flexible as a stand-alone object.

Best,

Nicholas

[Matt Newville]

Hi Nicholas,

I would not be opposed to adding such a method.  Just to be clear, this would not be necessary to fetch the parameter values . - those are kept up-to-date, so one can just get the value or something like `Parameters.valuesdict()`.  But you are (I think) asking about evaluating a different quantity.  If you're willing and able, a pull request would be great. 

Possibly related to this, there was a recent question on stackoverflow about lmfit speed for some models -- notably VoigtModel.  It turns out that evaluating the `height` constraint for that model is kind of slow.    Having a `Parameters.eval()` might allow some of the constraint expressions such as `fwhm` and `height` to be flagged to *not* be updated for each function evaluation, but still be easy to evaluate on demand, after the fit.     That might be an acceptable compromise between features and efficiency.

 

--Matt Newville 

[Nicholas Zobrist]

I would be happy to contribute and will work on it shortly. I think we are on the same page. This new method seems most appropriate for evaluating useful expressions involving the parameters and user-defined functions that do not need to be computed at every fit iteration. 

As for your second point, I'm not sure that I have enough familiarity with the code to address flagging constraint expressions to be evaluated later, but I agree that this ability would be useful. I have also encountered speed issues in custom models with unwieldy constraint expressions. The solution for me was to not include them when they cause problems, but it would be nice if they were still there.

-N