Earlier quoted context omitted.
There's actually this really clever emulation you can do where you don't blindly use two bits per trit, but fractionally pack the trits into bits such that you don't end up with any wasted bits. This has the further advantage that since it produces the same inputs and outputs as binary encoding that you can use the native binary hardware on the CPU to do all your math. Because it is the native binary encoding. One of…
I guess I shouldn't be surprised that you can use a clever encoding to work with trits natively but "clever encodings to pack trits" seems like something of an antifeature when we're talking about anything within a mile of cryptography...
It is possible to sit down and work it all out on paper, and you can work out how many trits using logarithms you can pack into a given number of bits, etc etc., but all the terms will cancel and the math will tell you that you just end up with binary again. You can end up with quite the table explaining how to add "binary-encoded base-3" numbers together if you insist on holding on to the idea that base-3 numbers somehow exist separately from base-2 numbers, but in the end it'll all just cancel out. You can get some idea of what it would look like, and how silly it would be, if we trained people to add numbers together by first converting them into binary, adding them in binary, and then converting back to decimal, since that would be the same thing, just with different bases, but does capture how inconvenient it is to do math that way when your bases can't be translated via lookup table (i.e., hexadecimal binary can be done mechanically on a string basis for the number, unlike 2 3 or 2 10 (thanks to the factor of 5 in the 10)). And then imagine that as we are teaching people that maneuver that we are telling them that the binary-encoded representation is the real number, and the base-10 encoding is a fake number that can't be trusted or used the same way.