Support Decimal type

[sitch]

For example:

[Decimal.new(1.5), Decimal.new(2.5)]
|> Math.Enum.mean

produces:

** (ArithmeticError) bad argument in arithmetic expression
             :erlang.+(#Decimal<1.5>, 0)
    (elixir) lib/enum.ex:1755: Enum."-sum/1-lists^foldl/2-0-"/3
      (math) lib/math/enum.ex:52: Math.Enum.mean/1

Decimals are a much better type to work with for those that need precision.

[Qqwy]

Hi @sitch !

I have no idea if this problem is still relevant for you, since we're now three (and a half) years down the road. However, since I recently took over active maintenance of this project, I felt the need to respond.

There is a bit of a conflict here: Many of the functions inside Math only work correctly for floats (and for integers, which in a lot of the cases are converted to floats under the hood). If it is not possible to e.g. use Decimal (or other numeric datatypes that exist in the Elixir ecosystem like Ratio, or Complex) in most or all functions of the library, this might be confusing.

That said, investigating if it is possible is something that I consider worthwhile. I'll spend some time on this, and will get back to you :slightly_smiling_face: .

[Qqwy]

I have done some research. Decimal does not expose any functionality to:

• Perform trigonometry
• Work with logarithms (which could be used to support trigonometric functions with some additional work)
• Work with (non-integer) exponentiation/raising to powers (which could be used to support logarithms and therefore also trigonometry).

This makes it impossible to support Decimal for anything except Math.Enum (and some of the 'General Functions'). Therefore I am not sure if it is worth it.

[Qqwy]

I will close this issue right now as "won't fix". It might make sense to have the functionality for mean/median/mode available for Decimals or other number-types as well, but to my current knowledge it is not possible to introduce versions that work with these types without severely degrading performance of the current implementation, since it would require a runtime check for each element in the collection.

That, combined with the fact that those would be the only functions that would work with non-floats/ints means that we're moving out of the intended design purpose of the Math library. I definitely see the value in an implementation of those algorithms, but they would be better suited in a dedicated library that advertises to be fully usable by user-defined types. (For instance, a library that wraps Numbers?)