gleam/int.power(Int, Int) -> Int & gleam/float.power(Float, Float) -> Float

[nksfrank]

Im trying to calculate a value of a base raised to the power of n where all the values are known integers. the current implementation makes that really cumbersome and clunky.

my particular use case is Exercism's Armstrong Numbers
Looking through the community solutions, most of them have implemented their own int_power function to deal with the use case where the value needs to be an int.

the obvious reason for differentiating gleam/int.power and gleam/float.power being the first argument it the aforementioned type. I would have expected the function in a given module to handle that value type. gleam/int.power(Int, Int) -> Int and gleam/float.power(Float, Float) -> Float, thus giving the programmer the ability to handle both value types within the language.

[lpil]

Hello! It is not possible to implement int.power as returning an int as that mathematical operation does not always return a whole number. It is also not possible to have it always return a float as there are numbers for which it is not defined.

[nksfrank]

Thank you for taking time to respond.
ah, yes, that was a mistake, the function signatures would of course be wrapped in a Option return.
I'm most definitely not sufficiently well-versed in the issue to say that a int.power(int, int) could return a non-whole number.

[lpil]

In Gleam we always use Result for modelling fallible results, never option. See the documentation for Option for details.

[mtsknn]

I have encountered this same problem/challenge in more than one Exercism puzzle, so +1.

It is not possible to implement int.power as returning an int as that mathematical operation does not always return a whole number.

@lpil Do you mean that there exist such integers $a$ and $b$ so that $a^b$ produces a non-integer result? Can you give an example? I've tried googling about this and asking ChatGPT but haven't found any answers.

Note that the OP didn't propose changing the current
gleam/int.power(Int, Float) -> Result(Float, Nil)
to
gleam/int.power(Int, Float) -> Result(Int, Nil).

Instead they proposed replacing it with these:

• gleam/int.power(Int, Int) -> Result(Int, Nil)
• gleam/float.power(Float, Float) -> Result(Float, Nil)

I agree this would be handy, unless there really are cases where $\mathbb{Z}^\mathbb{Z} \neq \mathbb{Z}$, in which case this wouldn't be possible.

[ollema]

@mtsknn is it not a problem then that you lose gleam/int.power(Int, Float) -> Result(Float, Nil)?

AFAIK Gleam does not support function overloading so:
gleam/int.power(Int, Float) -> Result(Float, Nil)
and
gleam/int.power(Int, Int) -> Result(Int, Nil)
can not coexist

[lpil]

@mtsknn

int.power(2, -1.0)
// -> Ok(0.5)

[mtsknn]

@lpil Ahhh! Of course. 🫣 😅

@ollema Right, my thinking was that you could still use float.power, like float.power(a |> int.to_float, b). But this point is anyway moot because int.power(Int, Int) -> Result(Int, Nil) isn't possible.