Event generation inside if-statements and use of delay

[henrikt-ma]

During test implementation of event-generating delay, I noticed that there should be similar restrictions for delay (event-generating or not) as for event-generating expressions. That is, I think we should extend some of the restrictions we currently have for event-generating expressions, introduced in #3360, to also cover the use of delay (and spatialDistribution), and that we should do this without waiting for delay and spatialDistribution to become event-generating.

Also did we forget about if-statements in #3360? Consider this:

model RelationInsideIfStatement
  Real x;
  Boolean b;
algorithm
  if time > 1.0 then
    x := 2.0;
    b := x > 1.5;
  else
    x := 1.0;
    b := false;
  end if;
end RelationInsideIfStatement;

I don't see a need to add restrictions for if-expressions and if-equations, since it is easy to rewrite such cases using a helper variable.

[henrikt-ma]

I am thinking that we could write something like this for delay:

The operator is not allowed inside \lstinline!function! classes or in algorithm statements where event generation is not allowed, see \cref{statements-and-algorithm-sections}.

Then, when event-generation for delay is introduced, we change the formulation like so:

The operator is not allowed inside \lstinline!function! classes or in algorithm statements where event generation is not allowed (also when used inside \lstinline!noEvent($\ldots$)!), see \cref{statements-and-algorithm-sections}.

[HansOlsson]

I understand the underlying issue, but I think it needs to be stronger:

• Since delay has history it is also problematic if we have if sin(time)<0 then delay(x, t1) else delay(x, t2), but you can have event-generation in such contexts. Thus I would say they should only be inside if/for with evaluable conditions (similarly as connect - but without special rules for cardinality etc and also the same rule inside expressions); and thus we need a separate rule for this.
• Another solution would be to replace the generic expr as input to delay, by a variable, or have that as an alternative. The reason is that one then delays the variable value, regardless of where the delay call is.

[HansOlsson]

Also did we forget about if-statements in #3360? Consider this:

model RelationInsideIfStatement
  Real x;
  Boolean b;
algorithm
  if time > 1.0 then
    x := 2.0;
    b := x > 1.5;
  else
    x := 1.0;
    b := false;
  end if;
end RelationInsideIfStatement;

No, that case isn't problematic, as a specific crossing function disappear/appears at an event. Handling inactive crossing functions isn't that complicated.

The corresponding case for for-statements (etc) is that the number of crossing functions change, which is more complicated. One could imagine some special rule if the number of crossing functions has an upper bound - but it becomes quite messy.

I don't see a need to add restrictions for if-expressions and if-equations, since it is easy to rewrite such cases using a helper variable.

Or have inactive crossing functions. Helper variables must ensure that they are only evaluated when needed.

[henrikt-ma]

No, that case isn't problematic, as a specific crossing function disappear/appears at an event. Handling inactive crossing functions isn't that complicated.

Good, then this is not a non-standard feature that we have implemented without realizing it is non-standard. :)

[henrikt-ma]

• Another solution would be to replace the generic expr as input to delay, by a variable, or have that as an alternative. The reason is that one then delays the variable value, regardless of where the delay call is.

Do you mean that adding that alternative to the specification would add some new functionality for users?

[HansOlsson]

• Another solution would be to replace the generic expr as input to delay, by a variable, or have that as an alternative. The reason is that one then delays the variable value, regardless of where the delay call is.

Do you mean that adding that alternative to the specification would add some new functionality for users?

Currently there is no restriction on delay, which doesn't really work, so technically we aren't adding new functionality - just avoiding removing functionality to make it work.

I see two possible restrictions that makes it work reliably:

1. Only allow delay when it is active/inactive during the entire simulation interval (so with evaluable conditions).
2. Only allow delay with "safe" arguments (such as variables) that can be delayed regardless of where they appear.

It is possible to allow either or both (or their intersection or some other variant), but thinking more I think only adding the first is the easiest to explain and implement. If there are any problems we can later extend it.

In MSL delay just appears at the top and the argument is always a variable; so only the intersection is actually needed for MSL

(Note that this is a bit more complicated for synchronous models. You can have delay in discretized sub-partitions, which sort of active as they are sort of active - even if clocked; so that works. However, that could then be part of a state machine, I believe the state machine part should also be forbidden. Switching to "safe" arguments wouldn't help as the variables aren't really "safe".)

[HansOlsson]

Just a minor update: It suffices that the condition controlling is a parameter expression, it doesn't have to be evaluable.

[henrikt-ma]

• Another solution would be to replace the generic expr as input to delay, by a variable, or have that as an alternative. The reason is that one then delays the variable value, regardless of where the delay call is.

Do you mean that adding that alternative to the specification would add some new functionality for users?

Currently there is no restriction on delay, which doesn't really work, so technically we aren't adding new functionality - just avoiding removing functionality to make it work.

I think we can safely count on tools being able to introduce a helper variable for the delayed expression if needed, but I must admit I don't see what good it would do. (If the variable isn't a state, the non-normative text about using the (internal) integrator polynomials doesn't apply anyway.)

What I do find useful on the other hand, is to introduce a helper variable for the entire delay-expression, as it allows rewriting

y = if b then delay(x) else 1.0;

into

delayHelper = delay(x);
y = if b then delayHelper else 1.0;

When b is a parameter expression, it might be better not to make this kind of rewrite, but until we are in a future with event-generating delay I don't see that it would really make a difference.

I think that delay inside if-equations should be handled similar to delay inside if-expressions, but the rewriting trick is generally not applicable for if-statements since the delayed expression may only exist within the if-statement branch of the delay. This is where I can see the need for a restriction to parameter (not evaluable) if-statement conditions. (So yes, I agree that handling parameter conditions should be easy enough for tools to implement.)

[henrikt-ma]

We do agree that we also need similar delay restrictions as for event-generating expressions in for- and while-statements, right?

[henrikt-ma]

To be clear, I am trying to avoid the unnecessary breaking of backwards compatibility it would mean to require that b in if b then delay(x) else 1.0 is parametric.

[HansOlsson]

• Another solution would be to replace the generic expr as input to delay, by a variable, or have that as an alternative. The reason is that one then delays the variable value, regardless of where the delay call is.

Do you mean that adding that alternative to the specification would add some new functionality for users?

Currently there is no restriction on delay, which doesn't really work, so technically we aren't adding new functionality - just avoiding removing functionality to make it work.

I think we can safely count on tools being able to introduce a helper variable for the delayed expression if needed, but I must admit I don't see what good it would do. (If the variable isn't a state, the non-normative text about using the (internal) integrator polynomials doesn't apply anyway.)

What I do find useful on the other hand, is to introduce a helper variable for the entire delay-expression, as it allows rewriting

y = if b then delay(x) else 1.0;

into

delayHelper = delay(x);
y = if b then delayHelper else 1.0;

When b is a parameter expression, it might be better not to make this kind of rewrite, but until we are in a future with event-generating delay I don't see that it would really make a difference.

The issue I see is that if the delayed expression isn't a variable (or another safe expression) one can have: y = if noEvent(x>0) then delay(sqrt(x)) else 0.0;, or e.g., y=if i>0 then delay(x[i], 1.0) else 0; so the helper-variable may cause problems.

[henrikt-ma]

The issue I see is that if the delayed expression isn't a variable (or another safe expression) one can have: y = if noEvent(x>0) then delay(sqrt(x)) else 0.0;, or e.g., y=if i>0 then delay(x[i], 1.0) else 0; so the helper-variable may cause problems.

Good point. I wouldn't say that the helper variable is causing problems, but the expression is problematic and that the helper-variable is not a fix for the issue.

To avoid introducing unnecessary backwards compatibility, shouldn't we be able to come up with a more precise characterization of what is not allowed than just rejecting everything except variables? Illustrating this using one of your examples would seem like a good idea to me. Something along the lines of:

The delayed expression expr needs to evaluate successfully at each point in time during simulation.
For example, if noEvent(x>0) then delay(sqrt(x)) else 0.0 makes it an error if x < 0 at any time of the simulation, while delay(if noEvent(x>0) then sqrt(x) else 0.0) imposes no constraint on x.