The docs say:
"<< is a left shift. >> is a signed right shift. >>> is an unsigned right
shift."

Now, here's the thing:

We don't have separate operators for signed multiply and unsigned multiply. Why not? Because one operator does both jobs, based on the type of its arguments.

We don't have separate operators for signed divide and unsigned divide. Why not? Because one operator does both jobs, based on the type of its arguments.

Same goes for %.

And yet, we DO have separater operators for signed right shift and unsigned right shift. C doesn't. C++ doesn't. But D does.

?

And, if I have understood the documentation correctly, these operators the
actual sign of the arguments (which means that D's (uint >> uint) will behave
differently from C).

I believe that Java has both >> and >>> - but with good reason. Java has no unsigned integers, and so you need a separate operator (>>>) to do unsigned shift right. This logic does not apply to D.

Is there a point to all this? Or is it just a case of "Oh yeah, that. I was going to fix that years ago but there always seemed be more important things to do"?

Arcane Jill (confused)

Arcane Jill wrote:

> The docs say:
> "<< is a left shift. >> is a signed right shift. >>> is an unsigned right
> shift."
> 

Question: what is the difference between a signed shift and an unsigned shift?

I know there is a difference between a Roll-Over and a Shift.

A simple shift will set the overflow flag with the bit shoved off the end and simply fill in zeros in the empty space.  For example:

00001111 >> 1 == 00000111

A roll over will operate the same way the shift does, except it uses the
value of the overflow flag to fill in the empty space.  This results in
what appears to be a roll over:

00001111 >>> 1 == 10000111

These are two separate operations, with very different results.  This
is why Java really has the >> and >>> operators.  It has nothing to do
with signed and unsigned numbers.  It has to do with predictable roll
over vs. shift operations.

These are bitwise operations and really have nothing to do with sign.

Most folks know that the shift function is a Q&D multiply/divide by 2.
The roll over is different, and used in hash functions among other
things.

Berin Loritsch wrote:

> Arcane Jill wrote:
> 
>> The docs say:
>> "<< is a left shift. >> is a signed right shift. >>> is an unsigned right
>> shift."
>>
> 
> Question: what is the difference between a signed shift and an unsigned shift?
> 
> I know there is a difference between a Roll-Over and a Shift.
> 
> A simple shift will set the overflow flag with the bit shoved off the end and simply fill in zeros in the empty space.  For example:
> 
> 00001111 >> 1 == 00000111
> 
> A roll over will operate the same way the shift does, except it uses the
> value of the overflow flag to fill in the empty space.  This results in
> what appears to be a roll over:
> 
> 00001111 >>> 1 == 10000111

Oops, I forgot to mention that most processors also have a BOF (Branch
on Overflow).  This is the reason that the overflow flag is involved.

This info dates back to when I did assembly work (not so much anymore).

Berin Loritsch schrieb:

> Question: what is the difference between a signed shift and an unsigned shift?

To fill up the "empty" bit which appears when shifting right, unsigned shift inserts a zero there. Signed shift replicates the old leftmost bit. If you're puzzled, look up "2's complement".

Unsigned shift right, is just that - a shift, which appears to divide a positive integer by 2 (or a power thereof). Signed shift right divides by 2 (or a power thereof) taking the sign into attention.

With left shifts, there is no difference between signed and unsigned - always fill up with zero, and always correspond to multiplication by 2 (or a power thereof).

-eye

In article <ce5lrj$26js$1@digitaldaemon.com>, Berin Loritsch says...

>Arcane Jill wrote:
>
>> The docs say:
>> "<< is a left shift. >> is a signed right shift. >>> is an unsigned right
>> shift."
>> 
>
>Question: what is the difference between a signed shift and an unsigned shift?

I would have expected you to know this, coming from a Java background. Java clearly has both, as documented at Sun's Java website: http://java.sun.com/docs/books/tutorial/java/nutsandbolts/bitwise.html

(x >> 1) is the same thing as (x / 2) if x is signed
(x >>> 1) is the same thing as (x / 2) if x is unsigned




>A simple shift will set the overflow flag with the bit shoved off the end and simply fill in zeros in the empty space.  For example:
>
>00001111 >> 1 == 00000111
>
>A roll over will operate the same way the shift does, except it uses the value of the overflow flag to fill in the empty space.  This results in what appears to be a roll over:
>
>00001111 >>> 1 == 10000111
>
>These are two separate operations, with very different results.  This is why Java really has the >> and >>> operators.  It has nothing to do with signed and unsigned numbers.  It has to do with predictable roll over vs. shift operations.

That's not what it says on the Java web site. Anyway, if >>> does rotate-right, then why is there no corresponding <<< for rotate-left?


>Most folks know that the shift function is a Q&D multiply/divide by 2.

Q and D?

>The roll over is different, and used in hash functions among other things.

Of course, you can use the ROL and ROR instructions in D using inline assembler. But this has got nothing to do with >>> (so I'm changing the thread title). It might be useful to have these functions in std.intrinsic though.

Jill

Ilya Minkov wrote:

> Berin Loritsch schrieb:
> 
>> Question: what is the difference between a signed shift and an unsigned shift?
> 
> 
> To fill up the "empty" bit which appears when shifting right, unsigned shift inserts a zero there. Signed shift replicates the old leftmost bit. If you're puzzled, look up "2's complement".
> 
> Unsigned shift right, is just that - a shift, which appears to divide a positive integer by 2 (or a power thereof). Signed shift right divides by 2 (or a power thereof) taking the sign into attention.
> 
> With left shifts, there is no difference between signed and unsigned - always fill up with zero, and always correspond to multiplication by 2 (or a power thereof).

Ok, Signed SHift == Roll Over, and Unsigned Shift == shift

Arcane Jill wrote:

> In article <ce5lrj$26js$1@digitaldaemon.com>, Berin Loritsch says...
> 
> 
>>Arcane Jill wrote:
>>
>>
>>>The docs say:
>>>"<< is a left shift. >> is a signed right shift. >>> is an unsigned right
>>>shift."
>>>
>>
>>Question: what is the difference between a signed shift and an unsigned shift?
> 
> 
> I would have expected you to know this, coming from a Java background. Java
> clearly has both, as documented at Sun's Java website:
> http://java.sun.com/docs/books/tutorial/java/nutsandbolts/bitwise.html
> 
> (x >> 1) is the same thing as (x / 2) if x is signed
> (x >>> 1) is the same thing as (x / 2) if x is unsigned

Honestly, I have always parsed this in light of my old assembly
experience, and really don't get hopped up on reading specs.

> 
> That's not what it says on the Java web site. Anyway, if >>> does rotate-right,
> then why is there no corresponding <<< for rotate-left?
> 

Good question

> 
> 
>>Most folks know that the shift function is a Q&D multiply/divide by 2.
> 
> 
> Q and D?

Quick and Dirty

>>The roll over is different, and used in hash functions among other
>>things.
> 
> 
> Of course, you can use the ROL and ROR instructions in D using inline assembler.
> But this has got nothing to do with >>> (so I'm changing the thread title). It
> might be useful to have these functions in std.intrinsic though.

Right.

Arcane Jill wrote:
> The docs say:
> "<< is a left shift. >> is a signed right shift. >>> is an unsigned right
> shift."
> 
> Now, here's the thing:
> 
> We don't have separate operators for signed multiply and unsigned multiply. Why
> not? Because one operator does both jobs, based on the type of its arguments.
> 
> We don't have separate operators for signed divide and unsigned divide. Why not?
> Because one operator does both jobs, based on the type of its arguments.
> 
> Same goes for %.
> 
> And yet, we DO have separater operators for signed right shift and unsigned
> right shift. C doesn't. C++ doesn't. But D does.
> 
> ?
> 
> And, if I have understood the documentation correctly, these operators the
> actual sign of the arguments (which means that D's (uint >> uint) will behave
> differently from C).
> 
> I believe that Java has both >> and >>> - but with good reason. Java has no
> unsigned integers, and so you need a separate operator (>>>) to do unsigned
> shift right. This logic does not apply to D.
> 
> Is there a point to all this? Or is it just a case of "Oh yeah, that. I was
> going to fix that years ago but there always seemed be more important things to
> do"?
> 
> Arcane Jill (confused)
> 
> 
> 
Maybe the operator was introduced because Java has it??
In Java >>> operator makes sense, since Java has only signed types, but you are right: The >>> operator doesn't make much sense in D.

In article <ce5jsr$260p$1@digitaldaemon.com>, Arcane Jill says...
>Is there a point to all this?

http://www.digitalmars.com/d/ctod.html#ushr ?

-- 
Kaz.

In article <ce5ubo$2bhe$1@digitaldaemon.com>, Kazuhiro Inaba says...
>
>
>In article <ce5jsr$260p$1@digitaldaemon.com>, Arcane Jill says...
>>Is there a point to all this?
>
>http://www.digitalmars.com/d/ctod.html#ushr ?
>
>-- 
>Kaz.

Aha - I missed that. Thanks for pointing that out. It does make perfect sense now.

Well, I suppose the point is that the docs say: "<< is a left shift. >> is a signed right shift. >>> is an unsigned right shift." Which means that the docs are wrong, and this is in fact a documentation error.

So the phrase ">> is a signed right shift" should read ">> is a right shift, which is signed if the left hand argument is signed, or unsigned if the left hand argument is unsigned".

Jill