rfranke
rfranke
#3700 looks good. Modelica 3.5 brings mostly clarifications for MSL. When does MSL plan to be based on it?
Following discussions under #3700, the best solution might be to revert e40361763bdf818b9d6bbeaf8bf1f28212b3c80c. It was intended as improvement, but what does it improve? It hinders the adoption of Modelica 3.5 instead....
In general you are right. But how to get out of the dead end in this specific case?
Would this then be MSL 5.0 due to a breaking change with include annotations?
The signatures should be correct for the widely tested MSL. It is good that the latest Modelica spec finally addresses issue #1955: "[Changed inputs to C functions to be const-correct,...
The multiplication only gives 0 if a Modelica tool treats `Modelica.Constants.inf` as large number, such as 1e60. IEEE 754 defines 0 * Infinity = NaN Modelica should be developed towards...
It is hard (appears artificial) to restrict Modelica `Real` to finite values, because almost all models are executed on IEEE 754 machines. Here is [how Python treats this since version...
To cut a long discussion short: #3850 would fix the issue.
@christoff-buerger: good that you can explain the result. Still it appears odd that the same `condition` variable gives two different behaviors. The model `EventClockAndClassic` says: ``` Real f = cos(5*time*Modelica.Constants.pi);...
I get from the explanation by @christoff-buerger above that `cosine_angle_input.y` shall be zero during initialization at `time == 0` and jump to 10 immediately afterwards, triggering `rotational_clock_2.y_clock.u`. It is defined...