VK wrote:

Richard Cornford wrote:
>Because it converts numeric arguments to strings and then

parses those strings - parseInt - can produce very wrong

results with numbers that would have exponented string

representations. For example:-

parseInt(0.00000025);

- returns 2 when zero is really the nearest integer value.

Its use in this role may introduce intermittent chaotic

effects in scripts. Math.floor looks like the nearest

native equivalent of VBScript's Int function.

var n = 9007199254740993.1;

alert(Math.floor(n)); // 9007199254740994

alert(n);

- also shows 9007199254740994, so the Math.floor method is not altering

a number that is already an integer when it is passed in.

// "intermittent chaotic effects" !! :-)

A discrepancy of 1 in 9007199254740994 is hardly going to produce

results nearly as chaotic as a discrepancy of 20+ orders of magnitude,

as - parseInt - produces.

var n = 1000000000000000000000;

alert(parseInt(n));

- alerts 1, not even close to the original value.

The matter is not about some particular method,

What is up, embarrassed by giving obviously bad advice again? You should

expect that by now as not knowing what you are doing will result in

that.

but about of how are numbers represented internally

and about IEEE floating point numbers presicion limits.

Beyond a certain point (two to the power of 53) javascript numbers

cannot represent all integers, and so specific integers can only be

represented by the closes approximation. Those approximations are small

in comparison to the magnitude of the numbers and anyone trying to work

with numbers of that size will encounter precision related issues

whatever they do.

What happens around zero is much more significant. Zero is more likely

to be in the range that is of interest and with all floating point

numbers being held as their nearest representable form addition and

subtraction of fractional values that may have been expected to produce

results that are zero may actually have produced results that are just

very close to zero. The - parseInt - fiction will produce very wrong

results in this significant area.

So using - parseInt - in, for example, an animation; an element may

approach a point smoothly, jump away by up to 9 pixels when it should be

at that point, and then smoothly carry on once it has passed that point,

and it may only do that when a set of variable (such as browser size)

have very particular values. An intermittently chaotic outcome that

would be difficult to spot and so an easy mistake to make for someone

who does not fully appreciate the interaction of the mechanism of -

parseInt - with the nature of the javascript number type.

See a very informative thread "How are JS numbers

represented internally?":

<snip>

When you say "informative", and baring in mind that you read that some

time ago (plus the many other threads trying to separate you from your

delusions about the representations of numbers on computer systems in

general and in javascript in particular), are you implying that you were

informed? And if so why "Of course only parseInt(n,10) is pretty much

what CInt() does in VB"? (Which combines not being true itself, not

being the question asked and not being a good answer to the question

asked)

Richard.