Try this

Decimal.new(-1) > Decimal.new(0) # true

Decimal.new(-1) < Decimal.new(0) # false

Is this the correct way, I’m using Decimal.compare/2 to work but I would like an explanation

Try this

Decimal.new(-1) > Decimal.new(0) # true

Decimal.new(-1) < Decimal.new(0) # false

Is this the correct way, I’m using Decimal.compare/2 to work but I would like an explanation

1 Like

I tried, didn’t work. Could you please elaborate which library you are using?

```
iex(1)> Decimal.new(-1)
** (UndefinedFunctionError) function Decimal.new/1 is undefined (module Decimal is not available)
Decimal.new(-1)
```

1 Like

My assumption would be that `Decimal.new/1`

returns an instance of it’s datatype. Meanwhile `Kernel.>/2`

simply compares this datatype based on some default rules - i.e. it has no idea what the actual **number**/value of a Decimal datatype is. So `Decimal.compare/2`

is the correct way of comparing two Decimals (i.e. don’t think of them as “numbers”).

Looking at the source: `decimal.ex`

line 714

```
def new(int) when is_integer(int),
do: %Decimal{sign: (if int < 0, do: -1, else: 1), coef: Kernel.abs(int)}
```

```
defmodule Decimal do
...
defstruct [sign: 1, coef: 0, exp: 0]
```

Structs are bare maps underneath

So `Kernel.>/2`

is comparing two maps - not two decimal values.

2 Likes

I’m in a phoenix project

```
defp deps do
[{:phoenix, "~> 1.2.0-rc.0"},
{:postgrex, ">= 0.11.1"},
{:phoenix_pubsub, "~> 1.0.0-rc"},
{:phoenix_ecto, "~> 3.0-rc.0"},
{:phoenix_html, "~> 2.5.1"},
{:phoenix_live_reload, "~> 1.0", only: :dev},
{:gettext, "~> 0.11"},
{:cowboy, "~> 1.0"},
{:poison, "~> 2.1", override: true}, #{:poison, "~> 1.5"},
{:comeonin, "~> 2.4.0"},
{:guardian, "~> 0.10.1"},
{:credo, "~> 0.3", only: [:dev, :test]},
{:ex_machina, "~> 1.0.0-beta.1", github: "thoughtbot/ex_machina", only: :test}
]
end
```

1 Like

Then the module `Decimal`

is propably from package `decimal`

, which is a dependenciy of o`postgrex`

and `phoenix_ecto`

.

And in fact, the `new/1`

function of that module is returning a struct, which again are implemented using erlang maps.

Erlang does describe the comparison of a map like this:

So after we already know the definition of `Decimal.new/1`

is `def new(int) when is_integer(int), do: %Decimal{sign: (if int < 0, do: -1, else: 1), coef: Kernel.abs(int)}`

, we can also tell that we will get the following maps back:

`Decimal.new(-1) #=> %{__struct__: Decimal, sign: -1, coef: 1, exp: 0}`

`Decimal.new(0) #=> %{__struct__: Decimal, sign: 0, coef: 0, exp: 0}`

Now comparing them:

- Ordered by size: They have the same size
- Ordered by keys: the keys are the same
- Ordered by values (comapred in order
`[:__struct__, :coef, :exp, :sign]`

) -
`__struct__`

: equal! -
`:coef`

: Comparing 1 and 0, BEAM comes to the conclusion that 1 is greater than 0 and will return an appropriate answer to your question. - It does not care anymore for
`:exp`

and`:sign`

4 Likes

Your assumption is correct.

The Decimal library that is used by Ecto (see it for yourself using `mix deps.tree`

) represents decimals as Structs.

Internally, structs are represented as maps. The comparison operators work, for historical reasons, for all basic datatypes. (Even comparing different datatypes with each other is supported, i.e. comparing a number to a list or a tuple to a map. For the curious: `number < atom < reference < fun < port < pid < tuple < map < list < bit string`

)

This is an (arguably ugly) implementation detail of Erlang. Code we write using a data type from some library should not care about the internal structure of that data type, i.e. we should treat it as a ‘black box’ (this improves code decoupling).

However, as a Decimal is supposed to be a number, it would be nice to compare it to all other kinds of numbers. But here another (arguably ugly) internal implementation detail of Erlang comes up: Operators like `>`

are allowed inside Guard clauses, but only since they are on a very small white-list of ‘guard-safe built-in functions’. When we redefine `>`

, this is no longer possible.

This is the reason that libraries like Decimal and Timex use functions like `*.compare/2`

instead of `>`

and `<`

for comparisons. I really hope that this will change in the future (for instance, if Erlang introduces guard-safe short-circuiting boolean-logic operators we could build many custom guard-safe operators), as it feels very Java-esque to me.

**Tl;Dr:** For the time being, you’ll have to use `*.compare/2`

to compare custom data types.

4 Likes

Wow thanks a lot you really care!!

2 Likes

@Nobbz Interesting! This would suggest that if we reorder the Struct fields in Decimal, we could make the comparison operators work:

```
defmodule EpicDecimal do
defstruct "1sign": 0, "2exp": 0, "3coef": 0
end
x = %EpicDecimal{"3coef": 0}
y = %EpicDecimal{"3coef": 3}
z = %EpicDecimal{"3coef": 3, "1sign": -1}
z < x && x < y
```

But this is probably a horrible idea for some other reasons ^^’. *(one thing I can think of is, because the sign is separate, that -0 < 0, which should be equal)*

1 Like

If you are comparing `Decimal`

s to `Decimal`

s that would really work yes, but `Decimal.new(1) < 0`

would still return false, since integer is always greater than a map…

2 Likes

It took me a bit by surprise that `Decimal.compare/2`

returns `Decimal<-1>`

, `Decimal<0>`

, or `Decimal<1>`

. I guess it makes sense that you want to stay within the same domain and you view `compare`

as `sgn(a - b)`

(Sign function). However coming from other languages one might be primed to expect `integer`

`-1`

, `0`

, or `1`

.

Using `Decimal.cmp/2`

returning `:lt`

, `:eq`

, or `:gt`

may actually be clearer.

2 Likes

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.

1 Like

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.

4 Likes

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.

4 Likes

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.

1 Like

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.

2 Likes

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)`

ericmj:

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.

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

1 Like

Recently I wrote simple, experimental library which makes dealing with Decimal library a bit easier. It is only a thin wrapper so the actual calculations are made by Decimal anyway.

1 Like

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.

1 Like

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.

1 Like