This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
see http://mysite.verizon.net/aesir_research/date/jdalg2.htm Reason: many times doing calculations, there exists a need to get just the integer portion of the number with no fractional digits. essentially, they need to be lopped off (truncated). .toFixed() does not do this because it rounds. Math.floor() and Math.ceiling() do not quite do this because they have special semantics on this that do not make this an exact replacement (such as when you get to negative numbers it acts different). when negative numbers are used, the sign should be carried through. I was going to submit a request for Math.fmod() or Math.frac() but there is already the % operator which works quite well for that. if the intention is to have Java-like functionality and libraries, then please supply the equivalent Java methods. I have tried parseInt(), but it does not properly handle floating point numbers like one thinks it should. you get errors or garbage for results. example: Math.int(1.2345) should return 1 Math.int(1.9876) should return 1 Math.int(-1.2345) should return -1 Math.int(-1.9876) should return -1
interesting case would be for floats that are over the size of Int32. perhaps this should just perform an internal ToInt32 abstract operation as outlined in ecma-262 5.1 section 9.5 just to make this simpler. or,if the float is known to have a decimal point and the exponent and number of decimal places in the mantissa turn out to have the equivalent of digits toi the right of the decimal point were it written out by hand without an exponent, those digits should be truncated in the mantissa. it might just be better to do this the hard way so that any floating point number will work. my understanding is that the built-in abstract type Int32 is not the smallest size integer that javascript can handle. it can currently handle about 2^53 as an upper limit. so doing it the hard way will produce better benefits and you can handle larger numbers, for calculating millisecond resolution time libraries, and things like that.
you can cancel this bug. it turns out that whatever (?) misfunctionalities I found may have been because of a corrupted firefox profile :-/ this seems to happen every month. I did some unit tests after a profile reset with opera, chrome, IE8, firefox 19 and came up with that parseInt() seems to have the correct functionality needed. perhaps whatever bugs I was facing were simply fixed? whatever the case,it's good now it seems. http://Jesusnjim.com/test/parseInt-parseFloat-bulletproof-test.html