Add "Square" and "Pow" math blocks

[mestinso]

Two math blocks that are often useful for me, but appear to be missing in MSL, are square and pow blocks. The basic equations:

Square:
y = u^2;

Pow:
y = u^p;
where p is a parameter (say default of 2)
...I would prefer "Power", but that's already taken

Thoughts/comments? Any idea why these aren't part of MSL already? They seem like common enough operations that they should be included. Note we already have a "Sqrt" block (y = u^0.5), which is a wrapper around the built-in sqrt function, which I'm guessing is why that one is present but the above ones are not.

[mestinso]

Any input on this one? I think the power operation one (y = u^p; where p is a parameter) is pretty essential.

Square isn't strictly required (assuming the new power block is added), but I think it's a nice quality of life element. And, on that note, below are some additional ones that could be added as well:

Unary Minus:
y = -u;

Reciprocal:
y = 1/u;

[AHaumer]

Feel free to prepare a PR, but keep the special cases in mind:
1/0
(-u)^p with p non-integer
BTW, y=-u ist just the gain block with k=-1.

[HansOlsson]

And 1/u is just division with a nominator of 1. Thus it does not seem clear to me that reciprocal and unary minus are necessary - and I see a potential problem that having too many blocks will make it harder to find the relevant ones.

For power I agree that there are many important special cases; not only (-u)^p for non-integer p but also specifically (-u)^(m/n) for integers m and n (where n is odd), or possibly just the roots.

[henrikt-ma]

As long as there isn't a source block that produces a true constant (see #3112), there's a techical use case for a Reciprocal block: With a Reciprocal block one could express the equation:

y = 1 / u;

Since we don't allow u to be infinite, this means that y is non-zero, making it mathematically sound to solve the equation with respect to u:

u = 1 / y;

By comparison, using a parameter signal for the numerator (coming from Modelica.Blocks.Sources.Constant), one gets the equation

y = k / u;

where k could be zero. This equation cannot safely be solved with respect to u.

In addition to the lack of a block that produces a true constant, it is also a matter of convenience to not have to add a separate block for the constant 1 in the numerator.

An alternative could be to make the numerator connector of the Modelica.Blocks.Math.Division block conditional.

[henrikt-ma]

Similar arguments can be made regarding the need for a Negate block; the equation one gets with a parameter k = -1 cannot be solved safely with respect to u:

y = k * u;

[mestinso]

Sounds like there is consensus regarding the need for the power block at the very least. Maybe I'll create a PR on that one first. The main issue is naming. Ideally, the block should be called "Power" I think, but that name is taken. Another option is "Pow" as mentioned in the first post, but that is of course just short for power and is potentially a bad choice since we would be left with "Pow" and "Power" blocks which is a little awkward.

Ideally, I think the naming should be the following:
"Power" Block:
y = u^p; where p is a parameter
and
"Exponentiation" Block:
y = p^u; where p is a parameter <-- This would mean a rename of the existing "Power" block to "Exponentiation"

Am I correct in assuming this would be too disruptive to make this change (even if Modelica conversions scripts were used)?

Another choice is to use the name "Exponentiation" for the new block (y=u^p;) even though the naming is arguably a little wrong/backwards.