Again, finally getting around to fixing up this blog and approving the few non-spam comments among the chaff. Since you didn’t show your calculation I can’t be quite sure what you’re doing wrong, but there’s a clue in that your result isn’t odd. If your current number is a **1****, you will always be adding a ****1** after the doubling. So:

1

(1) x 2 + 1 = 3

(3) x 2 + 1 = 7

(7) x 2 + 1 = 15

(15) x 2 + 1 = 31

(31) x 2 + 1 = 63

(63) x 2 + 1 = 127

(127) x 2 + 1 = 255

Again, finally getting around to fixing up this blog and approving the few non-spam comments among the chaff. Since you didn’t show your calculation I can’t be quite sure what you’re doing wrong, but there’s a clue in that your result isn’t odd. If your current number is a **1****, you will always be adding a ****1** after the doubling. So:

1

(1) x 2 + 1 = 3

(3) x 2 + 1 = 7

(7) x 2 + 1 = 15

(15) x 2 + 1 = 31

(31) x 2 + 1 = 63

(63) x 2 + 1 = 127

(127) x 2 + 1 = 255

After getting hacked (five or six years ago!) I just shut down the blog rather than slogging through the code trying to get things rooted out. But, everything is still here, including a handful of unapproved comments. So, four years later: you’re right in your calculation, Bazy, but 1111 binary *is*, in fact, 15. 16 would be 10000.

This calculation is just fantastic, thank you so much as it has saved my life!

One thing I found is it does not appear to convert 11111111 correctly, it should convert to 255 in decimal but I keep getting 248 for some reason, could you please advise what I’m doing wrong?

]]>Working:

1 x 2 = (2) + 1 = 3

3 x 2 = (6) + 1 = 7

7 x 2 = (14) + 1 = 15

thus 1111 is note equal to 16 in decimal. There seems to be some major loop hole.

please correct me if im wrong. ]]>

Hi, Rei.

Just as with decimal numbers, you can assume there are an infinite number of zero to the left of the leftmost binary digit. So, If you have a binary number with extra **0**s on the left, just ignore them and start with the first **1**.