parseInt() parses number literals with exponent incorrectly

It tries to parse strings to integers. My suspicion is that your floats are first getting casted to strings. Then rather than parsing the whole value then rounding, it uses a character by character parsing function and will stop when it gets to the first decimal point ignoring any decimal places or exponents.

Some examples here http://www.w3schools.com/jsref/jsref_parseint.asp

I think the reason is parseInt converts the passed value to string by calling ToString which will return "-3.67394039744206e-15", then parses it so it will consider -3 and will return it.

The mdn documentation

The parseInt function converts its first argument to a string, parses it, and returns an integer or NaN

parseInt(-3.67394039744206e-15) === -3

The parseInt function expects a string as the first argument. JavaScript will call toString method behind the scene if the argument is not a string. So the expression is evaluated as follows:

(-3.67394039744206e-15).toString()
// "-3.67394039744206e-15"
parseInt("-3.67394039744206e-15")
// -3

-3.67394039744206e-15.toFixed(19) === -3.6739e-15

This expression is parsed as:

• Unary - operator
• The number literal 3.67394039744206e-15
• .toFixed() -- property accessor, property name and function invocation

The way number literals are parsed is described here. Interestingly, +/- are not part of the number literal. So we have:

// property accessor has higher precedence than unary - operator
3.67394039744206e-15.toFixed(19)
// "0.0000000000000036739"
-"0.0000000000000036739"
// -3.6739e-15

Likewise for -3.67394039744206e-15.toFixed(2):

3.67394039744206e-15.toFixed(2)
// "0.00"
-"0.00"
// -0

If the parsed string (stripped of +/- sign) contains any character that is not a radix digit (10 in your case), then a substring is created containing all the other characters before such character discarding those unrecognized characters.

In the case of -3.67394039744206e-15, the conversion starts and the radix is determined as base 10 -> The conversion happens till it encounters '.' which is not a valid character in base 10 - Thus, effectively, the conversion happens for 3 which gives the value 3 and then the sign is applied, thus -3.

For implementation logic - http://www.ecma-international.org/ecma-262/5.1/#sec-15.1.2.2

More Examples -

alert(parseInt("2711e2", 16));
alert(parseInt("2711e2", 10));

TO note:

The radix starts out at base 10.

If the first character is a '0', it switches to base 8.

If the next character is an 'x', it switches to base 16.