parseInt() and parseFloat(): Can this second assertion ever fail?

Question

I've been using parseInt() and parseFloat() in various contexts for a while now, and I'd like to think I know all the ins and outs of the two. But recently I had a curious thought which I so far haven't been able to definitively work out a proof for.

Consider the following function:

function testProof(strInteger) {
    assert(strInteger === '' + parseInt(strInteger, 10));

    assert(parseInt(strInteger, 10) === parseFloat(strInteger));
}

// Sample calls...
testProof("5");
testProof("109");
testProof("-55");

First we assert that converting the input to an integer and then converting back to a string produces the original string again. This guards against cases where parseInt("100bucks") returns 100, and it also makes sure there is no fractional part that's getting truncated off by the conversion -- we want to make sure that the input is actually a whole number, integer string.

If that succeeds, we then assert that parseInt(..., 10) returns the same value as parseFloat(...).

There are many reasons why the first assert would fail:

Input is not a whole number ("1.5")
Input has leading zeros ("0050")
Input has trailing garbage ("100bucks")
Input is in exponential notation ("1e3"), or it's so large it becomes exponential
Input is not parseable, resulting in NaN
Maybe others?

But here's the question: As long as the first assert passes, can the second assert ever fail? Put another way, if we know ahead of time that the input is an integer inside a string, can parseFloat(...) function as a drop-in replacement for parseInt(..., 10)? (Not saying it's a good replacement... :-P)

score 1 · Accepted Answer · answered Jul 25 '14 at 18:20

1

It actually can fail only with this input:

testProof("NaN");

But if you really know it's an integer, why the test? Also parseFloat can't be a good replacement for parseInt as in lots of cases you don't know if it's really an integer and not a float.

answered Jul 25 '14 at 18:20

Razem

1,421
11
14

Good catch! I never considered trying a literal `"NaN"`. And I agree, this is probably something that shouldn't be done; it's more of a theoretical curiosity seeing if there are edge cases where the two act differently. – smitelli Jul 25 '14 at 18:39
@smitelli Well, they behave differently only when you don't know what's inside of the string. And on the other hand if you are pretty sure it's a stringified integer, it's much easier to just do `+str` or `str * 1`. – Razem Jul 25 '14 at 21:24

score -1 · Answer 2 · answered Jul 25 '14 at 18:24

While I cannot offer a proof, JS has no distinction between an integer and a float. The only difference between parseFloat and parseInt is how they interpret things like decimal points. If the input string is a valid integer in regular notation, though (as the first assertion asserts), they will always result in the same numeric value, which in JS means they are the same type as well.

parseInt() and parseFloat(): Can this second assertion ever fail?

2 Answers2