Issue 31079: mathematically wrong results from int and long bit_length methods (original) (raw)

Issue31079

Created on 2017-07-30 16:27 by vinsci, last changed 2022-04-11 14:58 by admin. 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 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 False
msg299501 - (view)	Author: Stefan Krah (skrah) *	Date: 2017-07-30 16:38
Look at Include/longobject.h and https://docs.python.org/3/library/stdtypes.html?highlight=bit_length#int.bit_length .
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) *	Date: 2017-07-30 18:02
Thank you for your expertise.