Destructuring Tweets - Episode 4 - Summing Up
Tags: snippet, javascript, destructuring, bicimal
Published: 2021-01-24 13:14:13

---
title: Destructuring Tweets - Episode 4 - Summing Up
published: true
description: I pick a more or less random snippet from Twitter and analyze it in depth in this series. It shall help me, and you understand the trickery behind it. This episode features decimal number behavior in JavaScript.
tags: snippet, javascript, destructuring, bicimal
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/dmtyewanx89ctjs7o5ur.png
---
Good Sunday, welcome to my series about destructuring one of those frequently shared JavaScript quizzes on Twitter. Welcome to the fourth episode!

# Snippet of the Week

This week's [snippet](https://twitter.com/nachoiacovino/status/1340989049415327744) is from [Nacho Iacovino](https://twitter.com/nachoiacovino):
```javascript
console.log(0.1 + 0.2);
console.log(0.1 + 0.2 == 3);
console.log(0.1 + 0.2 === 3);
```
What we have here seems to be relatively simple at first glance. The author creates three console logs. The first featuring an addition of 0.1 and 0.2, the second and third compare this addition to 0.3 with two different operators.
The first operator `==` is called "Equal", the second `===` "Strict Equal". Both return a boolean value, indicating whether the first and second statement is the same. So, a `console.log` either outputs `true` or `false`.

# The Output

Well, the output is easy here, isn't it? It should be:
- `0.3`
- `true`
- `true`

Welp, surprisingly enough, none of these is correct!
It's actually:
- `0.30000000000000004`
- `false`
- `false`

The two falses are evident in that context. Since the first output is this odd (pun intended) number, the addition is indeed *not* equal to `0.3`.
We end up with the fundamental question: why the hell `0.1 + 0.2` equals `0.30000000000000004`?

# Analysis

For that question to answer, we need to know that computers need to cut off decimal numbers at some point. Given two floating-point numbers, JavaScript tries to return the same.
Now, let's stay in the decimal (digits from 0 to 9). How'd you expect a computer to comprehend the number ⅓? It can't just think about it as a repeating decimal and note it down as one. What you need to do at one point is to cut it off. The last digit gets rounded, and that's it.
As you may already know, computers work in binary (digits from 0 to 1). Of course, the same problem exists there! Let's write down 0.1 in binary:
0.0001100110011001100110011... 
Notice how "0011" repeats itself over and over again? That's exactly the issue here. JavaScript reserves 52 bits for the fraction, and after that, the number gets cut off and rounded. That's where it gets slightly higher than 0.1. 
Mathematical evidence is beyond my article's scope, but I will add a link with detailed information on that.

# Snippet Summary
- **Trickery**: Floating-point math and bicimals
- **Key Learning**: Floating-point numbers are not reliable when used without additional proofing
- **Further Reading**:
    - [The two number types of JavaScript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures#number_type)
    - [Mathematical evidence](https://www.exploringbinary.com/why-0-point-1-does-not-exist-in-floating-point/)
    - [`toFixed` is a possible API to overcome these issues](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/toFixed)
    - [Double Precision Binary Floating Point Format as used by JavaScript numbers](https://www.wikiwand.com/en/Double-precision_floating-point_format#/IEEE_754_double-precision_binary_floating-point_format:_binary64)