-
Notifications
You must be signed in to change notification settings - Fork 42
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
Gather annotations for functions with impact on symbolic processing #2895
Comments
The first two changes makes sense to me; as those annotations are for functions and it makes sense to keep function annotations together. However, I think that HideResult and Evaluate can stay in the now shorter "Annotations for Code Generation". I don't think we should create a separate section for "Evaluate" just because it is that important, and "Annotations for Simulations" are about general settings for the entire simulation, whereas HideResult, as well as Evaluate, influence the code for specific components. |
Agree on restructuring chapter, and move function ones to function chapter. |
Regarding
Edit: Here is a proposal for a poll regarding
|
Adding to milestone of upcoming phone meeting in hope of discussion the question above regarding deprecation of |
The issue is that people have found it useful, and removing it without an alternative doesn't make sense. So, the obvious question is whether we can solve it in another way - and one option would be to go for MCP-0012, https://github.com/modelica/ModelicaSpecification/blob/MCP/0012/RationaleMCP/0012/MCP-0012_CallingBlocksAsFunctions.pdf and instead of allowing functions to generate events we allow calling blocks that generate events as if they were functions. An issue is that level 2 and 3 of that proposal rely on not yet unsolved issues regarding state-machines, but that's just another reason to improve state-machines. |
See proposal in edited comment above. With |
I don't see why the second option forbids combinations with other inlining. Both inlining after index reduction and late inlining should work together with generating events. |
The reason was just for simplicity; the
|
We've recently made improvements to the
inverse
andderivative
annotations for functions, and I think this makes it a good time to also consider the other highly related annotations for functions with impact on symbolic processing. Currently, these are described in 18.3 Annotations for Code Generation:Inline
LateInline
InlineAfterIndexReduction
GenerateEvents
smoothOrder
As is clearly stated in the text,
smoothOrder
is closely related toderivative
:To me, this just shows that
smoothOrder
andderivative
should be described next to each other.That the inlining annotations have a close relation with
inverse
andderivative
should probably be expressed more clearly both in text and by describing the annotations in the same chapter and section. When to inline is seems to me as more of a tricky tradeoff between keeping the specializedinverse
andderivative
functions applicable and making the expressions of a function body available to general symbolic processing, than a question about how to avoid function calling overhead in the generated code (referring to the title of 18.3).GenerateEvents
has an intricate relation to inlining. For example, the combinationGenerateEvents = true
andInline = false
is particularly challenging, showing the close relation between the two. Because of this, but also becauseGenerateEvents
has other effects on symbolic processing as well, it should be described along with annotations for inlining as well as other annotations for functions with impact on symbolic processing.If all of the above would be moved to a common section for annotations for functions (chapter 12 or 18), this would leave only
Evaluate
andHideResult
in 18.3, neither of which seems related to code generation. Thus, to make a more concrete proposal, I suggest:smoothOrder
to 12.7 Declaring Derivatives of FunctionsInline
,LateInline
,InlineAfterIndexReduction
, andGenerateEvents
.HideResult
to 18.4 Annotations for SimulationsEvaluate
is so fundamental that it deserves its own section right at the beginning of chapter 18: Annotations of Utter Importance. :)The text was updated successfully, but these errors were encountered: