Draft: Simplify Parameter init for FreeVariables

[maxdinkel]

Description and Context:
What and Why?

If someone wants to use queens for deterministic analyses, the setup of Parameters with FreeVariables is a bit cumbersome. This PR aims to simplify this process by allowing *args for Parameters that are used for 1d parameters without underlying distributions.

For example:

from queens.distributions.free_variable import FreeVariable
x1 = FreeVariable(dimension=1)
x2 = FreeVariable(dimension=1)
parameters = Parameters(x1=x1, x2=x2)

can be simplified to

parameters = Parameters('x1', 'x2')

This is just a suggestion that might ignite ideas for a better solution 🙂

Related Issues and Pull Requests

• Closes
• Related to

Interested Parties

Note: More information on the merge request procedure in QUEENS can be found in the Submit a pull request section in the CONTRIBUTING.md file.

[rjoussen]

I like this feature, I found it quite unintuitive before when having to use free variables explicitly.

[leahaeusel]

I like this feature, too 👍 Just two minor comments from my side:

[gilrrei]

Nice catch. I think the error message should be more precise, specifying that it was specified once by pure name and once using a distribution.

Additionally, we need to check if the user provides the same name twice, e.g., Parameters("x1","x1") as this might happen now.

[gilrrei]

Should we add some logging information that we are assuming the parameter to be 1d?

[gilrrei]

Suggested change

	*parameters_without_distribution (str): Names of one-dimensional parameters without
	assumption about underlying distribution.
	*parameters_without_distribution (str): Names of one-dimensional parameters without
	assumption about the underlying distribution.

[sbrandstaeter]

I hate to spoil the party, but I’m not sure I like the direction of this change. I agree that useability of the parameters object can be improved, but I had always envisioned this going a different route. What worries me is that introducing a special interface adds a fair bit of complexity — we now have another “if” in the conceptual tree of how to use the parameter object. Users need to know which interface to use depending on whether it’s a deterministic or random variable, which makes things less uniform. I’ve always appreciated that it’s just “the same thing” for both. I fear that this might make life easier for expert users, but harder for new ones.

Additionally, I had imagined extending the functionality of free variables — for example, defining bounds for deterministic variables used in the optimization or gird iterator — so that all related properties live in one place: the parameters object. The proposed interface feels too specific to one-dimensional real-valued parameters and doesn’t strike a good balance between added complexity and added value, in my opinion.

[gilrrei]

I agree that useability of the parameters object can be improved, but I had always envisioned this going a different route. What worries me is that introducing a special interface adds a fair bit of complexity — we now have another “if” in the conceptual tree of how to use the parameter object. Users need to know which interface to use depending on whether it’s a deterministic or random variable, which makes things less uniform. I’ve always appreciated that it’s just “the same thing” for both.

I agree, the parameters do way too much. Yet, I still think such a functionality is an acceptable interim solution. Completely changing the parameters interface will be a lot of work, and tbh it's not easy, I've looked into it in the past :(

I fear that this might make life easier for expert users, but harder for new ones.

I don't think that this is as easy as you think. It depends on what is meant by new ones. People who only care about the model infrastructure will find this change beneficial, but for those who are interested in distributions, it may cause confusion. I think we, experts accustomed to the strangeness of QUEENS, should seek the opinion of newish users, and not try to speak for them.

Additionally, I had imagined extending the functionality of free variables — for example, defining bounds for deterministic variables used in the optimization or gird iterator — so that all related properties live in one place: the parameters object.

We had this in the past, which I personally found as a mix between nice and annoying, mainly due to its implementation, which could definitely be improved :)

The proposed interface feels too specific to one-dimensional real-valued parameters and doesn’t strike a good balance between added complexity and added value, in my opinion.

My guesstimate would be that the strong majority of QUEENS users only use one-dimensional parameters. I don't have evidence to support that, just a feeling. Some I spoke to didn't even realise that one could do multivariate ones. I just want to highlight that it is an important case (not the only one for sure)

I think the willingness to improve the parameter setup is nice. Recently, I have studied factory functions, which I think are quite beneficial for usability and easy to test. Examples of these are np.ones, np.array, etc, which are functions to construct objects instead of using the init of np.ndarray (which numpy advises against!). They are a convenient way to initialize objects for special cases. I think we could also make use of this here. The only downside is that you must be aware of their existence, which can only be achieved through documentation and/or effective placement.