Why does parseFloat() in JavaScript produce consisant but unitinutive results?

Question

While providing an answer to a question about adding a method that increments a float value in an html input, I came across what I know is a common issue with IEEE Floating point math. This is an example (with a demo) of what I am seeing:

<input type="text" name="BoqTextBox" id="BoqTextBox" value="0.001" />
<input type="Button" id='AddButton' value="+" />
<script>
  $('#AddButton').on('click', function () {
    var input = $('#BoqTextBox');
    input.val(parseFloat(input.val(), 10) + 1);
  })
</script>

Clicking on the + button, causes the input to increment at first like this (using this converter for IEEE Binary Representations):

                     S|   Exp   |      Mantissa
0.001              //0 0111 0101 000 0011 0001 0010 0110 1111
1.001              //0 0111 1111 000 0000 0010 0000 1100 0101
2.001              //0 1000 0000 000 0000 0001 0000 0110 0010
3.001              //0 1000 0000 100 0000 0001 0000 0110 0010
4.0009999999999994 //0 1000 0001 000 0000 0000 1000 0011 0001
5.0009999999999994 //0 1000 0001 010 0000 0000 1000 0011 0001
6.0009999999999994 //0 1000 0001 100 0000 0000 1000 0011 0001
7.0009999999999994 //0 1000 0001 110 0000 0000 1000 0011 0001
8.001              //0 1000 0010 000 0000 0000 0100 0001 1001
9.001              //0 1000 0010 001 0000 0000 0100 0001 1001
10.001             //0 1000 0010 010 0000 0000 0100 0001 1001
... then predictably like this until ...
15.001             //0 1000 0010 111 0000 0000 0100 0001 1001
16.000999999999998 //0 1000 0011 000 0000 0000 0010 0000 1100
17.000999999999998 //0 1000 0011 000 1000 0000 0010 0000 1100
18.000999999999998 //0 1000 0011 001 0000 0000 0010 0000 1100
19.000999999999998 //0 1000 0011 001 1000 0000 0010 0000 1100
... then predictably like this until ...
31.000999999999998 //0 1000 0011 111 1000 0000 0010 00001100
32.001             //0 1000 0100 000 0000 0000 0001 00000110
33.001             //0 1000 0100 000 0100 0000 0001 00000110
... then predictably like that up to 256 (a power of 8 seemed fitting to test) ...

What I don't yet know is why does this behavior manifest itself at those specific values, and what logical steps can I take to mitigate its effects? Rounding for display purposes while keeping the actual calculated value stored someplace else?

Have you read [What Every Computer Scientist Should Know About Floating-Point Arithmetic](http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html)? — Matt Ball, Mar 22 '13 at 20:07
@JasonSperske The question is about JavaScript/floating point accuracy, not about using a different type/language altogether — Ruan Mendes, Mar 22 '13 at 20:10
@JuanMendes, I'm confused. I didn't mention any other language other than JavaScript (is this about the link to the IEEE converter?) Or was this directed at JanDvorak? — Jason Sperske, Mar 22 '13 at 20:13
Maybe we should add one more [classic blunder to Vizzini's list](http://www.youtube.com/watch?v=U_eZmEiyTo0), never trust a floating point value with more than 4 decimals when IEEE 754 is involved :) — Jason Sperske, Mar 22 '13 at 20:22

score 3 · Accepted Answer · answered Mar 22 '13 at 20:02

3

As you guessed you should print outputs only after rounding them. That behaviour is the result of difference between decimal & binary base numbers, because there are decimal numbers which don't have exact representation in binary format of floating point numbers, and therefore some accuracy is lost when storing it into binary and then reading it again. Floating point numbers are represented in CPU in the form 1.XXXXX...XXXX * 2^P, so from this form you can see that not all decimal numbers have such representation with limited length of XXXXXX...XXX.

answered Mar 22 '13 at 20:02

artahian

2,093
14
17

I'm totally on the same page as you on this, maybe what I was looking for was a bit more in depth look at why the numbers break away at that point and then rejoin (maybe I need to look into what a Mantissa is) – Jason Sperske Mar 22 '13 at 20:16
Mantissa is the part which I have noted by `1.XXXXXX...XXXX`. You can read more at http://kipirvine.com/asm/workbook/floating_tut.htm – artahian Mar 22 '13 at 20:18

Why does parseFloat() in JavaScript produce consisant but unitinutive results?

1 Answers1

Linked