-4

With unsigned char you can store a number from 0 to 255

255(b10) = 11111111(b2)             <=    that's 1 byte

This will make it easy to preform operations like +,-,*...

Now how about:

255(b10) = 10101101(b2)

Following this method will make it possible to represent up to 399 using unsigned char?

399(b10) = 11111111(b2)

Can someone propose an algorithm to preform addition using the last method?

Rob Kennedy
  • 161,384
  • 21
  • 275
  • 467
Jonas
  • 1,019
  • 4
  • 20
  • 33
  • It is *very* unclear what you are talking about. A `char` is a `char` and it has a definition which is based on *bits*. If you want a special datatype which is based on `bits with three states`, and then want to use that in a programming language, you first need to build the appropriate computer and compilers for it. – Irfy Mar 06 '12 at 03:22
  • Are you trying to define your own datatype which will simply "store" a `char` in an array of "tri-state bits"? The only way you can do this is to use "bits" to represent "tri-state bits", and then use those to represent your own numbers. Why in the world would you want to do this? – Irfy Mar 06 '12 at 03:23
  • representing big numbers – Jonas Mar 06 '12 at 03:26
  • When you say `255(b10) = 10101101(b?)`, do you mean that 144 = 0b0000000, which is to say, that you're redefining a char to be 144-399 instead of 0-255? – rob05c Mar 06 '12 at 03:28
  • You can represent bigger numbers simply by using larger data types, `unsigned short`, `unsigned int`, `unsigned long`... – Alex Z Mar 06 '12 at 03:29
  • @rob05c my bad b? is b2. no I want to represent 0-399 – Jonas Mar 06 '12 at 03:31
  • @AlexZ yeah but why lose 144 numbers in each byte? – Jonas Mar 06 '12 at 03:36
  • @jonas I still don't understand you. It is _only possible_ to store 256 discrete values with 8 bits. You can redefine what those are, e.g. 144-399 instead of 0-255, or even 12345-12600. But it isn't possible to store more than 256 discrete values. Are you asking how to do the former or the latter? The former, you can perform addition with simple bit shifting. We can help you with that. The latter is impossible. – rob05c Mar 06 '12 at 03:37
  • @rob05c why do you want to stop at 0=00000000 and 255=11111111 instead of reaching 0=00000000 and 399=11111111 – Jonas Mar 06 '12 at 03:40
  • 2
    Jonas, write down all the possible values between 00000000 and 11111111: 00000000, 00000001, 00000010, 00000011, etc. Count how many values you get. Assign one bit pattern to each successive natural number: 0, 1, 2, 3, etc. If you write down more than 256 values, you've either made a mistake, or you've made the discovery of the millennium. Nobody necessarily *wants* to stop at 255. It's just the laws of nature and mathematics that *force* us to. Look up the "pigeon-hole principle": You can't stuff 400 pigeons in only 256 holes. – Rob Kennedy Mar 06 '12 at 03:44
  • You do not *understand* bytes and bits. You can represent *only 256 different values* with 8 bits. And a `char` has only 8 bits. So you are out of luck. You cannot represent numbers larger than 255, unless you *redefine* 0 to mean, say, 144, 1 to mean 145, and so on. – Irfy Mar 06 '12 at 03:45
  • @jonas: Here's a simple excercise: Make a table of all the numbers from 0 to 399 and their proposed representation under your scheme. Once you're done, check for repetitions. You'll have 144 :) – Carl Mar 06 '12 at 03:45
  • @jonas see Rob Kennedy's comment above. What you want to do is mathematically impossible. You can only represent 256 discrete values with 8 boolean values. – rob05c Mar 06 '12 at 03:48

4 Answers4

5

With eight bits there are only 256 possible value (28), no matter how you slice and dice it.

Your scheme to encode digits in a 2-3-3 form like:

255 = 10 101 101
399 = 11 111 111

ignores the fact that those three-bit sequences in there can only represent eight values (0-7), not ten (ie, that second one would be 377, not 399).

The trade-off is that this means you gain the numbers '25[6-7]' (2 values) '2[6-7][0-7]' (16 values) and '3[0-7][0-7]' (64 values) for a total of 82 values.

Your sacrifice for that gain is that you can no longer represent any numbers containing 8 or 9: '[8-9]' (2 values), '[1-7][8-9]' (14 values), '[8-9][0-9]' (20 values), '1[0-7][8-9]' (16 values), '1[8-9][0-9]' (20 values) or '2[0-4][8-9]' (10 values), for a total of 82 values.

The balance there (82 vs. 82) shows that there are still only 256 possible values for an eight-bit data type.

So your encoding scheme is based on a flawed premise, which makes the second part of your question (how to add them) irrelevant, I'm afraid.

paxdiablo
  • 854,327
  • 234
  • 1,573
  • 1,953
  • what was I thinking!! never stay up till 3AM again =) – Jonas Mar 06 '12 at 03:44
  • 1
    and here I was hoping he simply wanted to represent 144-399 with 8 bits, so I could come up with some amusing-but-useless bit shifting arithmetic :( – rob05c Mar 06 '12 at 04:07
2

A unsigned char type can only mathematically hold values between 0 and 255 as determined by the rule 2^n - 1 for the maximum unsigned value that the amount of bits n can represent. There is no way to "improve" a char range, you probably want to use an unsigned short which holds two bytes instead.

Alex Z
  • 2,500
  • 2
  • 19
  • 23
0

You're mistaken.

In your scheme, 255 would be 010101101, which is 9 bits. The leading zero is important. I'm assuming here you're using something that looks like the octal representation. 3 bits/digit. Any other alternative means you cannot represent all the other digits.

|0|000|
|1|001|
|2|010|
|3|011|
|4|100|
|5|101|
|6|110|
|7|111|
|8|???|
|9|???|

9 in binary is 1001. So you can't use 3 bits per digit. You need to use 4 bits if you want to represent 8 and 9. Again, I'm trying to assume here that you're encoding each digit separately. So, 399 according to you would be: 001110011001 - 12 bits. By comparison, binary does 399 in 110001111 - 9 bits.

So binary is the most efficient, because encoding digits from 0 to 9 in your system means that the maximum number you can store without any information loss in 8 bits is 99 - 10011001 :)

One way to think of binary, is a path that is the result of a log search to find the number.

If you really want to condense the number of bits needed to represent a number, what you're really after is some sort of compression and not the way binary is done.

Carl
  • 43,122
  • 10
  • 80
  • 104
0

What you want to do is mathematically impossible. You can only represent 256 discrete values with 8 boolean values.

To test this, make a chart of all possible values, in decimal and binary. I.e.

000 = 00000000
001 = 00000001
002 = 00000010
003 = 00000011
004 = 00000100

...

254 = 11111110
255 = 11111111

You will see that after 255, you need a ninth bit.

You can let 255 = 10101101, but if you work backwards from that, you will run out before you reach 0.

You seem to hope you can somehow use a different counting mechanism to store more values. This is not mathematically possible. See the Pidgeonhole Principle.

rob05c
  • 1,223
  • 1
  • 9
  • 18