Assigning a prefix to a model after it is declared changes the values of its parameters

[jrr-us]

Hi all,

I have encountered some surprising behavior (might be a bug or a feature) when assigning a prefix to a model after it is declared. If I run:

A = PseudoVoigtModel(prefix='A_')
A.make_params()
A.set_param_hint('fraction', value=1)
for par in A.make_params().values():
    print(par)

The result is:

<Parameter 'A_amplitude', value=1.0, bounds=[-inf:inf]>
<Parameter 'A_center', value=0.0, bounds=[-inf:inf]>
<Parameter 'A_sigma', value=1.0, bounds=[0:inf]>
<Parameter 'A_fraction', value=1, bounds=[0.0:1.0]>
<Parameter 'A_fwhm', value=2.0, bounds=[-inf:inf], expr='2.0000000*A_sigma'>
<Parameter 'A_height', value=0.3183098861837907, bounds=[-inf:inf], expr='(((1-A_fraction)*A_amplitude)/max(1e-15, (A_sigma*sqrt(pi/log(2))))+(A_fraction*A_amplitude)/max(1e-15, (pi*A_sigma)))'>

However, if I assign the prefix at a later time:

A = PseudoVoigtModel()
A.make_params()
A.set_param_hint('fraction', value=1)
A.prefix = 'A_'
for par in A.make_params().values():
    print(par)

I get a different result:

<Parameter 'A_amplitude', value=-inf, bounds=[-inf:inf]>
<Parameter 'A_center', value=-inf, bounds=[-inf:inf]>
<Parameter 'A_sigma', value=-inf, bounds=[0:inf]>
<Parameter 'A_fraction', value=0.5, bounds=[0.0:1.0]>
<Parameter 'A_fwhm', value=-inf, bounds=[-inf:inf], expr='2.0000000*A_sigma'>
<Parameter 'A_height', value=-inf, bounds=[-inf:inf], expr='(((1-A_fraction)*A_amplitude)/max(1e-15, (A_sigma*sqrt(pi/log(2))))+(A_fraction*A_amplitude)/max(1e-15, (pi*A_sigma)))'>

Is this the expected behavior?

Cheers,
Joaquin.

[newville]

@jrr-us Hm, I am sort of OK with inconsistent or even non-sensical behavior when one does not provide initial values for parameters. There are no situations where that should be expected to work. If given that choice, I would suggest the better fix is to adopt the second set of values.

[jrr-us]

@newville Thank you for your reply. I see your point, however there are situations where default initial values might be fine. For example an initial amplitude of 1.0 would be a good starting value when fitting a peak that has been previously normalized to have unit area. Also, you can see in the second part of my example that fraction was changed to 0.5 even though it was previously given an initial value of 1.

A = PseudoVoigtModel()
A.make_params()
A.set_param_hint('amplitude', value=5.0)
A.set_param_hint('center', value=-1.0)
A.set_param_hint('sigma', value=0.1)
A.set_param_hint('fraction', value=1.0)
A.prefix = 'A_'
for par in A.make_params().values():
    print(par)

Gives:

<Parameter 'A_amplitude', value=5.0, bounds=[-inf:inf]>
<Parameter 'A_center', value=-1.0, bounds=[-inf:inf]>
<Parameter 'A_sigma', value=0.1, bounds=[0:inf]>
<Parameter 'A_fraction', value=0.5, bounds=[0.0:1.0]>
<Parameter 'A_fwhm', value=0.2, bounds=[-inf:inf], expr='2.0000000*A_sigma'>
<Parameter 'A_height', value=19.700713138340408, bounds=[-inf:inf], expr='(((1-A_fraction)*A_amplitude)/max(1e-15, (A_sigma*sqrt(pi/log(2))))+(A_fraction*A_amplitude)/max(1e-15, (pi*A_sigma)))'>

[reneeotten]

@jrr-us I don't think the way you use set_param_hint is really what you're supposed to do. That is, the set_param_hint belongs to the model and is intended to set, for example, parameter bounds for a certain model to make sure that it physically makes sense (e.g., the linewidth should be positive) and they will be used when doing make_params(). Since you're using one of the built-in models where we already set-up the parameter_hints correctly (i.e., for PseudoVoigModel we set hints for sigma and gama) so there is no reason to call this method again yourself.

It is not intended to set initial parameters and in my opinion you shouldn't use it like that. If you want to set initial parameters, you can do that when making the parameters, for example by doing params = A.make_params(amplitude=5, center=-1, sigma=0.1, fraction=1.0).

Having said that, it's not very obvious to me where the difference is coming from in the example you're showing, but since I don't think we actually support your use of set_param_hints I am not sure anyone will spend time on trying to track this down.

[jrr-us]

Actually, I was using set_param_hit to set bounds on parameters for the built-in models. I guess I misunderstood its purpose. Thank you @reneeotten and @newville for the clarification!

[reneeotten]

@jrr-us see, for example, here how to "guess" initial parameters from your experimental data and ways to fine-tune bounds and/or initial values after you've created the Parameters class.

[newville]

@jrr-us

..., however there are situations where default initial values might be fine. For example an initial amplitude of 1.0 would be a good starting value when fitting a peak that has been previously normalized to have unit area.

If a user expects that unit normalization is indeed reasonable for their data, then they should be able to state that explicitly. The fitting algorithms (yes, the algorithms, not our code or the implementation of the algorithms we are using) require initial values for all variable parameters. There really are no exceptions.

Also, you can see in the second part of my example that fraction was changed to 0.5 even though it was previously given an initial value of 1.

Again, in the absence of initial values provided by the user, I don't really see any values selected by default as wrong or better, except insofar as -Inf (or Nan) is sort of better because it clearly signals an unreasonable starting value that will fail early.

[jrr-us]

@newville To be clear, I was providing initial values for all parameters and I noticed that, at least in the PseudoVoigtModel for the fraction parameter, the value was changing after giving it a prefix. For that I was using set_param_hint, and it is clear to me now that this is not its intended use. Thank you all for your insight.

[newville]

@jrr-us so was the question "why do the values change" after setting a prefix or "why was the parameter hint ignored"? That not respecting the parameter hint does seem odd to me, but I completely did not get that from your initial report. If it isn't obvious, it's always good to ask the question that you actually want to be answered ;).

[jrr-us]

@newville Actually both, although I should have pointed out that the hint for fraction was not being respected, in addition to the default values being overriden after setting the prefix.