New block for raising an input to an Integer exponent

[henrikt-ma]

It is good that the MSL now has the Exponentiation block. In the future, when the MSL uses Modelica 3.6, however, there will be a difference between raising an expression to a Real or to an Integer exponent, see:

• https://specification.modelica.org/maint/3.6/arrays.html#element-wise-exponentiation

This PR introduces an IntegerExponentiation block similar to Exponentiation, but with an Integer exponent.

The fact that there is no separation in semantics in the Modelica version used by the MSL today doesn't mean one cannot have two different blocks already today. Offering both blocks makes it possible to make a future-proof selection of which block to use, and users may also be able to take advantage of the IntegerExponent even before the MSL changes to Modelica 3.6, as it is often possible for users to enable more modern language features in tools while still using an MSL pointing to a language version from the past.

[mestinso]

Why not add this as a feature to the existing model: ie two exponent parameters (realExponont and integerExponent) and a boolean flag to switch between real and integer behavior?

[henrikt-ma]

Why not add this as a feature to the existing model: ie two exponent parameters (realExponont and integerExponent) and a boolean flag to switch between real and integer behavior?

I think it would be too confusing to use a component with two parameters for the same thing, and too cumbersome to have to specify to things when all you want is to select which exponent to use. Also, the name exponent is much nicer than both realExponent and integerExponent by themselves.

[mestinso]

Why not add this as a feature to the existing model: ie two exponent parameters (realExponont and integerExponent) and a boolean flag to switch between real and integer behavior?

I think it would be too confusing to use a component with two parameters for the same thing, and too cumbersome to have to specify to things when all you want is to select which exponent to use. Also, the name exponent is much nicer than both realExponent and integerExponent by themselves.

Another thought is to wrap the exponent (as a Real) into the integer function:

if useIntegerExponent then
  y=u^integer(exponent);
else
  y = u^exponent;
end if;

...but potentially this is also confusing and the behavior can't be guaranteed to behave as desired. However, in my tests, it always behaved as desired (ie integer(2.0)==2)...

I don't feel strongly any which way (probably fine as is). Still, I will comment that this new feature feels more like an "advanced" feature/functionality of an existing component rather than a feature that truly warrants a new component.

[henrikt-ma]

I don't feel strongly any which way (probably fine as is). Still, I will comment that this new feature feels more like an "advanced" feature/functionality of an existing component rather than a feature that truly warrants a new component.

I think that a IntegerExponentiation block has a chance of becoming the more important block if the Modelica specification is ever able to decide on unit semantics of the exponentiation operator (along with all the rest of the language). Now that the exponentiation semantics is already separated into Integer and non-Integer exponents, I hope that this separation will also be used to separate the unit handling semantics:

• a ^ b where b is Real should require that the units of a and b are "1", if any.
• a ^ b where b is Integer (implying that b has not concept of unit):
  • When a has unit "1", the unit of a ^ b is "1" regardless of b.
  • When a has unit other than "1", it is required that b is evaluable, allowing the unit of a ^ b to be determined statically.
  • … (Omitting more details as this is not a language discussion.)

[mestinso]

I think that a IntegerExponentiation block has a chance of becoming the more important block if the Modelica specification is ever able to decide on unit semantics of the exponentiation operator (along with all the rest of the language)...

Ok, if it helps with unit related future improvements, I think that starts to make more sense to me.

Though for the examples you gave, I can't help but wonder where "rational numbers" fit into this picture. E.g. there are scenarios like r=(A/pi)^(1/2) which doesn't fit neatly into the examples given (though of course it could be rearranged back into real^integer case). However, as you mentioned, we don't need to discuss here. Thanks!

[henrikt-ma]

Though for the examples you gave, I can't help but wonder where "rational numbers" fit into this picture. E.g. there are scenarios like r=(A/pi)^(1/2) which doesn't fit neatly into the examples given (though of course it could be rearranged back into real^integer case). However, as you mentioned, we don't need to discuss here. Thanks!

Off-topic: While rational numbers in Modelica would be nice, I don't see it happen. More realistically, we could hope for a new built-in nthRoot that would generalize the current sqrt to other roots than the second. Using this, one could raise a to the power 3/7 like this:

nthRoot(a, 7)^3

If we get such a function, we could then think about how to expose it in the form of blocks.

Edit: Here's a new issue requesting that nthRoot is added to the language: modelica/ModelicaSpecification#3359