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:

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.