Title: mathematically wrong results from int and long bit_length methods
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.7, Python 3.6, Python 3.3, Python 3.4, Python 3.5, Python 2.7
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: skrah, vinsci
Priority: normal Keywords:

Created on 2017-07-30 16:27 by vinsci, last changed 2017-07-30 18:02 by skrah. This issue is now closed.

Messages (4)
msg299500 - (view) Author: (vinsci) Date: 2017-07-30 16:27
It takes as many bits to store the number 0 as the number 1, but the implementation claims it takes no bits at all to store a 0.

>>> (1).bit_length() == (0).bit_length() and True or False

It takes one extra bit to store the sign for negative numbers, but this isn't reflected in the implementations.

>>> (-1).bit_length() == 1 + (1).bit_length() and True or False
msg299501 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2017-07-30 16:38
Look at Include/longobject.h and .
msg299505 - (view) Author: (vinsci) Date: 2017-07-30 17:53
>>> (0).bit_length.__doc__
"int.bit_length() -> int\n\nNumber of bits necessary to represent self in binary.\n>>> bin(37)\n'0b100101'\n>>> (37).bit_length()\n6"

The library documentation has clearly been written in disregard of the advertised functionality in the docstrings of the methods.

The documentation is just echoing the flaws of the unit tests.

For the Python 3 variant of this issue, it can be added that the library documentation wrongly states that the method is "New in version 3.1.".
msg299506 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2017-07-30 18:02
Thank you for your expertise.
Date User Action Args
2017-07-30 18:02:45skrahsetstatus: open -> closed
resolution: not a bug
messages: + msg299506

stage: resolved
2017-07-30 17:53:26vinscisetmessages: + msg299505
2017-07-30 16:38:39skrahsetnosy: + skrah
messages: + msg299501
2017-07-30 16:27:18vinscicreate