Actions

## Bug #13711

closed### Unexpected behavior of bit_length method on negative integers

**Description**

The two's complement representation of negative integers produces unexpected results

when the **bit_length** method is applied to them.

```
5.bit_length => 3
4.bit_length => 3
3.bit_length => 2
2.bit_length => 2
1.bit_length => 1
0.bit_length => 0
(-1).bit_length => 0
(-2).bit_length => 1
(-3).bit_length => 2
(-4).bit_length => 2
(-5).bit_length => 3
(-6).bit_length => 3
(-7).bit_length => 3
(-8).bit_length => 3
(-9).bit_length => 4
```

I would have thought that **bit_length** on a negative integer would return the number

of bits it takes to represent a two's complement number on the given cpu/os.

Since the two's complement of negative integers are of the form:

```
-1 => 111111111111111111
-2 => 111111111111111110
-3 => 111111111111111101
-4 => 111111111111111100
-5 => 111111111111111011
-6 => 111111111111111010
-7 => 111111111111111001
-8 => 111111111111111000
-9 => 111111111111110111
```

it thus appears for negative integers **bit_length** returns the bit

position of the left most **0** of the two's complement representation.

Is this correct?

Is this intentional?

If so, can an explanation of this behavior/rationale be given.

Actions

Like0
Like0Like0Like0