How about support for rational numbers in Elixir/BEAM?

Got a little confused since Ratio 3.x no longer supports use Ratio. In general, I don’t like operator overloading neither in this case, nor in my times with C++. I think this should be approached the same as comparing DateTimes.

I think I’d like the addition of rationals into the VM if we had some sort of static typing. Knowing types at compile time allows the VM to squeeze out more performance. Supposedly it would be also visible to the developer that a particular “a + b” may be more time consuming then adding two integers.

Yup, we didn’t yet update to Ratio 3.0, because we use it in many places and we’d have to do it all at once, so it’s not just a matter of bumping the version I generally agree that operator overloading is confusing when applied to things like dates, but when it comes to numbers, well, these operators were created for handling numbers. Not using operators makes things twice as less readable and adds the risk that someone accidentally uses > instead of Ratio.gt. Regarding performance, I don’t think that the difference between integers and rationals would be that crucial to make it always visible for developers. They are not tensors after all And the compiler still has to check for integers and floats upon each operation.

I feel like the decision against operator overloading has been made a long time ago. Otherwise I expect us to have operator overloading for the Decimal library, which has been around since around elixir 0.13. I’d be curious if an approach like Nx took with defn would be more fruitful, where the mathematical operations can be defined in a context separate to core elixir, but using the same syntax.

Even with operator overloading like Numbers does, you still can’t just naively reuse code that was expecting number() values, since comparisons in guards aren’t overloaded:

def foo(x) when x > 0 do
  x * 3
end
def foo(x) do
  x * 2
end

# vs

def foo_no_guard(x)
  if x > 0 do
    x * 3
  else
    x * 2
  end
end

Nice to hear that you are using Ratio!

Unfortunately, Elixir’s hands are a bit tied in this regard: It is impossible to add support for a rational type in a way that would work as expected in guards without changing the Erlang VM itself.

Personally I would be very happy if support for decimals and rationals would be added as builtins to Erlang, because I also think that their usage is common enough to warrant this. However, I expect that such a change is highly unlikely because it would be a large undertaking to add support to them. (This besides the fact that not everyone agrees that they should be added in the first place.)

To respond to your separate points in detail:

• Comparison: This is the case to allow collections (like maps and sets) to work with any mixture of keys/elements. In practice these kinds of collections are rather rare, however.
• Performance: I have not done any benchmarking myself. I’d expect the code to be reasonably performant now that we have a JIT, but it would definitely be interesting to look at how fast things would be if one were to inline most of the logic in the final module; currently there are multiple function-call-indirections that happen for many operations. But long story short: If you are doing a lot of math that needs to be performant, you might want to look into using Nx or a NIF.
• Reuse: Being able to support arithmetic for arbitrary datastructures is the gap the Numbers tries to fill. If you’re using a dependency that does not allow it, you could always contribute a PR to that dependency. In my experience, people are quite open to this kind of extension of functionality .

Thanks for the answer and the library

Concerning guards, maybe it would be possible to support them? Now it’s possible to extract values from the struct and I think it wouldn’t be necessary to reduce the fractions there

I’m afraid I agree. I’ll ask at the Erlang forum though, maybe they have some useful thoughts.

We don’t do any big math in Elixir, though small operations done frequently in different places contribute to the load. Since they’re small, I don’t expect delegating to the native code to help. But I’ll come back when I have benchmarks

Good to hear that Numbers are welcome