To expound upon my question as mentioned in the title, I am researching, out of curiosity, what the implications of a (balanced) ternary based computer would be, besides obvious things such as greater "density" of information. Clearly, ternary operators would be "easier" to implement, or more "natural" if you will, than binary ones. Also, bitwise operations would need to be replaced by tritwise operators. I am aware of the benefits and drawbacks to balanced ternary on the hardware level, but I want to know what that would mean for typical writing programs in a C-level language. Could a C compiler be written for a ternary computer without simply emulating a binary one? If not, how much would a language like C, or even Lisp-like languages need to be altered to take advantage of the balanced ternary system? I'm sort of a noob, so I apologize if I said anything inane as a result. Thanks for answering!
-
1$\begingroup$ Welcome to cstheory, a Q&A site for research-level questions in theoretical computer science (TCS). Your question does not appear to be a research-level question in TCS. Please see the FAQ for more information on what is meant by this and suggestions for sites that might welcome your question. Finally, if your question is closed for being out of scope, and you believe you can edit the question to make it a research-level question, please feel free to do so. Closing is not permanent and questions can be reopened, check the FAQ for more information. $\endgroup$– KavehCommented Nov 25, 2011 at 5:40
-
4$\begingroup$ Why isn't the answer "Obviously none"? $\endgroup$– JeffεCommented Nov 25, 2011 at 15:45
-
$\begingroup$ Isn't it worth treating this question as a question about the asymptotics of division algorithms like I did below? Not exactly research level, but no longer silly. $\endgroup$– Jeff BurdgesCommented Nov 27, 2011 at 23:19
3 Answers
As you know, any language providing bitwise operations like C must introduce additional complexity into the machine code if your n-ary CPU did not offer these operations itself. In other words, either the CPU or the C compiler must provide a couple division algorithms optimized for specific fixed constant denominators.
Interestingly, your C compiler already does this when converting between array indexes and pointer arithmetic. In fact, it tunes the division by constant algorithm at compile time according to sizeof(...) and alignment (pdf).
In other words, there is a small risk the machine code would bloat up in size, and endianness-like issues would suck up more programmer time, but otherwise I double much would change, either for better or worse.
At least one ternary computer was built in 1958, see http://en.wikipedia.org/wiki/Setun, so it's not a completely hypotethical concept. Note that if a new tri-state nanodevice is discovered, ternary computers may be built again.
A computers with exotic number representations can be better suited for special tasks - e.g. for exact real arithmetic, but for most tasks they will be the same to program. The abovementioned Setun was using not usual ternary numbers, but so called http://en.wikipedia.org/wiki/Balanced_ternary which is an interesting representation of signed numbers using negative-valued digits
C's not a terribly good example, because it provides access to many low-level details that, I believe, really assume that the computer is based on binary with 8-bit words.
As a thought exercise, you could add n-ary (what's-the-generalization-of-trit)wise operations into the C language as it exists. As Burdges suggests in his answer, the programmer could reasonably expect that a tritwise operation would be more efficient on the tritwise architecture, and the bitwise operation would be more efficient on the bitwise architecture. But what do you do about sizeof()? To deal with that, you'd probably need an incompatible "ternary C" that has a different sizeof (reporting the size in "trites" or whatever). This wouldn't be terribly difficult, I imagine (at least relative to the difficulty of writing a C compiler, which is hard).
Lisp is a better example, since it abstracts out irrelevant low-level details like the number of bytes in an object's memory representation. I imagine a tertiary Lisp compiler would look nearly the same as a binary Lisp compiler, save for the code emitted when you do bitwise operations.
-
$\begingroup$ You'll remember that "bit" is a portmanteau for "binary digit", so the generalization is simply "digit". $\endgroup$– minopretCommented Apr 12, 2013 at 16:21