I am going to teach a small group of people about the numbering systems in computing and was wondering how many bits per digit are there in the decimal system, for instance:
What you are looking for is the 2-based logarithm of 10, which is an irrational number of around 3.32192809489....
The fact that you can't use an integer number of bits for a decimal digit is the root cause of why many fractions that are easy to express in the decimal system (e.g. 1/5 or 0.2), are impossible (not hard: really impossible) to express in binary. This is important when evaluating rounding errors in floating point arithmetics.
In other words, what amount of information is contained in a single digit in these systems.
For base 2, base 4, base 8, base 16 and other 2N bases the answer is obvious because in a base 2N each digit can be expressed with exactly N digits.
How do you get N given 2N? Well, you use a 2-based logarithm, which is an inverse of exponentiation.
K-based logarithms of numbers that are not powers of K aren't cardinal numbers. In particular:
This number may look confusing, but it actually has some uses. For example, it's an entropy of a single decimal digit.
For your case, though, I don't think this value is of any use. @Christian's answer does a good job at explaining why.
I'm sorry to say the question is misguided. You wouldn't use bits in that manner. A bit is a binary digit. You can convert the decimal number 10, to a binary 1010 (8+2), so you'd need 4 bits to express the decimal value 10.
You've fallen into a bit of a trap, by using binary (2), octal (8) and hexadecimal (16) as examples, because these are all powers of 2, and thus you can think of them in terms of bits, whereas 10 isn't a power of 2, so it just doesn't work very well like that.
BCD - Binary Coded Decimal uses 4 bits per digit, the same as Hexadecimal.
Using bits implies a power of 2, thus, as others have said you can't easily shohorn 10 bits into bytes without wastage. A common solution is to use 4 bits as per hexadecimal and waste the 6 states represented as A-F. The interesting bit is doing decimal math with this - it's not neat and simple.
A useful teaching idea might be to compare how Micky Mouse might have developed a counting system, as he only has 4 fingers per hand - which leads naturally to an octal based system.
In base 1024, each symbol is 10 bits. Three decimal digits have the same amount of information as one digit in base 1000, which is slightly less than 1024. Therefore, a decimal digit has slightly less than 10/3 bits. This approximation gives 3.333333..., while the exact number is 3.321928...
This might be an oversimplification but it depends on which question you are asking.
(and the answer is basically octal or hex)
I also don't consider fractional bits as bits because in practical usage bits don't have fractions.
Q1: How many bits can you represent in a decimal digit?
A1: You can represent 3 bits of information in a single decimal digit:
The most common scheme would be straight binary with wrapping where 0=8=000 and 1=9=001. But you could use any scheme there is nothing that says this is the only way to encode bits into decimal digits.
or
Q2: How many bits does it take to represent a decimal digit?
A2: You need at least 4 bits to represent all decimal digits. With some waste or wrapping.
Again the most common scheme would be straight binary with wrapping but you could use any other scheme.
Disclaimer - I'm not an information theorist, just a code monkey who works primarily in C and C++ (and thus, with fixed-width types), and my answer is going to be from that particular perspective.
It takes on average 3.2 bits to represent a single decimal digit - 0 through 7 can be represented in 3 bits, while 8 and 9 require 4. (8*3 + 2*4)/10 == 3.21.
This is less useful than it sounds. For one thing, you obviously don't have fractions of a bit. For another, if you're using native integer types (i.e., not BCD or BigInt), you're not storing values as a sequence of decimal digits (or their binary equivalents). An 8 bit type can store some values that take up to 3 decimal digits, but you can't represent all 3-decimal-digit values in 8 bits - the range is [0..255]. You cannot represent the values [256..999] in only 8 bits.
When we're talking about values, we'll use decimal if the application expects it (e.g., a digital banking application). When we're talking about bits, we'll usually use hex or binary (I almost never use octal since I work on systems that use 8-bit bytes and 32-bit words, which aren't divisible by 3).
Values expressed in decimal don't map cleanly on to binary sequences. Take the decimal value 255. The binary equivalents of each digit would be 010, 101, 101. Yet, the binary representation of the value 255 is 11111111. There's simply no correspondence between any of the decimal digits in the value to the binary sequence. But there is a direct correspondence with hex digits - F == 1111, so that value can be represented as FF in hex.
If you're on a system where 9-bit bytes and 36-bit words are the norm, then octal makes more sense since bits group naturally into threes.
If I were teaching this, I would first explain what a number (expressed as a series of digits means). i.e., from right to left, assuming base n, a * n^0 + b * n^1 + c * n ^2 ... z * n^y.
Then explain that 10^3 is approximately equal to 2 ^ 10. It is not exact and is the reason in computers, we often do not know what 2k really means (is it 2,000 or 2,048?) It serves fairly well for quick approximations. 2^16 is about 2 ^ (16 - 10) * 1,000, or 2^6 (64) * 1,000 or 64,000. In reality, it is 65,536, but if you don't mind being off around a percent, it works fairly well for quick approximations.
