-
-
Notifications
You must be signed in to change notification settings - Fork 209
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
Proposal for @constants
#1802
Comments
That's a good idea. |
Agreed. The same idea also exists in Modelica. |
Working on a prototype. |
I'm stuck on how to treat these during flattening/renamespacing. @YingboMa Do we want to assume these are global or should we allow to have different values for different subsystems? I'm leaning toward the former - if it's not global, it's not a real constant, it's just a fixed parameter. |
Prototype is here. Still needs more work before it's ready for a PR, but I'd like feedback on my strategy first. |
Done! |
What if we introduced a new category of
@constants
, alongside@parameters
? My use case is including physical constants or unit conversion factors. These don't belong in parameter vectors, especially not the anonymous conversion factors generated by the unit conversion pass.Basically, we'd add a new metadata tag
MTKConstantCtx
, analogous toMTKParameterCtx
. The@constants
macro would require a default value.build_function
would just use the default value.This method is less flexible than something like a tag on the parameter vector (b/c it requires rebuilding the system to change a parameter to a constant). However, I want these constants to not appear in the parameter vector at all. So we'd have two different ways to make some thing constant. I'm wondering if that's too confusing.
The text was updated successfully, but these errors were encountered: