modelica / fmi-standard

Specification of the Functional Mock-up Interface (FMI)
https://fmi-standard.org/
Other
269 stars 84 forks source link

Incorrect variable naming for fmi3GetIntervalFraction, fmi3SetIntervalFraction, fmi3GetShiftFraction and fmi3SetShiftFraction #1985

Open Tc-Fast opened 1 day ago

Tc-Fast commented 1 day ago

In order to maintain backwards compatibility the naming in the xsd files can not be changed. I suggest to leave the names in the xsd therefor as is and add a comment for clarification.

pmai commented 16 hours ago
  • The functions fmi3GetIntervalFraction, fmi3SetIntervalFraction, fmi3GetShiftFraction and fmi3SetShiftFraction use arguments named "counter" and "resolution". This is incomprehensible. The variable names should be "intervalNumerators", "intervalDenominators", "shiftNumerators" and "shiftDenominators", because these names are commonly used in the context of fractions.

This seems to me to be the underlying mis-understanding: That these accessors are about fractions, which would rather suggest that the Fraction part of their names should be struck. The non-fraction versions of these accessors are also dealing in fractions, as floating-point numbers are just as much fractions as the others are. The fact that these accessors carry "Decimal" in their name is lamentable - given that these are exactly not decimal but binary fractions - but like the rest of the naming not something up for change this late in the game.

  • The variable "counter" is not a "counter". I guess this name is the result of a translation from german to english ("Zähler" -> "Counter"), but in the context of fraction it should translate to "numerator".

Disregarding the fact that numerator is just the latin word for counter in any case (no need to take german into account here), this is not about fractions, it is about the way that such clocks are usually implemented: You have a counter that counts up, the resolution of which then determines how this is mapped to the time unit, how it fits into the overall schedule, and how and when wrap-around is handled. This is usually tied to an overall scheduling mechanism, but that is beyond the things that FMI standardizes (which makes explaining the concepts slightly more problematic).

  • The documentation states about the "counter" variable: "Note: This variable may increment by values other than 1." This is wrong, since the "counter" is not a "counter". It is never incremented or decremented.

This is talking about the internal implementation, where exactly this counter does count up. Which again suggests that the whole fraction business is misleading you into thinking this should be about fractions (the mathematical concept), not clocks and scheduling. So we should rather downplay this whole fractional wording, rather than more fully embracing it.

  • The variable "resolution" is misleading as well. A fraction does not have a "resolution".

But a schedule or clock does. Just because a concept can be expressed via mathematical constructs does not make them the same (or as Korzybski would have it: The map is not the territory).

In order to maintain backwards compatibility the naming in the xsd files can not be changed. I suggest to leave the names in the xsd therefor as is and add a comment for clarification.

I suggest to not change any of the naming, but rather explain more clearly the concepts in a way that does not mislead people into thinking about fractions the whole time.

chrbertsch commented 14 hours ago

FMI Design Meeting: Pierre: the clocks have counters and resolutions. The wording stems from how you would implement clocks. It is perhaps misleading that we talk about fractions ... We might want to look into the Modelica spec. Nikolai: I will look into this and start a new PR.