Retain default values for keyword arguments when manually choosing param_names

[schtandard]

Description

I assume that the current behavior is intended, so I consider this a feature request.

By default, all model function arguments are turned into model parameters unless they are an independent variable or they have a non-numeric default value. Those arguments with a default value get turned into parameters with that as their initial value. However, when explicitly choosing the parameters using param_names, this stops being true and one has to set all initial values manually which feels redundant.

It would be really nice if the initial values were derived from the default argument values even when using param_names.

A Minimal, Complete, and Verifiable example

import lmfit

def foo(x, a=3, b=5, s=1):
    return a + s * b * x**2

print("\nDefault behavior:")
mdl = lmfit.Model(foo)
params = mdl.make_params()
for pname, par in params.items():
    print(pname, par)

print("\nExplicitly choosing parameter names:")
mdl = lmfit.Model(foo, param_names=['a', 'b'])
params = mdl.make_params()
for pname, par in params.items():
    print(pname, par)

print("\nWe have to explicitly set the initial values:")
mdl = lmfit.Model(foo, param_names=['a', 'b'])
mdl.set_param_hint('a', value=3)
mdl.set_param_hint('b', value=5)
params = mdl.make_params()
for pname, par in params.items():
    print(pname, par)

print("\nIn this particular case, we could cheat by using True instead of 1, but that's very hacky:")
def foo(x, a=3, b=5, s=True):
    return a + s * b * x**2
mdl = lmfit.Model(foo)
params = mdl.make_params()
for pname, par in params.items():
    print(pname, par)

Output:

Default behavior:
a <Parameter 'a', value=3, bounds=[-inf:inf]>
b <Parameter 'b', value=5, bounds=[-inf:inf]>
s <Parameter 's', value=1, bounds=[-inf:inf]>

Explicitly choosing parameter names:
a <Parameter 'a', value=-inf, bounds=[-inf:inf]>
b <Parameter 'b', value=-inf, bounds=[-inf:inf]>

We have to explicitly set the initial values:
a <Parameter 'a', value=3, bounds=[-inf:inf]>
b <Parameter 'b', value=5, bounds=[-inf:inf]>

In this particular case, we could cheat by using True instead of 1, but that's very hacky:
a <Parameter 'a', value=3, bounds=[-inf:inf]>
b <Parameter 'b', value=5, bounds=[-inf:inf]>

Version information

Python: 3.9.18 | packaged by conda-forge | (main, Aug 30 2023, 03:40:31) [MSC v.1929 64 bit (AMD64)]

lmfit: 1.2.2, scipy: 1.11.3, numpy: 1.26.0,asteval: 0.9.31, uncertainties: 3.1.7

[newville]

@schtandard I would say that this is intended behavior.

Yes, when explicitly stating the names of the parameters with Mode(..., param_names=[..]) any default values will be lost. It seems to me that one explicitly state the names of the Parameters because arguments that would not be recognized as Parameters should, in fact, be Parameters. In that case, the initial values are probably not numeric, so would be useless as initial values. That is, explicitly using param_names seems like you want to not use the values in the function signature.

It is not clear to me why you need to explicitly name the Parameters. Perhaps you meant to set the names of the independent variables (non-Parameters) instead, as with:

>>> mx = lmfit.Model(foo, independent_vars=['x', 's'])
>>> params = mx.make_params()
>>> for pname, par in params.items():
...     print(pname, par)
...
a <Parameter 'a', value=3, bounds=[-inf:inf]>
b <Parameter 'b', value=5, bounds=[-inf:inf]>

as described at https://lmfit.github.io/lmfit-py/model.html#explicitly-specifying-independent-vars

Also, just to be clear: if you raise an Issue and erase all of the starting Template again, including the part that says

### DO NOT IGNORE ###

READ THESE INSTRUCTIONS FULLY. IF YOU DO NOT, YOUR ISSUE WILL BE CLOSED.

we will certainly will close the issue and not engage with you further.

[schtandard]

It seems to me that one explicitly state the names of the Parameters because arguments that would not be recognized as Parameters should, in fact, be Parameters.

Ah, I see. I guess my use case of wanting to exclude an argument from the parameters is less common. But even in that case, wouldn't it still be useful to automatically recognize the initial values for the parameters where the default arguments are numerical? If I have a signature of foo(x, a=3, b=5, c=42, d=0, e=None) and want to include e in my parameters, having to repeat the initial values of a through d seems unnecessary; adding one more parameter requires re-configuring the other four.

[schtandard]

Perhaps you meant to set the names of the independent variables (non-Parameters) instead

No, I do not want to use s as an independent variable (though that is indeed the workaround I am currently using in order to avoid the warning) because I do not want to set that variable most of the time. My model has a very common use-case where that argument should retain its default value (s=1 in the example) and a much less common special case where providing that value becomes necessary. If I set it as an independent variable, one will have to explicitly set s=1 in the common case.

[newville]

@schtandard Well if your model sometimes wants to vary s and sometimes keep it fixed to 1, then a default value of True is very close to "deliberately confusing". You could certainly do

>>> mod = lmfit.Model(foo)
>>> params = mx.make_params()
>>> params['s'].vary = False  

or

>>> mod = lmfit.Model(foo)
>>> params = mx.make_params(s={'value': 1, 'vary': False})

You know, explicit and not ugly. ;)

If I have a signature of foo(x, a=3, b=5, c=42, d=0, e=None) and want to include e in my parameters, having to repeat the initial values of a through d seems unnecessary; adding one more parameter requires re-configuring the other four.

.... or changing the signature to have a sensible numerical value for e.

[schtandard]

@schtandard Well if your model sometimes wants to vary s and sometimes keep it fixed to 1,

Well, I never want to vary it. I only want to set it to a different value sometimes.

then a default value of True is very close to "deliberately confusing".

Exactly my point: The only way to achieve the effect I desire for s without having to redundantly set the initial values for all other parameters is "deliberately confusing".

>>> mod = lmfit.Model(foo)
>>> params = mx.make_params(s={'value': 1, 'vary': False})

You know, explicit and not ugly. ;)

Well, yes, that's what I would like to do, however I need to set s to non-scalars, as illustrated in the example in #920. Parameters are expected to be scalar and setting one to, e.g., a numpy array leads to an error even if the parameter is not varied. That is the whole reason why I need to exclude it from being a fit parameter, even though its default value is scalar.

If I have a signature of foo(x, a=3, b=5, c=42, d=0, e=None) and want to include e in my parameters, having to repeat the initial values of a through d seems unnecessary; adding one more parameter requires re-configuring the other four.

.... or changing the signature to have a sensible numerical value for e.

This seems like an argument against providing param_names at all (which I do not support, to be clear). As I understood your previous comment, the whole point is that sometimes the function signature does not tell the whole story: Sometimes one wants to use arguments with non-numerical default values as parameters or, as in my case, exclude ones with such default values. And param_names provides a way of telling lmfit which is which, as the alternative may be impractical for other reasons (in the former case) or be "deliberately confusing" (in the latter case).

My argument is that this should not affect the arguments for which the default heuristic "arguments with numerical default values are parameters" is correct, i.e. where it agrees with param_names. It is the default heuristic because it is correct for most arguments, after all.

[schtandard]

Is the ruling that this is intended behavior and a change is not desired? Or is it merely not a priority but a PR would be accepted? It seems like an easy change (and fully backwards compatible) so I would give it a shot, but only if the effort is not doomed from the start.

[newville]

@schtandard I think it is highly unusual to explicitly set param_names, especially for a function with a signature that includes default values. I would not say that we would reject such a change, but I do not think we've seen a case where the current behavior is causing problems.

I sort of think it is more likely that you got to a point where you thought you needed to set param_names when really what you wanted was to set independent_vars.