Replies: 2 comments 1 reply
-
|
Interesting idea. I'll need some time to read through the linked resources to get a better picture, but my immediate thought is this would work well with https://github.com/Project-Platypus/Rhodium, which is very similar to EMAWorkbench. It already has a way to translate from the given model inputs (Levers, Constraints, Responses, etc.) to Platypus's decision variables. @RhodiumModel()
@Responses(Minimize("max_P"), Maximize("utility"), Maximize("inertia"), Maximize("reliability"))
@Constraints("reliability >= 0.95")
def lake_problem(
pollution_limit = Real(0.0, 0.1, length=100),
b = Uniform(0.1, 0.45, default_value=0.42), # decay rate for P in lake (0.42 = irreversible)
q = Uniform(2.0, 4.5, default_value=2.0), # recycling exponent
mean = 0.02, # mean of natural inflows
stdev = 0.001, # standard deviation of natural inflows
alpha = 0.4, # utility from pollution
delta = 0.98, # future utility discount rate
nsamples = 100): # monte carlo sampling of natural inflows)
...In this example, it can inspect the arguments to see One potential downside to a generalized representation is the level of support for the different types. For example, the parameters Platypus can accept would need associated mutation/variation operators, otherwise it would raise an exception. Additionally, each consumer might only use a subset of the supplied information, and it might not be immediately obvious what it is using. For instance, Platypus might not respect the distribution of a parameter since that's instead controlled by the selected mutation/crossover operator(s). Though I think this can be addressed through documentation. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for getting back! Glad to see there’s interest for solving this problem on a broader level.
Agreed, we've been having a little discussion already here.
I think the first part is as intended, as not all sampler/consumer need the same information, but the second part might indeed be a challenge to address. It might be enough to cover it in good documentation, or it might need a bit more rigorous solution. Open to ideas! If you're interested in participating, let's centralize the discussion to Scientific Python, so we can get all ideas in one place: Feel free to make a little introduction with your thoughts on the problem from the perspective of your library! |
Beta Was this translation helpful? Give feedback.
-
|
👍 Going to close this discussion in favor of using https://discuss.scientific-python.org/t/standardized-system-for-parameter-management-across-scientific-python-libraries/1422 |
Beta Was this translation helpful? Give feedback.
-
Over at Mesa we’re working on a system for managing model/agent default values and ranges, and I believe this could be beneficial beyond Mesa. We’re exploring how to create a standardized way to define parameter spaces, including default values, ranges, and distributions, to be used by any internal and potentially external components.
The idea is to develop a
ParameterSpecstructure that can be used for continuous, discrete, ordered, and categorical data, with flexibility for specifying distributions, sampling strategies, and default values. Then each software component (samplers, visualisation, batch runners) can extract the pieces of information it needs. By defining everything in one place, it makes it easier to integrate different components and much less error prone.Since we also did something similar in the EMAworkbench (see parameters), we where thinking such a spec might be beneficial for more simulation and other scientific libraries. It might have potential for a SPEC.
We’ve started discussions here, and we’d love to hear your thoughts and see if there’s potential for a broader collaboration. If there’s much interest, we can start a centralized discussion with the Scientific Python community.
Beta Was this translation helpful? Give feedback.
All reactions