Built in datatype for handling money values?

[money] (money | Hex) does exactly what you want. It is not part of the standard library because it does not need to be. This is actually a great advantage because now it can be updated independently.

Enum.reduce(data, 0, &sum.(&1, &2))

I’m pulling data from a database and cannot know ahead of time if all my data would be Money types, but i just need to perform very simple “math” on the data that pull from the db

The code sample above fails when using Decimal: ERR: %ArithmeticError{message: "bad argument in arithmetic expression"}

In that case I’d advise you to use Numbers, which is made to solve exactly that problem.

Do note that Money does not follow Numbers’ specification completely right now, though (And adding that would probably be a backwards-incompatible change).

Another approach would be to define a summation protocol and implement this for any datatypes you might want to use.

This package is probably better, and defines money datatypes for databases (currently postgresql and mysql, I think):

According to the data I have there are:

• 52 currencies that have no decimal places
• 239 that have 2 decimal places
• 3 that have 3 decimal places
• 1 that has four decimal places

But you should also consider that some currencies have specific rounding rules for cash values that relate to the physical currency in circulation.

For example, the AUD and CHF have cash rounding to 0.05 but normal rounding to 0.01.

Additionally there is the question as to when to round and to what precision. In a chain of financial transactions it is most common (according to my research, not an formal statement) that rounding is performed only at the end of the chain.

Then if you are splitting up money (like allocating it to various amounts) then rounding has to be handled carefully to ensure that any remainder is taken care of.

Anyway, money handling and its implication in the real world is an interesting problem - but its not just about decimal arithmetic (I am the author of ex_money and suggestions and PRs are always welcome)

thanks for the stats, but see where the trouble lies … I feel Elixir should make handling decimals natural, so we can do stuff like 100.00 + 10 … and it should just work

Using a protocol, say via @Qqwy’s number library, you could easily just redefine + to call it’s protocol dispatched add function, then it would just work with, say, Decimal.

Something like 100.00 + 10 is ill defined though, I hate hate hate it when languages allow it. Do you want it to be 110.00 or do you want it to be 110 or do you want it to come out as some new type or etc… etc… That is why I like statically strongly typed languages making both operands to + be the same type, that way it is properly formed.

From a decimal and money point of view, how would you want it to manage 100.00 / 3 ? The issues of rounding, when to round, what kind of rounding all still need to be managed and the defaults are probably not what you want and expect.

Rounding is often done in the “half up” fashion - as it is for floats in Elixir/erlang, for financial transactions you probably want to use “half even”.

If you do (100.00 / 3) * 3.2351 then when should the rounding be applied? At each step or only at the end? Where would you specify the rounding in such an expression?

I’m not sure a language can apply the necessary convenience and yet be transparent on the underlying mechanisms. And given that Elixir favours being explicit over implicit I suspect this isn’t a likely focus for the core team.

Understood. But for day to day usage, how best should we handle 2-decimal exact precision numbers? If I’m working with money, then I know that 100.00 +10 is ALWAYS 110.00 - I have a context, I’m working with MONEY

You should convert everything to money before adding. The question of 100.00 + 10 shouldn’t even come up