in reply to Negabinary Number System

That's an interesting concept. So, if we use this system, the first few numbers would be:
  1. 0000 0001
  2. 0000 0110
  3. 0000 0111
  4. 0000 0100
  5. 0000 0101
  6. 0001 1010
  7. 0001 1011
  8. 0001 0000
  9. 0001 0001
  10. 0001 0110
The system goes from -170 to 85, giving us 256 possible numbers, as we should have.

Does that look correct? What are the possible benefits to the negabinary system? What calculations does it make easier that binary has a problem with? I know that it would make working with negative numbers much easier, but why is that a problem with the current high-bit-flip?

Update: Just as a thought, wouldn't an inverse negabinary system work better? You'd go from -85 to 170 in an 8-bit number, which would allow more positives than negatives, which would seem more useful. (Interestingly enough, 85 * 2 = 170 ...) In that system, you'd have:

  1. 0000 0011
  2. 0000 0010
  3. 0000 1101
  4. 0000 1100
  5. 0000 1111
  6. 0000 1110
  7. 0000 1001
  8. 0000 1000
  9. 0000 1011
  10. 0000 1010
(Coincedentally, the second list is the negative numbers from the first system, and vice versa.)

------
We are the carpenters and bricklayers of the Information Age.

Vote paco for President!

Replies are listed 'Best First'.
Re^2: Negabinary Number System
by Anonymous Monk on Mar 03, 2008 at 04:46 UTC
    Actually, an inverse negabinary would have the same problems. Notice that if you use 9 bits in a regular negabinary system, you get numbers from -170 to 341 -- each time you add a bit, you go from having 1/3 negative numbers and 2/3 positive numbers, to having 2/3 negative numbers and 1/3 positive numbers, and vice versa. An inverse negabinary system would simply reverse which occurs during an odd number of bits and which occurs on an even number of bits.