Allow equality relations among Reals for parameter?

[casella]

MLS Section 3.5 states

In relations of the form v1 == v2 or v1 <> v2, v1 or v2 shall, unless used in a function, not be a subtype of Real.

[The reason for this rule is that relations with Real arguments are transformed to state events (see section 8.5) and this transformation becomes unnecessarily complicated for the == and <> relational operators (e.g., two crossing functions instead of one crossing function needed, epsilon strategy needed even at event instants). Furthermore, testing on equality of Real variables is questionable on machines where the number length in registers is different to number length in main memory.]

"Shall" looks pretty prescriptive to me. Yet, if I try this model on Dymola and OpenModelica (not sure about other tools)

model CheckInequality
  Real x(start = 0, fixed = true);
  Real y;
equation 
  der(x) = 0;
  y = if x == 0 then 2 else 4;
end CheckInequality;

I get some warning along the lines that "Hey, you shoulnd't really do that, but we'll compile your model anyway" and then the model is compiled. In this case it actually behaves correctly, but that's by pure chance.

Here, we have a typical scenario of a MLS rule that has been ignored for ages (at least by some tools), so that people write models ignoring it and then we get into all kind of trouble.

My first question is: should this rule really be enforced, even if it means breaking code that actually runs? If the answer is no, we should rewrite it as

In relations of the form v1 == v2 or v1 <> v2, v1 or v2 should, unless used in a function, not be a subtype of Real.

[If you use such constructs, you may end up having numerically fragile simulation code]

If the answer is yes, then we should really mean it.

Comments?

[ceraolo]

In this case it actually behaves correctly, but that's by pure chance.

IMO there are a full class of comparison of reals that are safe, i.e. those under item 2) in (OpenModelica/OpenModelica#14934 (comment)).

In other cases, (my item 1) they are risky either within or outside functions.

To do these things, however, the programmer should be wise enough to avoid comparisons which risk to be tool-library-OS -timestep-hardware dependent

So, whether the prescription is a recommendation or an imposition depends on what model of user we have in mind.

[HansOlsson]

In this case it actually behaves correctly, but that's by pure chance.

IMO there are a full class of comparison of reals that are safe, i.e. those under item 2) in (OpenModelica/OpenModelica#14934 (comment)).

It is not clear that they are safe, and none of the examples demonstrate a real need.

For floor(time)==a can be seen as sort of safe, but is problematic.

One obvious solution would be to change to integer(time)==a and change a to an integer.
Alternatively rewrite it to: time>=a and time<a+1, which not only handles non-integer values for a, but also is more efficient, since it avoids unnecessary events.

For the other it is more complicated, depending on e.g., double vs. extended double (etc, which is common on some CPUs) a number such as 0.1 can be represented in various ways that don't necessarily compare equal; this is in contrast to numbers such as 1245.0 which can be exactly represented as a double precision number.

It is also requires examining the logic to see that the only way to get x1=0.1 is if the else-branch of the first if-statement (one needs to examine that to verify that 0.1 cannot be the result of a computation with the corresponding pitfalls) so why not write the simpler:

model B
parameter Real a=1.0;
Real t=time, x1, x2;

equation

if time>=a and time<a+1 then
   x1=time+0.2;
   x2=0.0;
else
   x1=0.1;
   x2=-0.1;
end if;

annotation(
    experiment(StopTime = 1.9));
end B;

[ceraolo]

Ehm...
I provided an example which was badly written on purpose, just to show things!

I would never compare reals in a program of mine.

It was just to contribute to the discussion on whether these comparisons should be foridden or not. Since it is known that many libraries compare real numbers, I just tried to figure examples in which these comparisons should not create issues.

And also, consider that inside functions they are allowed by MS. Why?

Reading your comment I may envisage (you do not say explicitly, so it is my guess) that you are against any comparison betwen real numbers.
That is a wise position, which I am not against. But it seems to me that should apply also for comparisons inside functions.
It corresponds to a model of user that in general does not pay enough attention at the potential risks of comparing real numbers.

[maltelenz]

we should really mean it.

System Modeler really means it!

Error: CheckInequality: Invalid relation. Operator == on Real numbers is only allowed inside functions. In x == 0.

This is a hard error, not a warning.

[HansOlsson]

And also, consider that inside functions they are allowed by MS. Why?

Reading your comment I may envisage (you do not say explicitly, so it is my guess) that you are against any comparison betwen real numbers. That is a wise position, which I am not against. But it seems to me that should apply also for comparisons inside functions. It corresponds to a model of user that in general does not pay enough attention at the potential risks of comparing real numbers.

The reason they are even more problematic in models is that model-equations may (depending on tool, model structure, etc) be solved as a system of equations where the variables are only approximated - which increases the problem.

Restricting functions too much on the other hand introduces the risk that people just use an external function, so that's why I think the current restriction to only allow comparison among Reals in functions is an acceptable compromise, and will just check if we can enforce it more.

[henrikt-ma]

This discussion reminds me of the model ModelicaTest.Blocks.ZeroThresholds. While this model is not directly testing equality of Reals, it wants to highlight the difference between strict and non-strict inequality testing. I would put this in the same ballpark as equality testing. In an extremely simple test model like this, I can sort of understand the expectation that one should be able to correctly distinguish between strict and non-strict comparison, but I am quite skeptical about the general case. This makes me wonder if even the extremely simple test model really is a good example of what users can expect?

[ceraolo]

Restricting functions too much on the other hand introduces the risk that people just use an external function, so that's why I think the current restriction to only allow comparison among Reals in functions is an acceptable compromise, and will just check if we can enforce it more.

Thank you for the explanation.
When we compare two reals in functions (at least) one of them may come from the input, and thus be subject, before entering the function, to a lot of floating point computations, so, AFAICT, the risk of having unreliable results is very similar to that when we compare in equation sections of models. And that risk remains also when using external functions.
Am I missing something?

[henrikt-ma]

Personally, I find careful use of floating point equality testing very handy from time to time, so I can clearly see the benefit of being able to express those algorithms inside a Modelica function. I think that what you are missing is that we hold the author of the function more responsible for using equality testing with care inside the algorithm in the body of the function, whereas equality testing outside of functions is in the domain of the symbolic processing for which tools are responsible, and for this a more solid foundation is needed.

[HansOlsson]

This discussion reminds me of the model ModelicaTest.Blocks.ZeroThresholds. While this model is not directly testing equality of Reals, it wants to highlight the difference between strict and non-strict inequality testing. I would put this in the same ballpark as equality testing. In an extremely simple test model like this, I can sort of understand the expectation that one should be able to correctly distinguish between strict and non-strict comparison, but I am quite skeptical about the general case. This makes me wonder if even the extremely simple test model really is a good example of what users can expect?

As noted in the PR that added ZeroThresholds it relies on separating >= from > for Modelica.Blocks, and if we really wanted to have been strict about not comparing Reals we shouldn't have both >= and > for Reals.

There's some simply no perfect solution, but the current trade-off seems acceptable.

Personally, I find careful use of floating point equality testing very handy from time to time, so I can clearly see the benefit of being able to express those algorithms inside a Modelica function. I think that what you are missing is that we hold the author of the function more responsible for using equality testing with care inside the algorithm in the body of the function, whereas equality testing outside of functions is in the domain of the symbolic processing for which tools are responsible, and for this a more solid foundation is needed.

Exactly. And as noted even if equality testing in a Modelica function is a bit problematic, it's better than people switching to external functions just for to perform that.

[ceraolo]

I think that what you are missing is that we hold the author of the function more responsible for using equality testing with care inside the algorithm in the body of the function, whereas equality testing outside of functions is in the domain of the symbolic processing for which tools are responsible, and for this a more solid foundation is needed.

Exactly. And as noted even if equality testing in a Modelica function is a bit problematic, it's better than people switching to external functions just for to perform that.

OK.