Why does JavaScript's parseInt(0.0000005) print "5"?

Question

I've read an article about JavaScript parseInt, which had this question:

parseInt(0.5);      // => 0
parseInt(0.05);     // => 0
parseInt(0.005);    // => 0
parseInt(0.0005);   // => 0
parseInt(0.00005);  // => 0
parseInt(0.000005); // => 0

parseInt(0.0000005); // => 5

Why is this happening?

Solution 1

I've searched about it on ecmascript standard, and saw this:

The first step is converting the input to `string` if it is not:

19.2.5 parseInt ( string, radix )

The parseInt function is the %parseInt% intrinsic object. When the parseInt function is called, the following steps are taken:

1. Let inputString be ? ToString(string).
2. Let S be ! TrimString(inputString, start).

...

So, I've checked the values on string-based using String function to see what is the output for each of them:

String(0.5);      // => '0.5'
String(0.05);     // => '0.05'
String(0.005);    // => '0.005'
String(0.0005);   // => '0.0005' 
String(0.00005);  // => '0.00005'
String(0.000005); // => '0.000005'

String(0.0000005); // => '5e-7'

So, it means when we use parseInt(0.0000005), it is equal to parseInt('5e-7') and based on the definition:

parseInt may interpret only a leading portion of string as an integer value; it ignores any code units that cannot be interpreted as part of the notation of an integer, and no indication is given that any such code units were ignored.

So the answer will return 5 only because it is the only character which is a number till a noncharacter e, so the rest of it e-7 will be discarded.

Solution 2

(This is more of a long comment rather than a competing answer.)

The unwanted conversion leading to this weird effect only happens when passing the value to parseInt as a number type - in this case it appears that the compiler (or interpreter or whatever drives JS) auto-converts the number into a string for you, as the string type is the expected type of the function parameter

That number-to-string conversion function, unfortunately, prefers the engineering number format when it would get too long otherwise.

Also, the conversion may lead to loss of precision, which is something every programmer has to be aware of whenever dealing with decimal (non-integer) numbers.

If you instead remember to place the to-be-parsed value into a string yourself, then you'll not get such unexpected results:

let n = '0.0000005';
console.log(parseInt(n))

Will print 0 as desired.

Lessons learned:

• Avoid implicit type conversion wherever you can.
• Avoid parseInt and similar functions that do not let you know if the string to be parsed has extra non-fitting data. E.g, int-parsing "x" or "1x" should both tell you that this is not a proper int number. In this regard, parseInt exhibits bad behavior by ignoring extra data in the string and not telling us. A good parser function either tells you where it stopped (so that you can check if there's garbage left over) or fails when it finds unexpected data.

Comments

[jcalz]

Somewhere in this question and answer should probably be strongly worded advice not to parseInt(x) for x that isn’t a string. If you already have a number presumably you want Math.round() or Math.floor() or something. The example here shows that it’s essentially just luck that you often get reasonable looking output.

[Ingo Steinke]

While ESLint does not complain, at least PhpStorm (which is also useful for JavaScript and TypeScript) warns that a number is not assignable as a String parameter).

[Alex Klaus]

It's an example of the usual fallacy of not checking the type of input values. This and other examples of implicit string conversion are covered here - alex-klaus.com/javascript-wat