is there a JS equivelent

[Dave Cox]

of "int" in VB?

//b=1.2
b=int(b)
//b now equals 1

[VK]

Dave Cox wrote:

is there a JS equivelent of "int" in VB?

var i = 1.2;

window.alert( parseInt(i,10) ); // 1, fractional part is disregarded

also:

window.alert( Math.floor(i) ) // 1, integer smaller than 1.2

window.alert( Math.ceil(i) ) // 2, next integer bigger than 1.2

window.alert( 'i is ' + ((parseInt(i)==i) ? 'integer' : 'fractional') )
// test

[Trond Michelsen]

VK wrote:

Dave Cox wrote:

>is there a JS equivelent of "int" in VB?

var i = 1.2;
window.alert( parseInt(i,10) ); // 1, fractional part is disregarded
also:
window.alert( Math.floor(i) ) // 1, integer smaller than 1.2
window.alert( Math.ceil(i) ) // 2, next integer bigger than 1.2

Uhm. floor() and ceil() are nice functions, but neither of them are
equivialent to int(). parseInt() is a better choice.

--
Trond Michelsen

[VK]

Trond Michelsen wrote:

floor() and ceil() are nice functions, but neither of them are
equivialent to int(). parseInt() is a better choice.

Sorry for possibly being ambiguous.
Of course only parseInt(n,10) is pretty much what CInt() does in VB.
I just wanted to add after that "(see) also (some useful methods for
numbers treatment in relevance to integer/fractional question)".

[Richard Cornford]

Trond Michelsen wrote:

VK wrote:

>Dave Cox wrote:

>>is there a JS equivelent of "int" in VB?

var i = 1.2;
window.alert( parseInt(i,10) ); // 1, fractional part is disregarded
also:
window.alert( Math.floor(i) ) // 1, integer smaller than 1.2
window.alert( Math.ceil(i) ) // 2, next integer bigger than 1.2

Uhm. floor() and ceil() are nice functions,
but neither of them are equivialent to int().

parseInt() is a better choice.

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.

Richard.

[Trond Michelsen]

Richard Cornford wrote:

Trond Michelsen wrote:

>VK wrote:

>>Dave Cox wrote:
is there a JS equivelent of "int" in VB?
var i = 1.2;
window.alert( parseInt(i,10) ); // 1, fractional part is disregarded
also:
window.alert( Math.floor(i) ) // 1, integer smaller than 1.2
window.alert( Math.ceil(i) ) // 2, next integer bigger than 1.2

Uhm. floor() and ceil() are nice functions,
but neither of them are equivialent to int().
parseInt() is a better choice.

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.

Ah. I sorta suspected parseInt() could have some issues, but this one
didn't occur to me. Thanks.

Math.floor looks like the nearest native equivalent of VBScript's Int
function.

Yes, you're right. I thought Math.floor() would only be appropriate if
it's a positive number. But, I should of course have checked how the Int
function actually works in Visual Basic, instead of assuming it behaves
like it does in other languages, like perl or python.

--
Trond Michelsen

[VK]

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
// "intermittent chaotic effects" !! :-)

The matter is not about some particular method, but about of how are
numbers represented internally and about IEEE floating point numbers
presicion limits.

See a very informative thread "How are JS numbers represented
internally?":
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/38d21acb4d4509ce>

Especially see the excellent summary by Lasse Reichstein Nielsen:
<http://groups.google.com/group/comp.lang.javascript/msg/3833df1762d81fee>
(I constructed my "failure case" for Math.floor in one second by using
this summary).

In this aspect I see the job as not fully accomplished yet. That should
be an abandonned practice to describe IEEE presicion issues as some
kind of natural disaster a la earthquake ("A Big One can happen, see
the photos", "It can error out, see the sample" :-)

Instead it should be finally described in terms of IEEE precision
limits with exact "secure borders" given and workarounds for beyond
these borders.

[Richard Cornford]

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.

[Dave Cox]

Thanks for your replies, help appreciated.

Dave

[Richard Cornford]

Trond Michelsen wrote:

Richard Cornford wrote:

<snip>

>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.

Ah. I sorta suspected parseInt() could have some issues,
but this one didn't occur to me. Thanks.

Given the frequency of examples where - parseInt - is used in animation
to 'round' the results of floating point calculations you have to think
that this doesn't occur to many. Probably the aspect that is least
appreciated is that - parseInt - must type-convert its numeric arguments
to strings prior to parsing those strings. This is inevitably a
relatively time consuming so would be rejected by the informed on those
grounds alone, as animation really needs the calculation aspect of the
problem to be as quick as possible if the presentation is to be smooth.

If the range in which the results in known to be smaller than a signed
32 bit integer (as will always be the case in animation as screens do
not yet get bigger than that) and truncation fractional parts is
sufficient 'rounding', then operations that apply the internal -
ToInt32 - function can be the optimum choice. These would be any bitwise
operations (except >>-, which uses ToUint32) such a bitwiser OR and
shift operations.

For quick (4 to 14 times faster than all alternatives) truncating
(towards zero) of integers where the range of the outcome could be
accommodated by a signed 32 bit integer any bitwise operation that would
not alter the value of an integer that was alrady in that range would
do. These include OR zero and right or left shift of zero bits:-

var int = (nFloat | 0);

- or:-

var int = (nFloat << 0);

>Math.floor looks like the nearest native equivalent of
VBScript's Int function.

Yes, you're right. I thought Math.floor() would only be
appropriate if it's a positive number. But, I should of
course have checked how the Int function actually works
in Visual Basic, instead of assuming it behaves like it
does in other languages, like perl or python.

It is an interesting phenomenon that it never occurs to people who come
here to ask about a javascript equivalent of some feature of some other
programming language to state what it is that feature does in that other
language. Even though it should be obvious that all programmers cannot
know all languages and so at lest some will not know the language in
question, but that people who know javascript will know what its
features do and so will be able to match a specification with any
corresponding native feature, or implement an equivalent if it is not
natively available.

Richard.

[Dr John Stockton]

JRS: In article <CQ*****************@newsfe7-win.ntli.net>, dated Sat,
16 Sep 2006 11:01:54 remote, seen in news:comp.lang.javascript, Dave Cox
<da*****@tiscalinotospam.co.ukposted :

>of "int" in VB?

In News, the body of an article should stand independently of its
subject line. Don't assume that other software behaves the same as
yours.

The practical answer for such questions can depend on the range of
argument needed. If the argument can never be negative nor very large,
you are likely to have a wider choice than if you must match a wider
range.

Generally, to get a reliable translation from VB to JS, or between any
other pair of natural or artificial languages, one needs a reasonable
understanding of what is happening in the source language to be sure of
making a sound re-implementation.

It's a good idea to read the newsgroup and its FAQ.
--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/>? JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.