By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
 428,839 Members | 2,270 Online + Ask a Question
Need help? Post your question and get tips & solutions from a community of 428,839 IT Pros & Developers. It's quick & easy.

# is there a JS equivelent

 P: n/a of "int" in VB? //b=1.2 b=int(b) //b now equals 1 Sep 16 '06 #1
Share this Question
10 Replies

 P: n/a 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 Sep 16 '06 #2

 P: n/a 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 Sep 16 '06 #3

 P: n/a 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)". Sep 16 '06 #4

 P: n/a 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 disregardedalso:window.alert( Math.floor(i) ) // 1, integer smaller than 1.2window.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. Sep 16 '06 #5

 P: n/a 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 disregardedalso:window.alert( Math.floor(i) ) // 1, integer smaller than 1.2window.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 Sep 16 '06 #6

 P: n/a 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?": Especially see the excellent summary by Lasse Reichstein Nielsen: (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. Sep 17 '06 #7

 P: n/a VK wrote: Richard Cornford wrote: >Because it converts numeric arguments to strings and thenparses those strings - parseInt - can produce very wrongresults with numbers that would have exponented stringrepresentations. For example:-parseInt(0.00000025);- returns 2 when zero is really the nearest integer value.Its use in this role may introduce intermittent chaoticeffects in scripts. Math.floor looks like the nearestnative 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?": 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. Sep 17 '06 #8

 P: n/a Thanks for your replies, help appreciated. Dave Sep 17 '06 #9

 P: n/a Trond Michelsen wrote: Richard Cornford wrote: >Because it converts numeric arguments to strings and thenparses those strings - parseInt - can produce very wrongresults with numbers that would have exponented stringrepresentations. For example:-parseInt(0.00000025);- returns 2 when zero is really the nearest integer value.Its use in this role may introduce intermittent chaoticeffects 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 ofVBScript'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. Sep 17 '06 #10

 P: n/a JRS: In article , dated Sat, 16 Sep 2006 11:01:54 remote, seen in news:comp.lang.javascript, Dave Cox 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 © ? JL/RC: FAQ of news:comp.lang.javascript

### This discussion thread is closed

Replies have been disabled for this discussion. 