classification
Title: << operator has a bug
Type: behavior Stage: resolved
Components: Versions: Python 3.8
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Nandish, eric.smith
Priority: normal Keywords:

Created on 2020-12-22 19:00 by Nandish, last changed 2020-12-22 19:40 by eric.smith. This issue is now closed.

Messages (4)
msg383599 - (view) Author: Nandish (Nandish) Date: 2020-12-22 19:00
I verified the following on both Python 2.7 and Python 3.8

I did print(100<<3) Converting 100 to Binary gives 1100100. What I did is I droped the first 3 bits and added 3 bits with the value '0' at the end. So it should result as 0100000, and I converted this to Decimal and the answer was 32.

For my suprise when I executed print(100<<3) the answer was 800. I was puzzled. I converted 800 to Binary to check whats going on. And this is what I got 1100100000.

If you see how 800 was Python answer, they did not shift or drop the first 3 bits but they added value '0' to last 3 bits.

Where as print(100>>3) , worked perfect. I did manual calculation and cheked the print result from python. It worked correctly. Dropped last 3 bits and added value '0' to first 3 bits.

Looks like (100<<3) , left shift operator has a bug on Python.
msg383605 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2020-12-22 19:24
Why do you think the first 3 bits should be dropped? That's not the documented behavior of <<.
msg383607 - (view) Author: Nandish (Nandish) Date: 2020-12-22 19:35
I took print(100>>3), I dropped last 3 bits and added value ‘0’ to first 3
bits. Both manual calculation and python result was correct.

How can << shit operator and >> shit operator work differently , with
different logic ?

Thanks
Nandish

On Wed, Dec 23, 2020 at 12:54 AM Eric V. Smith <report@bugs.python.org>
wrote:

>
> Eric V. Smith <eric@trueblade.com> added the comment:
>
> Why do you think the first 3 bits should be dropped? That's not the
> documented behavior of <<.
>
> ----------
> nosy: +eric.smith
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue42720>
> _______________________________________
>
msg383608 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2020-12-22 19:40
That's not how they're defined. From https://docs.python.org/3/reference/expressions.html?highlight=left%20shift#shifting-operations

"A right shift by n bits is defined as floor division by pow(2,n). A left shift by n bits is defined as multiplication with pow(2,n)."

Perhaps you are assuming that Python operates on fixed width integers, such as 8 bit bytes? That's not true. You can think of Python integers as infinitely large, up to the limit of how memory you have.

Since it's working as documented, I'm going to close this.
History
Date User Action Args
2020-12-22 19:40:54eric.smithsetstatus: open -> closed
resolution: not a bug
messages: + msg383608

stage: resolved
2020-12-22 19:35:07Nandishsetmessages: + msg383607
2020-12-22 19:24:28eric.smithsetnosy: + eric.smith
messages: + msg383605
2020-12-22 19:00:22Nandishcreate