O_o… that is very odd indeed. I would expect any function named compare to indeed return integers, similar to for instance the UFO-operator that Rubyists might be familiar with.
I actually think that a built-in Decimal datatype would be a great addition to both Elixir and Erlang.
The current way that > works with the Decimal Struct is just a side effect of the implementation of Maps. Below a certain number of entries the order of Map.keys is fixed, above that it can vary since the underlying implementation switches and Map.keys no longer returns a fixed order.
FWIW, this is a place where I think Structs are a suboptimal solution. With something this small a tuple would make more sense and with some care in construction would work “better” with normal Erlang/Elixir operators.
I guess the intent is to make a data type that can be used for money.
Having complete comparison over all terms is actually a very nice feature that allows us to implement data structures such as ordered dictionaries very easily.
We could implement such functions if we could access map keys in guards.
It wouldn’t work because of the exponent unfortunately.
Not sure I understand. Why would you expect compare/2 to return integers but not cmp/2? The reason compare/2 returns a Decimal is mostly because the library follows the IEEE754 specification.
Can you show how it would work better with tuples? One of the reasons it’s a struct is because we can implement protocols for it so it works with JSON encoding, inspecting, converting to string and so on.
I’m probably speaking out of turn, I was only considering the comparability aspect.
But if it was a simple tuple of say { sign, exponent, coefficient } then the Erlang comparision operators would “work” for at least positive numbers and it should be possible to design the tuple so it works for all numbers.
I’d have to dig much deeper into Decimal to know if this tradeoff makes any sense in the larger context of all the things Decimal does. A quick look suggests my assumptions about what the library actually does may be wrong.
I did some more looking and thinking and using Tuples for Decimal to enable “<” use would only work if you always normalize the coefficient and somehow put leading zeros in front of it.
You could add a number one order of magnitude larger than the specified precision to fake this, but that would complicate all the rest of the operators.
Another approach would be to use actual binaries for the coefficient, but that also adds a lot of
complexity.
Aha! I had not considered that. Thank you, I’ve been wondering about the actual reasoning behind the ‘all things are comparable’ in Erlang for a very long time. 
Yes, you’re right. I had not considered that (1 * 10^3) < (123 * 10^1)
If you follow the IEEE specification, then it makes sense to return Decimals there. It is just that I would expect comparing functions (like compare/2 or cmp/2) to be used in checks like check if a is larger or equal to b. compare(a, b) >= 0. Of course this no different from checking if b is strictly smaller than a, but depending on the context it is often more readable to use a x >= y over a y < x or a x <= y over a y > x.
So that would be a reason for a comparing function to return integers instead of decimals or symbols. Of course, if a library were to offer functions like lte?(a, b), that is a great way too.
Oh, and let me just say that I really like the Decimal library 
FWIW, I’ve come up with a basic tuple implementation for Decimal-like library that does work with “<”. It’s about as complex as I expected although the trick is to fiddle the exponent, not the mantissa or significand.
Can someone explain the problem Decimal is meant to solve that isn’t solved by float? Or just exactly what the use case is for Decimal?
I understand that it can do things float can not, I’m just trying to grasp the itch this library scratches. I think you could tweak it such that < would work, but the data structure I have come
up with is heavily dependent on the precision requested.
Would doing that break the entire purpose of the library?
My guess is that it’s important that the data structure represent the number w/o additional context provided by Decimal in the process table. The representation I have come up with has the precision as a deductible fact, but it’s tricky to work with items that were build with different notions of precision.
All right. This is a very important piece of knowledge and in my opinion it should be included in the Computing Science 101.
Try the following calculation in any programming language (all non-archaic languages follow the IEEE 754 floating point standard): 2.3 - 0.3. Is the answer what you would expect?
The problem with floating-point numbers is that we are trying to save an arbitrary number with a radix point in a fixed-size binary representation. If you type the float 7.1, what is stored is not 7.1. It actually is ± 7.099999999999999644728632119949907064437866210937500000000000. If you want to see it for yourself, try: :erlang.float_to_binary(7.1, decimals: 60). These inaccuracies become even more defined when dealing with large numbers, because then the amount of possible binary numbers between two whole numbers becomes a lot smaller. There even is a point where whole numbers are rounded, because they are less significant than the rounding issue.
Compare :erlang.float_to_binary(12345678987654321.0, decimals: 1) with :erlang.float_to_binary(12345678987654321.1, decimals: 1). (Actually, the rounding error is so prevalent here, you can just check IEx default output instead)
Another example: (0..10) |> Enum.reduce(fn x, acc -> acc + 0.1 end).
When we do arithmetic operations with floats, these inaccuracies amplify. This is fine for calculations where we are working with external measurements that are imprecise by definition, or difficult mathematical equations that we can only approximate. It is however a problem when we are working with a known, exact, decimal amount, such as when we are counting something. A good example: Money.
These rounding issues have made money disappear in the past. Please use decimals when dealing with money.
If you want to read more about this, there is a great explanation in the Python documentation (while the syntax is in Python, the examples are true for all other programming languages). There also is What every Computing Scientist should now about Floating Point, which is a very juicy article with a lot of details.
