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

Another problem about javascript number!

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
Share this Question
Share on Google+
10 Replies


P: n/a
VK

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
VK

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

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 <ch****@163.com> 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" <ch****@163.com> 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: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'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 <sc**********@yahoo.com> posted :
Do not mix two very separate things: xxx three1. The biggest number JavaScript engine can handle: that one can be
seen 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 handle
in bitwise operations: this range is given in my previous answer.


--
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.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> 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

This discussion thread is closed

Replies have been disabled for this discussion.