back to the lesson

## Why 6.35.toFixed(1) == 6.3?

importance: 4

According to the documentation `Math.round` and `toFixed` both round to the nearest number: `0..4` lead down while `5..9` lead up.

For instance:

``alert( 1.35.toFixed(1) ); // 1.4``

In the similar example below, why is `6.35` rounded to `6.3`, not `6.4`?

``alert( 6.35.toFixed(1) ); // 6.3``

How to round `6.35` the right way?

Internally the decimal fraction `6.35` is an endless binary. As always in such cases, it is stored with a precision loss.

Let’s see:

``alert( 6.35.toFixed(20) ); // 6.34999999999999964473``

The precision loss can cause both increase and decrease of a number. In this particular case the number becomes a tiny bit less, that’s why it rounded down.

And what’s for `1.35`?

``alert( 1.35.toFixed(20) ); // 1.35000000000000008882``

Here the precision loss made the number a little bit greater, so it rounded up.

How can we fix the problem with `6.35` if we want it to be rounded the right way?

We should bring it closer to an integer prior to rounding:

``alert( (6.35 * 10).toFixed(20) ); // 63.50000000000000000000``

Note that `63.5` has no precision loss at all. That’s because the decimal part `0.5` is actually `1/2`. Fractions divided by powers of `2` are exactly represented in the binary system, now we can round it:

``alert( Math.round(6.35 * 10) / 10 ); // 6.35 -> 63.5 -> 64(rounded) -> 6.4``