Inconsistency with compiler warnings upgrading to 1.17

Questions / Help
1

Hello :wave:
I was working on upgrading one of our apps to 1.17 this morning and came across the compiler warning.

pattern matching on 0.0 is equivalent to matching only on +0.0 from Erlang/OTP 27+

This seemed fine and is no problem to patch, in our case if +0.0 is possible technically -0.0 is possible.

iex(1)> 1.0 * 0.0 == +0.0
true
iex(2)> -1.0 * 0.0 == -0.0
true

Since it’s a warning, for a future version, I can understand that +0.0 would match for -0.0

 -1.0 * 0.0 == +0.0
true

However, it will be risky for us to match only on +0.0, for if/when it becomes a requirement.
So we would want to add the matches for -0.0, however

 def format(number) when is_number(number) do
    case number do
     #I've flipped the order on both to test
      -0.0 -> Integer.to_string(number)
      +0.0 -> Integer.to_string(number)
    end
  end

Will generate a compiler warning

  warning: this clause cannot match because a previous clause at line 9 always matches

Outside of ignoring these warnings, would leave us in a place where we can only match on +0.0, and hope the warning remains true for future versions (both +0.0 and -0.0 being matched on +0.0)

Is there a recommended way to tackle this? What will be the expected behaviour from OTP/27 onwards? Should we wait until we upgrade to OTP 27 where we could possibly have different matches?

2

One option would be to match abs(number), which will ensure that 0.0 and -0.0 are treated identically.

The “best” answer ultimately depends on your application; in general, matching floats with == can cause unexpected bugs.

For instance, the dreaded “almost zero but not quite” and the non-associativity of floating-point math:

iex(4)> 1/3.0 - 1/6.0 - 1/6.0
0.0

iex(5)> 1/3.0 - 100.0*(1/600.0) - 1/6.0
-2.7755575615628914e-17

iex(6)> -100.0*(1/600.0) - 1/6.0 + 1/3.0      
-5.551115123125783e-17

The usual approach for dealing with this is to define a “tolerance” around zero that is acceptable - this is strongly application-dependent, so I can’t tell you the right value for your application.

Beware: if you take that route, make sure you’re applying it consistently or you can end up with REALLY weird bugs like this one in Minecraft:

1 Like
3

That’s why I detest floating point

4

The trick to remember is that pattern matching uses ===. == does type coersion between numbers and therefore 0.0 == -0.0 == 0.

Therefore, regardless of the OTP version:

  • if you want to match on any zero, use x == 0
  • If you want to match only on zero floats, use is_float(x) and x == 0
  • To match on positive or negative floating zeroes, do <<x::float>> and check if the first bit it zero. From Erlang/OTP 27, you can match on either +0.0 or -0.0 directly
7 Likes
5

apologies for slight offtopic, but i found this post crazy interesting, especially this part:

(…) for people who are unfamiliar with Erlang:

Like Prolog before us we only have one data type, terms. This means that the language is practically untyped. There are only terms and while you can certainly categorize them if you wish, there are no types in the sense most people use that term.

Functions have a domain over which terms they operate, and going outside their domain results in an exception that’s often analogous to a type error (for example trying to add a list to an integer) which can be mistaken for having traditional types. To make things more confusing, we have functions that can tell you which pre-defined category a term belongs to, like is_atom returning true for all terms that are in the atom space and false for all terms outside of it.

This mixup is so prevalent that even our documentation refers to these pre-defined categories as “types” despite them being nothing more than value spaces, but it’s important to remember that at the end of the day we only have one data type, and that many functions are defined for all terms.

1 Like
6

Thank you! That makes complete sense