Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft a new ParameterConfig given assumption that all parameter names are unique #10088

Open
xjules opened this issue Feb 17, 2025 · 0 comments · May be fixed by #10095
Open

Draft a new ParameterConfig given assumption that all parameter names are unique #10088

xjules opened this issue Feb 17, 2025 · 0 comments · May be fixed by #10095
Assignees

Comments

@xjules
Copy link
Contributor

xjules commented Feb 17, 2025

Based on the discussion (17.02), we decided to give it a try with a full parameter refactoring.
The entire premise is based on the uniqueness of parameter names (ie. both design matrix groups, and genkw groups don't share any parameters) in the global parameter domain / space.
The draft should thus contain two suggestions:

    1. The actual parameter configuration setup. Bear in might that field and surface parameter stay practically the same.
    1. The loading and saving of parameter into the storage. Here, the suggestion was to exploit pollars and use the row-wise way of data storing to preserve the data type:
Parameter Name Value Transformed Value
Param1 10 f(10
Param2 25 f(25)
Param3 100 f(100)
@xjules xjules moved this to Todo in SCOUT Feb 17, 2025
@xjules xjules moved this from Todo to In Progress in SCOUT Feb 18, 2025
@xjules xjules self-assigned this Feb 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

1 participant