-
Notifications
You must be signed in to change notification settings - Fork 43
Handle units of literal constants by means of rules for the empty unit #3257
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
base: MCP/0027
Are you sure you want to change the base?
Changes from 7 commits
7524b11
1309d10
2dfb4e8
0c62f41
203c16e
5d42065
fc4abde
b86567b
1f5131c
3291a73
f639afc
3a3b1f0
e411347
f3755a2
fccda32
89092ba
82bb062
99ff3c9
13529f7
847e645
ebfc229
232c4fa
9aeb15f
a28b795
089f554
35e4f01
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,34 @@ | ||
| # Modelica Change Proposal MCP-0027<br/>Units of Literal Constants | ||
| Francesco Casella, Henrik Tidefelt | ||
|
|
||
| **(In Development)** | ||
|
|
||
| ## Summary | ||
| The purpose of this MCP is to allow more unit errors to be detected by giving more expressions the unit `"1"` instead of having an undefined unit. | ||
| The problem with undefined unit is that it gets in the way of carrying out checking of units (which tools tend to deal with by not checking units at all where this happens). | ||
|
|
||
| ## Revisions | ||
| | Date | Description | | ||
| | --- | --- | | ||
| | 2022-10-04 | Henrik Tidefelt. Filling this document with initial content. | | ||
|
|
||
| ## Contributor License Agreement | ||
| All authors of this MCP or their organizations have signed the "Modelica Contributor License Agreement". | ||
|
|
||
| ## Rationale | ||
| FIXME | ||
|
|
||
| ## Backwards Compatibility | ||
| As current Modelica doesn't clearly reject some models with non-sensical combination of units, this MCP will break backwards compatibility by turning at least some of these invalid. | ||
|
|
||
| ## Tool Implementation | ||
| None, so far. | ||
|
|
||
| ### Experience with Prototype | ||
| N/A | ||
|
|
||
| ## Required Patents | ||
| To the best of our knowledge, there are no patents that would conflict with the incorporation of this MCP. | ||
|
|
||
| ## References | ||
| (None.) |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -89,3 +89,171 @@ \section{The Syntax of Unit Expressions}\label{the-syntax-of-unit-expressions} | |
|
|
||
| The unit expression \lstinline!"T"! means tesla, but note that the letter \lstinline!T! is also the symbol for the prefix tera which has a multiplier value of 10\textsuperscript{12}. | ||
| \end{example} | ||
|
|
||
|
|
||
| \section{Unit Checking}\label{unit-checking} | ||
|
|
||
| How to verify that units are used in compatible ways is current not fully determined by the specification. | ||
| This section gives rules for certain situations, but in general tools are expected to reason according to standard dimensional analysis.. | ||
|
|
||
|
|
||
| \subsection{Standard Dimensional Analysis}\label{standard-dimensional-analysis} | ||
|
|
||
| This section gives an incomplete characterization of \emph{standard dimensional analysis}, also referred to as just \firstuse{dimensional analysis}. | ||
| What is described below applies to unit checking in Modelica -- \emph{standard dimensional analysis} could have additional meanings in other contexts. | ||
| While Modelica has a concept of \willintroduce{empty units} (described in later sections), standard dimensional analysis only deals with non-empty units such as \lstinline!"m"!, \lstinline!"m/s"!, or \lstinline!"1"!. | ||
| It consists of two parts: | ||
| \begin{itemize} | ||
| \item | ||
| Unit compatibility requirements. | ||
| \item | ||
| Rules for deriving the unit of an expression. | ||
| \end{itemize} | ||
|
|
||
| Examples of unit compatibility requirements that must be met in Modelica: | ||
| \begin{itemize} | ||
| \item | ||
| The expression of a declaration equation must have the same unit as the component to which it belongs. | ||
| \item | ||
| The two sides of an equation or assignment statement must have the same unit. | ||
henrikt-ma marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| \item | ||
| The two operands of the additive operators \lstinline!+! and \lstinline!-! must have the same unit. | ||
| \item | ||
| In a function call, the unit of an argument expression must match the unit (unless empty, see below) of the corresponding function input component. | ||
| \end{itemize} | ||
|
|
||
| % TODO: Replace these examples by giving unit semantics where operators and built-in functions are defined in the specification, | ||
| % and just include some likes to places where such semantics are given. | ||
| Examples of unit derivation in Modelica: | ||
| \begin{itemize} | ||
| \item | ||
| The result of additive operators has the same unit as the operands. | ||
| \item | ||
| The result of multiplication has a unit obtained by adding the exponents of the operands' units. | ||
henrikt-ma marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| \item | ||
| Built-in operators such as \lstinline!pre! and \lstinline!previous! preserve units, while \lstinline!der! changes the unit by dividing it by \lstinline!"s"!. | ||
| \end{itemize} | ||
|
|
||
|
|
||
| \subsection{Empty and Undefined Units}\label{empty-and-undefined-units} | ||
|
|
||
| In situations where the specification does not prescribe how to determine the unit of an expression, the unit of that expression is said to be \firstuse[undefined unit]{undefined}. | ||
| It is then not possible for a tool to reject the equation (or other construct) with support in the specification, and options for the tool include silently not performing unit checking, or applying checks based dimensional analysis. | ||
henrikt-ma marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
henrikt-ma marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
|
|
||
| The unit of an expression can also be defined as being \firstuse[empty unit]{empty}, see below. | ||
| In certain places (see below), expressions with empty unit can be implicitly cast to suitable units. | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not a friend of "soft" qualifiers like "certain", "some of", etc. in specification texts. I think it would be better to enumerate all the specific places/sections/cases you mean to include in this statement. Include a "fall-through" case handling the situation if no element of the enumeration fits, if appropriate.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The paragraph is part of the section introduction, so it isn't meant to convey the details. I agree that later, when the actual rule is given, one has to avoid formulations that risk causing unnecessary ambiguity. Does it work better now, with the reformulated presentation of the corresponding list of cases? (I don't think this list needs a fall-through case, as it should always be possible to add more cases in a backwards compatible way.) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Should it then be marked non-normative? Otherwise, it's normative, right? (I'm not too firm on the procedural details of this)
I can't tell which list you mean here?
This is not a contradiction! You can first specify (random example: operators covered by some procedure):
and then later refine by adding more cases
The set of the fallthrough/uncovered cases shrinks by adding more cases, but it's always crystal clear which ones are "undefined" (first: everything except +,-, then everything except +,-,*,/)
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I'm not sure. It's a matter of style where we have at least decided to not explicitly mark chapter introductions as non-normative even though their nature is non-normative. In the case at hand, I'd say that the (see below) should be sufficient to ensure the reader that there's a specific meaning of certain places to be found by looking at the sections below.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I refer to formulations like this one:
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
The nice thing about this list (When encountering the empty unit in…) is that it doesn't leave any situation undefined. In the other cases, the unit isn't determined by the context, but always becomes |
||
| When an expression with empty unit is implicitly cast to some unit, that unit is referred to as the \firstuse{inferred unit} of the expression. | ||
|
|
||
|
|
||
| \subsection{Unit Inference}\label{unit-inference} | ||
|
|
||
| Where the empty unit has no other defined meaning, it can be implicitly cast to unit \lstinline!"1"!. | ||
|
|
||
| In some cases the empty unit can be implicitly cast to an inferred unit: | ||
| \begin{itemize} | ||
| \item | ||
| In binding equations and modifications: | ||
| \begin{itemize} | ||
| \item The entire expression of the binding or modification. | ||
| \item When the entire expression is an array construction, array concatenation and array range, then apply rules recursively for the direct subexpressions. | ||
| \end{itemize} | ||
| \item | ||
| The entire argument expression in a function call. | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Comparing it to #3266 (comment) it seems that it has the same critical flaw. In general, my issue with some proposals is that there are way too much text and theory, but too little actual practice. I can see that the other proposal - changed to not apply to addition and subtraction - does detect actual modeling issues; but also that it finds a number of issues that aren't that important and will take time to correct. I don't know if people are actually willing to put in the effort to correct - and I don't know the corresponding result for this proposal.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I think it needs to be seen in the light of me looking for a solid ground on which to implement unit checking in System Modeler, where the specification at least marks a starting point for something that can evolve into a set of rules that make unit consistency a model feature that is portable between tools.
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Can you explain what you mean by that, because to me this proposal is very clear?
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
You are just describing the properties of a sound logical system, as opposed to a complete one. |
||
| % To keep the design close to the bare minimum, this part is currently excluded: | ||
| %\item | ||
| % For a translation-time constant with value 0.0: | ||
| % \begin{itemize} | ||
| % \item Expressions constituting the entire side of an equality or relation. | ||
| % \item The right hand side of an assignment. | ||
| % \item The direct subexpressions of array construction, array concatenation, and array range. | ||
| % \end{itemize} | ||
| \end{itemize} | ||
|
|
||
|
|
||
| \subsection{Expressions with Empty Unit}\label{expressions-with-empty-unit} | ||
|
|
||
| This section describes conditions under which an expression has empty unit. | ||
| Conditions not given here must not be interpreted as definitely not implying empty unit; instead, the unit may be currently undefined for some expressions, allowing the unit to be properly defined in future versions of the specification. | ||
|
|
||
| Basic expressions defined to have empty unit: | ||
| \begin{itemize} | ||
| \item | ||
| \lstinline!Real! literals. | ||
| \item | ||
| \lstinline!Integer! expressions implicitly cast to \lstinline!Real!. | ||
| \end{itemize} | ||
|
|
||
| Expressions defined to \emph{not} propagate the empty unit, thereby forcing inference of unit \lstinline!"1"!: | ||
| \begin{itemize} | ||
| \item | ||
| Addition, subtraction, multiplication and division operators when either operand has non-empty unit. | ||
|
||
| \item | ||
| Right operand of binary exponentiation. | ||
|
||
| \item | ||
| Component references outside of functions, where the component's declared \lstinline!unit!-attribute is \lstinline!""! (possibly by not being specified). | ||
| (Unit checking involving user-defined functions with empty unit on inputs and outputs is currently not defined.) | ||
| \end{itemize} | ||
|
|
||
| Built-in non-array operators, functions, and special expressions that propagate any unit (including empty): | ||
| \begin{itemize} | ||
| \item | ||
| When all operands have the same unit: negation, addition, and subtraction (scalar or element-wise). | ||
| \end{itemize} | ||
|
|
||
| Special situations in which the empty unit can be propagated up the expression tree: | ||
henrikt-ma marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| \begin{itemize} | ||
| \item | ||
| Multiplication and division when both operands have empty unit. | ||
|
||
| \end{itemize} | ||
|
|
||
| \begin{example} | ||
| Consider unit checking of the following declaration equation: | ||
| \begin{lstlisting}[language=modelica] | ||
| Real y(unit = "m") = 1 + 2.5 * 3; | ||
| \end{lstlisting} | ||
| The unit of the declaration equation right-hand side is determined as follows: | ||
| \begin{itemize} | ||
| \item The \lstinline!Real! literal \lstinline!2.5! has empty unit. | ||
| \item The \lstinline!Integer! literals \lstinline!1! and \lstinline!3! are implicitly cast to \lstinline!Real!, and therefore have empty unit. | ||
| \item The multiplication \lstinline!2.5 * 3! has empty unit, as multiplication can propagate the empty unit of both operands. | ||
| \item The addition \lstinline!1 + (2.5 * 3)! has empty unit, as addition can propagate any unit as long as both operands have the same unit. | ||
| \item The entire right-hand side expression gets inferred unit \lstinline!"m"! in order to be compatible with the component's declared \lstinline!unit!. | ||
| \end{itemize} | ||
| \end{example} | ||
|
|
||
| \begin{example} | ||
| Consider unit checking of the following erroneous declaration equation for \lstinline!y!: | ||
| \begin{lstlisting}[language=modelica] | ||
| Real x(unit = "m") = 1.0; | ||
| Real y(unit = "m") = x^2 / 2; | ||
| \end{lstlisting} | ||
| The unit of the declaration equation right-hand side is determined as follows: | ||
| \begin{itemize} | ||
| \item The unit of \lstinline!x! is \lstinline!"m"!, and dimensional analysis gives that \lstinline!x^2! has unit \lstinline!"m2"! | ||
| \item The \lstinline!Real! literal \lstinline!1.0! has empty unit, and gets inferred unit \lstinline!"m"!. | ||
| \item As the left operand of \lstinline!x^2 / 2! is non-empty, the right operand cannot be empty, and hence empty unit of \lstinline!2! is implicitly cast to \lstinline!"1"!. | ||
| \item Dimensional analysis then gives that the unit of \lstinline!x^2 / 2! is \lstinline!"m2"!, which is an error due to the required unit being \lstinline!"m"!. | ||
| \end{itemize} | ||
| \end{example} | ||
|
|
||
| \begin{example} | ||
| Consider the potential consequences of an undefined unit in the following declaration equation: | ||
| \begin{lstlisting}[language=modelica] | ||
| Real y(unit = "m") = sin(1.57); | ||
| \end{lstlisting} | ||
| To see that the unit of the declaration equation right-hand side is undefined, note that: | ||
| \begin{itemize} | ||
| \item The \lstinline!Real! literal \lstinline!1.57! has empty unit. | ||
| \item The expression \lstinline!sin(1.57)! is not covered by the specification, and hence has undefined unit. | ||
| \end{itemize} | ||
| If a tool wants to proceed according to ``standard dimensional analysis'', alternatives include: | ||
| \begin{itemize} | ||
| \item | ||
| Assume that \lstinline!sin! is a mapping from unit \lstinline!"1"! to unit \lstinline!"1"!. | ||
| The unit of \lstinline!1.57! then defaults to \lstinline!"1"! (alternatively, the same unit could be obtained by inference). | ||
| The unit of \lstinline!sin(1.57)! is then found to be \lstinline!"1"!, which is an error due to the required unit being \lstinline!"m"!. | ||
| \item | ||
| Assume that \lstinline!sin! preserves both the unit \lstinline!"1"! and the empty unit. | ||
| The empty unit of \lstinline!1.57! gets propagated to \lstinline!sin(1.57)!, which in turn gets inferred unit \lstinline!"m"!. | ||
| \end{itemize} | ||
| \end{example} | ||
Uh oh!
There was an error while loading. Please reload this page.