Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The article suggests that using binary digits (0, 1) is the most efficient means of communication. I think I've heard something to this effect elsewhere. Why is that? Wouldn't a tertiary digit (0, 1, 2) be more efficient? An a quaternary digit (0, 1, 2, 3) be even more so? At some point noise would make it difficult to distinguish between the states, but I would think that it would be most efficient to use a digit that has a certain number of states with relationship to the noise floor. (More noise, fewer digits; in the case of no noise, analog would be most efficient. Although I guess by this argument, no noise would imply infinite capacity, which either means that there's a problem with my argument or it is a reason why noise must exist) Am I missing something?


Base 3 encoded messages are shorter because this base is closer to the number e (2.718). Binary is the next best approximation, but easier to understand. I want to believe that DNA is encoded in base 4 because it provides more redundancy.


Technically, yes. I think what you're getting at is called "Radix Economy" (https://en.wikipedia.org/wiki/Radix_economy)

Ternary is the most efficient (integer) base, and binary and quaternary follow. It drops from there pretty quickly. The explanation I've always heard is it's dramatically easier to deal with two-state electronics.

Further reading: https://sweis.medium.com/revisiting-radix-economy-8f642d9f3c...


This is surprising to me because of the use of quadrature amplitude modulation in wireless communication, which uses 2^n quadrature states. Of course these states encode groups of n bits, but the thing actually getting transmitted over the channel has many more than two states. I haven't read this article yet though, I'm probably missing something.


1 is the smallest n such that n > 0 i.e. can be used to transmit information.

If you had something where you could represent base-whatever as easily as binary then it would be (naively) more efficient, but we don't.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: