1391094 - parseInt(200/604800000)==3?

Status: RESOLVED INVALID

(Invalid Bugs :: General, defect)

Description

[Jim Michaels]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170809080026

Steps to reproduce:

in console or js run:
parseInt(200/604800000)
3
200/604800000
3.306878306878307e-7


Actual results:

wrong number, should be 0. for some reason, parseInt took the leftmost digit of a float and returned it even though the exponent is -7.


Expected results:

should have returned 0.

Comment 1

[Jim Michaels]

this bug is in opera as well, so may be in spec.

Comment 2

[Tooru Fujisawa [:arai]]

parseInt receives string as the first argument, and stops parsing at '.',
so whether it has "e-7" at the end or not doesn't matter.
https://tc39.github.io/ecma262/#sec-parseint-string-radix

if you want to parse such syntax, you need parseFloat instead.

Comment 3

[Tooru Fujisawa [:arai]]

or perhaps what you need might be just Math.{round,floor,ceil}

Comment 4

[Jim Michaels]

no, parseInt used to correctly convert floating point to an integer. correct result is 0. this is all wrong. that behavior breaks a LOT of old code.

the correct behavior for floating point I think looked something like:
function parseInt(floatingPointValue) {
if (typeof(floatingPointValue)=="string") convert string to number;
if (floatingPointValue>Math.pow(2,53)) return NaN;
if (floatingPointValue>=0&&floatingPointValue<1) return 0;//[0..1)
if (floatingPointValue>=-1&&floatingPointValue<0) return -1;//[-1..0)
return INT(floatingPointValue);
}

Comment 5

[Jim Michaels]

the spec is broken.

Comment 6

[Jim Michaels]

by the way, ceil and round does not replace an integerize function like parseInt(), which is suppose to "leave off everything past the decimal point." so to speak. technically that cannot be done as a correct measure for an INT() function. C++ does not do the spec method when you perform a type conversion to int using int(double). maybe it should be bought/permissioned. I don't know how they lost its goodness.

I am going to leave off of this until it gets fixed.

Comment 7

[Jim Michaels]

I must say, I used the words myself "everything past the decimal point" regarding parseInt, and someone implemented it, now I feel bad because that's not the algorithm. and it's still broken in current stable ff.
I do not know exactly what the correct algorithm is, but it can be thought out. and an older spec had the correct algorithm - the one used 2 months ago at least, before all the code breakage it's causing.

if someone is using integers for fixed point e-commerce like I think, it would be a very notable bug. thank you for fixing the bug.

Comment 8

[Jim Michaels]

Math.floor always returns input-1 or input as integer. 
Math.ceil always returns input+1 or input as integer.
these are not to be confused with parseInt(), which are the *only* int() (integerize) function that simply drops non-integer parts. just to make this clear. not sure what parseInt used to do with something > mantissa size though. I think it simply returned the floating point number at that point (anything over about 2^53).

Comment 9

[Jan de Mooij [:jandem]]

(In reply to Jim Michaels from comment #7)
> an older spec had the correct algorithm - the one used 2 months ago
> at least, before all the code breakage it's causing.

parseInt behavior has not changed for years, at least when it comes to this.

(In reply to Jim Michaels from comment #5)
> the spec is broken.

Maybe it is, maybe it's not. There are a lot of things in the spec that are not great, but we do have to implement the spec, so Bugzilla is really not the right place to discuss this. We've told you this before.