424,986 Members | 1,944 Online Need help? Post your question and get tips & solutions from a community of 424,986 IT Pros & Developers. It's quick & easy.

 P: n/a code1:var x=0xf0000000; alert(x); output:4026531840 code2:var b=0xf<<28; alert(b); output:-268435456 I have such above codes , how can code2 output the same as code1?! Jan 22 '06 #1
10 Replies

 P: n/a chanma wrote: code1:var x=0xf0000000; alert(x); output:4026531840 code2:var b=0xf<<28; alert(b); output:-268435456 I have such above codes , how can code2 output the same as code1?! You can't (by regular official means). That's going to be someone after me probably to layout all details, you just remember that your range for such operations is from -2147483648 to 2147483647 (sorry, but try to be happy with that you have :-) Jan 22 '06 #2

 P: n/a >code1:var x=0xf0000000; alert(x); output:4026531840 But these code actually output 4026531840; this prove that the JS engine sometimes interprets one num to an unsigned one,but sometimes as my code2,interprets it to an signed one.Doesn't it seem there be some way to tell JS engine when and how to interpret the code? Jan 22 '06 #3

 P: n/a chanma wrote:code1:var x=0xf0000000; alert(x); output:4026531840 But these code actually output 4026531840; this prove that the JS engine sometimes interprets one num to an unsigned one,but sometimes as my code2,interprets it to an signed one.Doesn't it seem there be some way to tell JS engine when and how to interpret the code? Do not mix two very separate things: 1. The biggest number JavaScript engine can handle: that one can be seen by alert(Number.MAX_VALUE); 2. The lowest / biggest values of 32bit signed integer you can handle in bitwise operations: this range is given in my previous answer. If it is absolutely necessary to implement it for integers out of the supported range, you have to implement your own BigMath library with bitwise operations at the bottom and string concatenation / parsing at the top. Any BigMath is very resource expensive on 32bit machines, this is why for example in Mozilla.org each and every 64bit number leads to a discussion "do we really need it here or can we stay somehow within 32bit". But depending on your actual task the slow down may not be so important. Jan 22 '06 #4

 P: n/a VK wrote: chanma wrote:code1:var x=0xf0000000; alert(x); output:4026531840 But these code actually output 4026531840; this prove that the JS engine sometimes interprets one num to an unsigned one,but sometimes as my code2,interprets it to an signed one.Doesn't it seem there be some way to tell JS engine when and how to interpret the code? Do not mix two very separate things: 1. The biggest number JavaScript engine can handle: that one can be seen by alert(Number.MAX_VALUE); 2. The lowest / biggest values of 32bit signed integer you can handle in bitwise operations: this range is given in my previous answer. If it is absolutely necessary to implement it for integers out of the supported range, you have to implement your own BigMath library with bitwise operations at the bottom and string concatenation / parsing at the top. Any BigMath is very resource expensive on 32bit machines, this is why for example in Mozilla.org each and every 64bit number leads to a discussion "do we really need it here or can we stay somehow within 32bit". But depending on your actual task the slow down may not be so important. A side note: it is funny fut within the range from 0 to 4294967295 (unsigned 32bit integer) you can make right *opposite* to what you're trying to do: by using Unsigned Right Shift operator you can: var v = 0xF0000000; alert(v.toString(2)); alert((v>>>28).toString(2)); But JavaScript doesn't have Unsigned Left Shift nor their circular counterpairs: Circular Unsigned Right Shift / Circular Unsigned Left Shift So with your actual task you are still on your own. Jan 22 '06 #5

 P: n/a On 2006-01-22, chanma wrote: code1:var x=0xf0000000; alert(x); output:4026531840 code2:var b=0xf<<28; alert(b); output:-268435456 I have such above codes , how can code2 output the same as code1?! Bit shifting will limit you to 32 bit numbers (unless you are using a 64 bit cpu/fpu?) with a wrap. In Perl they are unsigned integers (1<<31 comes out as 2147483648) while in Javascript they are signed (1<<31 comes out as -2147483648). In both cases 1<<32 comes out as one. On the other hand, Javascript can handle integers with quite a few digits without loss of accuracy. 1<<28 causes no problems (not quite too large) and b=0xf*(1<<28) comes out as 4026531840. or b=0xf*Math.pow(2,28) which comes out as 4026531840. What out if you force Math.pow to use floating point and not get an exact integer. I was writing a script the other day and came across that. I was looping and shifting a variable, x, by 1 (x<<1) to double it at each run through the loop. Ooops. I changed that to x=x+x to double it and got rid of the problem. Jan 22 '06 #6

 P: n/a "chanma" writes: code1:var x=0xf0000000; alert(x); output:4026531840 But these code actually output 4026531840; this prove that the JS engine sometimes interprets one num to an unsigned one, No. It sometimes (indeed most times) use 64-bit IEEE floating point numbers to represent its number values. It is quite capable of keeping 4026531840 as a positive value. It is always "signed" in the sense of having a sign bit. but sometimes as my code2,interprets it to an signed one. Bitwise operations convert to *signed* 32-bit numbers before operating, and does 32-bit operations, Doesn't it seem there be some way to tell JS engine when and how to interpret the code? Any number you have is a floating point number. 32 bit signed numbers are only used internally in some operations. If your number is negative, add Math.pow(2,32). /L -- Lasse Reichstein Nielsen - lr*@hotpop.com DHTML Death Colors: 'Faith without judgement merely degrades the spirit divine.' Jan 22 '06 #7

 P: n/a chanma wrote: code1:var x=0xf0000000; alert(x); output:4026531840 code2:var b=0xf<<28; alert(b); output:-268435456 I have such above codes , how can code2 output the same as code1?! A possibly unexpected characteristic of javascript is that there is no such thing as a negative numeric literal in the language. When a numeric literal is preceded by a minus sign that minus sign is actually a unary minus operator, with the (exclusively positive) numeric literal as its operand. This is as true for hexadecimal literals as it is for decimal literals. Javascript's single numeric type is an IEEE 754 64 bit double precision floating point number. some operations, particularly bitwise operations, convert the javascript floating point number type into (32 bit and 16 bit) integer types for internal evaluation. The output of these operations can always be precisely represented by the 64 bit double precision number type (its mantissa is longer than 32 bits and its exponent longer than 5), however, the process of converting a floating point number to an integer will modify many numeric values. All fractional parts must be truncated, and numbers with values outside the range that the internal 32/16 bit type is capable of representing must be modified. The language specification defines three operations/function that are used to convert the floating point number type into internal integer representations. They are:- ToInt36 (ECMA 262, 3rd ed. Section 9.5), ToUint32 (Section 9.6) and ToUint16 (section 9.7). ToUint16 is irrelevant to your situation. Your - x = 0xf0000000 - produces a positive numeric value by virtue of the fact that all numeric literals are positive, and no unary minus operation is applied to the value of the numeric literal. Your - b=0xf<<28 - produces a negative result because the left shit (<<) operation uses signed 32 bit integers internally. That is, it applies the internal ToInt32 function to its left hand side operand, shifts that value (which becomes negative because the highest bit is then set) and then converts that value into a double precision number (which is negative as it has the same numeric value as the internally used signed 32 bit value). One of the bitwise operators uses an unsigned 32 value internally (as produced with the ToUint23 function). That operator is the unsigned right shift operator (>>>). This means that you can convert a value that can be precisely represented as a signed 32 bit integer into an equivalent of an unsigned 32 bit integer where the unsigned 32 bit integer would have the same bit pattern as the signed 32 bit integer by applying - x >>> 0 - (unsigned right shift by zero bits). I.E:- code2: var b = (0xf << 28) >>> 0; alert(b); output: 4026531840 But remember that the 32 bit integers employed in javascript are internal intermediate values. The exposed numeric values are all 64 bit double precision floating point numbers. They can represent the same values as 32 bit integers but those values are held in very different bit patterns. Richard. Jan 22 '06 #8

 P: n/a THANKS A LOT! Jan 22 '06 #9

 P: n/a JRS: In article <11**********************@g43g2000cwa.googlegroups .com> , dated Sun, 22 Jan 2006 04:53:51 remote, seen in news:comp.lang.javascript, VK posted : Do not mix two very separate things: xxx three1. The biggest number JavaScript engine can handle: that one can beseen by alert(Number.MAX_VALUE); 1.5. The smallest integer that cannot be stored exactly in a Number, minus one : 2^53. 2. The lowest / biggest values of 32bit signed integer you can handlein bitwise operations: this range is given in my previous answer. -- © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 © JL/RC: FAQ of news:comp.lang.javascript jscr maths, dates, sources. TP/BP/Delphi/jscr/&c, FAQ items, links. Jan 22 '06 #10

 P: n/a Richard Cornford wrote: [...] Your - b=0xf<<28 - produces a negative result because the left shit (<<) operation [...] Why, why, it is not this bad, really ;-) Regards, PointedEars Jan 23 '06 #11 