Overbryd
Decimal arithmetic - using 'defmacro' gives me ArithmeticError
I am implementing an application that deals with monetary values. Therefore I use the excellent Decimal library to handle such values.
Now arithmetic is supported by the various functions provided by the module, e.g. Decimal.add/2.
But this results in very hard to read and write code, take this for an example:
# I would love to write: distance = price / order_price
# But I have to write:
distance = Decimal.div(price, order_price)
# This gets even more messy when dealing with multiple values
multiplier = 0.2
sale = Decimal.add(price, Decimal.mult(price, Decimal.new(multiplier)))
So, defmacro to the rescue?
Yea, I thought I really have a clean solution with a prefix macro that deals with decimal arithmetic.
Now, in my tests writing this prefix-macro I could do this:
a = Decimal.new(1)
b = Decimal.new(2)
result = decimal a + b
assert result == Decimal.new(3)
# Tests passed, hooray!
But as soon as I used this code in my application, suddenly I got lots of (ArithmeticError) bad argument in arithmetic expression
Why is this happening? Is Elixir inlining the arithmetic expressions and therefore falling back to the Kernel defaults?
I thought I explicitly loaded the Decimal.Prefix macros in the enclosed/0 function.
The weird thing, tests pass just fine, but I don’t get why errors appear when the application runs.
And I double checked the inputs, they are all of Decimal type.
Help in this matter (also the original thing, dealing with monetary values doing arithmetic with these) is highly appreciated.
Kind regards,
Lukas
Marked As Solved
Qqwy
There is only one reason to define operators as macros, which is that inside a macro you can find out if it is called as part of a guard clause, or outside of one. So outside of a guard clause you could have fancy logic, while inside a guard clause you could fall back to the built-in operators that work on the built-in data types.
Also Liked
NobbZ
Instead of doing some juggling with the kernel import inside of a single block, you should instead transform the given block by traversing the AST:
defmacro decimal({:+, _, [a, b]}), do: quote do Decimal.add(unquote(a), unquote(b)) end
defmacro decimal({:-, _, [a, b]}), do: quote do Decimal.sub(unquote(a), unquote(b)) end
...
I’m not sure though how well this plays with more complex expressions that have more than a single argument
It might be necessary to deep-traverse the AST to ensure proper transformation.
Besides of that, I think a |> Decimal.add(b) |> Decimal.div(c) reads pretty well. One has to remember that operations are applied left to right this way and one has to sort them.
Qqwy
You might like the Numbers library, which allows you to work with any numeric types, as well as automatically converting integer and float arguments to the Decimal type when the other argument is one, which removes the Decimal.new(x) clutter:
alias Numbers, as: N
distance = N.div(price, order_price)
multiplier = 0.2
sale = N.add(price, N.mult(price, multiplier))
Numbers on purpose does not export overloaded operators (but might do so in an explicit opt-in way in the near future).
EDIT: The new version 5.1.0 Has support for exporting overloaded operators as well.
Overbryd
Thank you all for the insightful replies. I learned a lot today.








