# [erlang-questions] strictly less-than (Re: [erlang-questions] Ordered set and DETS)

Pascal Chapier pascalchapier@REDACTED
Fri Sep 10 20:05:23 CEST 2010

```I didn't know that float appears lately in Erlang.

It should be the reason why we have this weird type of number.

Integer is a mathematical group with a pretty good representation in Erlang where there is no size limit.
+, - and * are defined in that group, and the Erlang algorithms are consistent with the mathematical operations.

Float is nothing but a subset of the rational numbers. In this subset, there is no guarantee that the result of a
mathematical addition between 2 float is a float. IEEE gives the rules to round the math result to the closest float.

IEEE +, -, *, / are perfectly defined functions, but they have not the properties of their math counterpart:

1> Y = 1.7e308.
1.7e308
2> W = -Y.
-1.7e308
3> D = 9.975e291 .
9.975e291
4> Y =:= Y + D.
true   %% Hummm !
5> (Y + D*1.1) - Y  .
1.99584030953472e292
6> ((Y + D*1.1) - Y) > 2*D .
true   %% i.e. D*1.1 > 2*D with D > 0.0 !
7> (D+Y)+W.
0.0                 %% really ?
8> D+(Y+W).
9.975e291  %% very good, but different!
9>

In these examples, all variable are floats, this shows that one must be aware of the float representation when using them.
Mixing floats with integer, complex calculation, FPU internal representation and code implementation can even create a bigger mess.
In real life, this kind of problem is not likely to occur, because we generally use float in a small range, far from the maximum value,
and we are generally not interested in very very small values - except 0.0 (on my side I change unit if the values I am using are smaller
than 1/1000 or bigger than 10000).
Nevertheless, the smallest relative difference between two float is around 10e-16 (in 64bits), and this is sometime a problem.

I wrote a small 3D simulation program as a hobby. The float were very useful, but I had to write my own operators for <, > and ==,
based on a global value NEAR, which define a relative limit where float representation is not relevant, knowing my problem and the algorithms I use.

My conclusion is that it is a bad idea to compare floats, a worse idea to check their equality, and an error to mix integers and floats is such operations,
using only implicit conversion and standard IEEE operations. The same conclusion applies to pattern matching.

I think that it is a good idea to say that the target is to have separate float and integer types, and separate them in Erlang terms comparison.

The problem I see, is that it is not possible to detect at compilation a mix in comparison or operation, and this seems be necessary to have
an intermediate phase where numbers and numbers operations or comparisons have a deprecate status (i.e. operation without explicit conversion).

Is it acceptable to have warnings at run time, and is it feasible to have these warnings controlled by a flag, for backward compatibility?

I am not sure that the problem is enough critical to be worth the creation of new syntax operation or the dynamic check .

Pascal.

```