Jump to content

Talk:Arithmetic shift

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

One's Complement

[edit]

When multiplying a negative number written using the one's complement convention, 1, and not 0, should be inserted into the LSB. A clear example of this is 1101 (-2). When left-shifted as described in the article, it'd become 1010 (-5). However, if 1 is put into the LSB, it becomes 1011(-4), the correct answer. So actually, when using one's complement, the signal bit should be reinserted into the LSB after the shift. Budsbd 14:30, 6 March 2007 (UTC)[reply]

On arithmetic right shift equivalence to division:

It is stated that arithmetic right shift is not equivalent to division by a power of two, but this is only the case if division of negative rounds towards zero; if on a particular machine division rounds towards negative infinity, the right shift is equivalent.

Also, it is stated that this non-equivalence is the reason C doesn't specify right shift behavior of a negative value. From my understanding, the real reason is simply that right shifts of signed positive integers are common, and some hardware doesn't natively support arithmetic right shifts (only logical, which fills the sign bit with zero), so requiring sign preservation would hurt efficiency on these machines. For the same reason, C doesn't specify the rounding direction when a negative value is divided. C's philosophy is generally to provide what the underlying hardware does (int sizes for example), so >> maps to whatever is provided. -- A reader —Preceding unsigned comment added by 66.90.245.211 (talk) 18:23, 2 February 2008 (UTC)[reply]

Shift Functions and Signed Arguments

[edit]

I added a footnote on how shifts work in Scheme, as I think it is interesting to show that Shifts do not have to be operators and that a hybrid approach is possible (shift left, right and in any way depending on the operator). --88.217.68.206 (talk) 23:44, 18 May 2008 (UTC)[reply]

In Haskell, too, shifts are not "operators" provided by the language but functions provided by a library. (The distinction between "operators" and "functions" in Haskell doesn't really exist, since both are provided by libraries. Any function can be used in either prefix or infix position; the default depends on whether the function is named with letters or punctuation. Both shift x -2 and x `shift` -2 will evaluate to the value of x shifted right by two.)

Both a signed-argument function (shift with a positive argument for left shifts, negative for right shifts) and a pair of unsigned-argument functions (shiftL and shiftR) are provided. I just updated the Haskell information to indicate this; I show the signed-argument function and add a note with further information about the unsigned-argument functions. (I show just the single argument version outside the note to make room for the module name to make it more clear that this is a library function, not part of the langauge definition.)

The OpenVMS macro langauge note is probably no longer correct that a signed-argument shift is "unusual," since now four of the languages listed (OpenVMS macro langauge, Scheme, Common Lisp and Haskell) provide signed-argument shift functions, and no doubt there are other languages that do this as well. I'm not sure if or how that note should be changed. Cjs (talk) 23:42, 30 June 2019 (UTC)[reply]

Equivalence discussion

[edit]

The article rides about the claim that there is no equivalence of shift and multiplication or division before it gets to the issue. This should not be presented drama-style.

The statement "Logical shifts of binary numbers are only equivalent to division by a power of 2 when the ones' complement representation of signed numbers is being used, for example." lacks explanation, esp. since logical shifts are not applicable to the interpretation of a word as a negative number; I vaguely feel this statement is just nonsense because for a negative number, a logical shift would make it positive in any complement.

Complement

[edit]

The suggested transition from "older ones' complement architectures to newer two's complement architectures" is not historically correct; the first working digital computer (Zuse Z3) did use the 2's complement. — Preceding unsigned comment added by Towopedia (talkcontribs) 15:41, 6 September 2012 (UTC)[reply]

Left shift not correct?

[edit]

The arithmetic left shift diagram appears to be incorrect. It shows the second-most-significant bit being copied into the most-signficant bit. In C (C99) and C++ (11) the result of left shifting a negative signed integral type is undefined behavior. C and C++ can thus be said to have no arithmetic left shift; only logical.

However, in the abstract sense, the most-significant bit should be preserved (+3 becomes +6 and -2 becomes -4). An overflow happens if the most-significant bit is different from any of the N next most significant bits, whether positive or negative. For the diagram to apply to the abstract logical situation, all those bits disappear and MSB remains the same. Anything else is a technical detail dependent on the platform or language. Casu Marzu (talk) 17:51, 30 September 2013 (UTC)[reply]

The first picture depicts LOGICAL SHIFT in ARITHMETIC SHIFT

[edit]

The first pic & its caption (http://en.wikipedia.org/wiki/File:Rotate_left_logically.svg) doesn't go with the text in the Main section of Arithmetic Shift. Please

  • remove the first picture

or

  • change its caption stating that it is infact a logic shift operation and is given to differentaite between the two shifts

The caption says "A left arithmetic shift of a binary number by 1..." but it is seen as a "logical shift" as the new bit is filled with zero and not the replicated last bit. — Preceding unsigned comment added by 122.172.182.194 (talk) 05:36, 27 October 2013 (UTC)[reply]

MIPS lacks a Shift Left Arithmetic operator

[edit]

MIPS lacks a sla operator, but is listed as having one 67.252.63.253 (talk) 04:03, 16 December 2015 (UTC)[reply]

Arithmetic vs logical vs multiplication

[edit]

This section is supposed to be about arithmetic shift vs multiplication, but then talks about arithmetic shift vs logical shift. As far as I know, arithmetic and logical left shift are identical operations, so I'm not sure what this section is talking about.

https://en.wikipedia.org/wiki/Bitwise_operation#Logical_shift says "Therefore, the logical and arithmetic left-shifts are exactly the same."

How can the "MSB be preserved" when the MSB is destroyed by the shift?? — Omegatron (talk) 00:19, 5 December 2018 (UTC)[reply]

Funnel shift

[edit]

A funnel shift (or double shift in the x86 instruction set) is the shift of two concatenated bit fields. This is useful for unaligned bit streams. I don't find any mentioning of this in Wikipedia. Should it be added here or made as a separate article? Agnerf (talk) 08:51, 4 April 2021 (UTC)[reply]

Logical/arithmetic left equivalence

[edit]

I added a fact tag to

> Logical left shifts are also equivalent, except multiplication and arithmetic shifts may trigger arithmetic overflow whereas logical shifts do not

In Intels, RISC-V, and the M68K, logical and arithmetic left shifts are equivalent *including* the flags. I'm not sure what the source for this statement was. 69.121.57.177 (talk) 14:39, 13 August 2023 (UTC)[reply]

Not only that, all the rest of the text makes no mention of "flags" at all and is comparing the results, which are identical. I'm sure there are lots of ways to change what flags are triggered and you can't just split them into "arithmetic" and "logical". Spitzak (talk) 17:08, 13 August 2023 (UTC)[reply]

Arithmetic shift operators in various programming languages and processors

[edit]

Most of the entries under "left" in this table are incorrect, as they list logical left shift operators and mnemonics on systems that have no arithmetic left shift.

Instead they should probably either list "none", or clearly identify that these are logical left shifts or somehow note that they are synonymous with arithmetic left shifts. 69.121.57.177 (talk) 14:41, 13 August 2023 (UTC)[reply]

Found the same thing: The information given for C language in this table is incorrect. For unsigned types shift right (>>) operator is "logical shift" and for signed types the behavior is implementation defined (e.g. depends on CPU and/or compiler). It can be "arithmetic shift" but it doesn't have to. 84.253.48.217 (talk) 13:21, 1 February 2024 (UTC)[reply]

Two's complement "double meaning" of MSBit shifted in

[edit]

When shifting right a two's complement number the sign bit is shifted in. Therefore the number of sign bits increases. This is one way to see it.

This is not "visible" for positive values, where the sign bit(s) is 0. And each 1 bit in position [n] (pos [0] is the rightmost) would represent 2exp(n). A 0 bit gives no added value.

But for negative values the increasing number of sign bits, all those except for the leftmost "real" single sign bit, still (or also) carry the integer weights. For negative values a 0 would in pos [n] mean (-2exp(n))-1. A 1 or "sign" bit gives no added value.

In other words, the increasing number of sign bits with a right shift of a two's complement would carry this "double meaning" as sign bits or "inverted" bits. And that these increasing number of sign bits don't stand in the way for the value. I guess that's the magic og two's complement.

These leftmost "value" bits, being 1 for negative and 0 for zero or positive values, all they state is that "there is nothing here".

So a shift right by 8 bits always is the same as divide by 2exp(8)=256.

Is this worth mentioning in the article? And in case, how should one say all this "in one sentence"? Or is it there already? Øyvind Teig (talk) 09:46, 18 May 2024 (UTC)[reply]

This is already talked about over and over and over in this article. And right shift by 8 is floor((x/256.0)), not x/256, which is exactly what all your convoluted description of the sign bit amounts to. Spitzak (talk) 18:14, 19 May 2024 (UTC)[reply]
Thank you. I am still not able to see where this is discussed in the article. Please give an example. Plus, x >> y = floor(x/pow(2,y)) is correct, but most often not used since we are talking about integer division with integer results, as I was. And the connection of this floor definition with my "convoluted" description I also fail to understand. I did try to repeat points from different angles, which to the best of my understanding should be acceptable on a the talk page, "If in doubt, make the extra effort so that other people understand you. Being friendly is a great help." Øyvind Teig (talk) 21:16, 20 May 2024 (UTC)[reply]