1>>x behaviour

[Vivien Parlat]

Hello,

I have a little question about operator >> between integers: does
anyone know why, when I write:
"1 >> x", the returned value is 1 for all values multiple of 32 and 0
else (this does not hurt me, 1 does).
When I do the same thing with : "1L >> x", only multiples of 64 do
this.
I thought 0 was the only possible result for any x > 0.
Why is it not the case ? And how to correct this simply -- in one
instruction, else I did it by:

long longFoo = intBar;
longFoo >>= x;
return (int) longFoo;

.... but this looks weird to do this.

Thanks in advance to any answer.

 

[Morten Wennevik]

Hi Vivien,

The shift operation is done using the lowest 5 bits of the x operand for
Int32, and lowest 6 bits for Int64.

1 >> 32 is the same as 1 >> 0

 

[Jay]

So is that a bug?

Hi Vivien,

The shift operation is done using the lowest 5 bits of the x operand for
Int32, and lowest 6 bits for Int64.

1 >> 32 is the same as 1 >> 0

 

[Morten Wennevik]

So is that a bug?

It's by design. When you think about it, shifting a 32 bit integer with
anything more than 31 places doesn't make any sense.

http://msdn2.microsoft.com/en-us/library/xt18et0d.aspx

 

[garyusenet]

What does shift do? I read this thread and was intrigued but don't
understand it's use.
I am just learning the basics.

Please advise.

 

[Marc Gravell]

But there is an oddity here;

shifting by 5 and then by 7 is equivalent to shifting by 12
shifting by 16 and then by 16 would leave nothing; yet shifting by 32 in one
go doesn't always...

Intriguing, but not a huge problem generally...

Marc

 

[Marc Gravell]

In brief, it works on the bitwise representation of a value, and moves
everything left or right by {x} places, dropping bits off one end, and
back-filling with 0s at the other.

e.g. integer 1 in binary is ...00001 (=int 1); left shift gives ...00010
(=int 2); right shift this twice yields ...00000 (=int 0)

http://msdn.microsoft.com/library/d.../en-us/csref/html/vclrfrightshiftoperator.asp

Marc

 

[Morten Wennevik]

Hi,

Shifting is used when you need information at bitlevel

Consider the number 68437143. In the file it would be represented as

00000100 00010100 01000100 10010111

Hidden inside is the dimensions of an image where the information is
arranged as

0000 010000 01010001000 10010010111
Unused Colors Width Height
4 6 11 11

To be able to get this information we need to do bit manipulation
By filtering the number with 2047 we get the lower 11 bits

00000100000101000100010010010111 (68437143)
&
00000000000000000000011111111111 (2047)
=
00000000000000000000010010010111 (1175)

int n = 68437143;
int filter = 2047
int Height = n & filter; // 1175


To get Width we shift the bits 11 places to the right

00000100000101000100010010010111 (68437143)00000000000000001000001010001000 (33416) 10010010111 has been pushed out

[Code]
n = n >> 11;

Do the same filtering to get the Width

00000000000000001000001010001000 (33416)
&
00000000000000000000011111111111 (2047)
=
00000000000000000000001010001000 (648)

Shift right 11 more places

00000000000000001000001010001000 (33416)00000000000000000000000000010000 (16)



Summarized in code it will look like

int number = 68437143;
int filter = 2047;
int height = number & filter;
number = number >> 11; // you could also write number >>= 11
int width = number & filter;
int color = number >> 11;

Image size = 648x1175x16



For instance, image files pack values int bits, not bytes.

[QUOTE]
What does shift do? I read this thread and was intrigued but don't
understand it's use.
I am just learning the basics.

Please advise.

 

[Jay]

Yes it doesn't make sense, but it ought to do something sensible rather than something quirky. For
example, if you shift by more than 32 bits, it should set the variable to zero (assuming unsigned
variables for now) since this is the true answer if you did shift more than 32 bits.

So is that a bug?

It's by design. When you think about it, shifting a 32 bit integer with
anything more than 31 places doesn't make any sense.

http://msdn2.microsoft.com/en-us/library/xt18et0d.aspx

 

[Morten Wennevik]

Yes it doesn't make sense, but it ought to do something sensible rather
than something quirky. For
example, if you shift by more than 32 bits, it should set the variable
to zero (assuming unsigned
variables for now) since this is the true answer if you did shift more
than 32 bits.

Not if there is more information in the shift parameter than should be
used for shifting. For instance, if you have a value that needs to be
shiftet several times each time a different number of places. You could
then store all the shift values in a single integer and shift the shift
value n places each shift.

int someNumber = 12345667;
int shiftNumber = 12345;

int value1 = someNumber;
someNumber >>= shiftNumber;
shiftNumber >>= 5;
int value2 = someNumber;
someNumber >>= shiftNumber
shiftNumber >>= 5
....

I can't see much reason to use it, but there may be some performance to be
gained in a heavy duty loop.

 

[Jay]

Thanks for the info. It sounds like the sort of behaviour I'd expect from C, but not what I'd expect
from C# which I tend to think of as being cleaned up of quirks. But if that's the way it is, then
that's the way it is. I just have to be careful when I code I guess.

Yes it doesn't make sense, but it ought to do something sensible rather
than something quirky. For
example, if you shift by more than 32 bits, it should set the variable
to zero (assuming unsigned
variables for now) since this is the true answer if you did shift more
than 32 bits.

Not if there is more information in the shift parameter than should be
used for shifting. For instance, if you have a value that needs to be
shiftet several times each time a different number of places. You could
then store all the shift values in a single integer and shift the shift
value n places each shift.

int someNumber = 12345667;
int shiftNumber = 12345;

int value1 = someNumber;
someNumber >>= shiftNumber;
shiftNumber >>= 5;
int value2 = someNumber;
someNumber >>= shiftNumber
shiftNumber >>= 5
....

I can't see much reason to use it, but there may be some performance to be
gained in a heavy duty loop.