ModelicaSpecification
ModelicaSpecification copied to clipboard
modelica
Should we relax the rule concerning function dimensions.
When trying to enforce the fact that:
The dimension sizes not declared with colon (:) of each array result or array local variable (i.e., a non-input component) of a function must be either given by the input formal parameters, or given by constant or parameter expressions, or by expressions containing combinations of those (section 12.4.4).
I have discovered that at least:
Modelica.Blocks.Continuous.Internal.Filter.roots.bandStop
Modelica.Blocks.Continuous.Internal.Filter.roots.bandPass
Modelica.Blocks.Continuous.Internal.Filter.base.ChebyshevI
Modelica.Blocks.Continuous.Internal.Filter.base.Butterworth
Modelica.Blocks.Continuous.Internal.Filter.base.Bessel
do not meet this requirement. In particular, in Modelica.Blocks.Continuous.Internal.Filter.roots.bandStop, the 1st dimension of c1 depends on a which is an output.
I think a constraint that they depend at most indirectly on input formal parameters would be enough. I am not even sure that we need to specify anything beside something similar to what we have for default binding, that is:
These bindings must be executed in an order where a variable is not used before its binding equations has been executed; it is an error if no such order exists (i.e. the binding must be acyclic).
This relates to https://github.com/modelica/ModelicaStandardLibrary/issues/593.
To me it would seem natural to have different rules for outputs and local components:
- For an output component with non-colon dimension, the size should be possible to determine based on just the public parts of the function (some might refer to this as the function signature).
- For a local component, I agree with @qlambert-pro that the specification appears over-constrained today.
Being able to use local variables to factorise code would be nice though.
Being able to use local variables to factorise code would be nice though.
Indeed. To not destroy the current function signature concept too badly, it feels like one would need some kind of semi-public non-input/output single-assignable component. Perhaps declared as protected input…
function f
input Real[:] x;
output Real[yLen] y;
protected
input Integer yLen = size(x, 1); /* Non-assignable local variable allowed to be used like an input. */
algorithm
…
end f;
That is, the protected input components would be considered helper variables that are part of the function signature, and one would need to update the declaration equation rules to make sure they fulfill the requirements we need (require declaration equation, not depend on any "fully" protected variable, etc).
I think a constraint that they depend at most indirectly on input formal parameters would be enough. I am not even sure that we need to specify anything beside something similar to what we have for default binding, that is:
These bindings must be executed in an order where a variable is not used before its binding equations has been executed; it is an error if no such order exists (i.e. the binding must be acyclic).
Possibly, but in that case we should combine the two - so that bindings combined with sizes must be acyclic.
Possibly, but in that case we should combine the two - so that bindings combined with sizes must be acyclic.
I am fine with that.
Possibly, but in that case we should combine the two - so that bindings combined with sizes must be acyclic.
I am fine with that.
Unfortunately I'm not 100% sure how to write that text.
It is a bit non-trivial since we have the following:
- Proposed separation of sizes for outputs and protected variables, even though some have tried to use
protected Integer n=size(A,1);when declaring size of outputs. - Sizes for inputs. They are just constraint on the inputs, so cycles are ok, e.g.,
input Real A[:,size(A,1)];is a square matrix. - Both sizes and bindings? I guess we should consider both, right?
What about:
The dimension sizes not declared with colon (:) of each array result or array local variable (i.e., a non-input component) of a function must be computable without executing the body of the function.
Possibly, with a link to the paragraph on function calls, to indicate that this dimensions should be known after having processed the inputs and default bindings of the different variables.