[issue31079] mathematically wrong results from int and long bit_length methods

Stefan Krah added the comment: Thank you for your expertise. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ __

[issue31079] mathematically wrong results from int and long bit_length methods

vinsci added the comment: >>> (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 docs

[issue31079] mathematically wrong results from int and long bit_length methods

Stefan Krah added the comment: Look at Include/longobject.h and https://docs.python.org/3/library/stdtypes.html?highlight=bit_length#int.bit_length . -- nosy: +skrah ___ Python tracker ___

[issue31079] mathematically wrong results from int and long bit_length methods

New submission from vinsci: 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