Talk:Balanced ternary

re: draft task, because NevilleDNZ liked it so much

Many ThanX ;-) I confess that I might be a Nerd at heart and as I find it hard resist solving an especially annoying puzzle.

But now I have a hammer, where is the nail? An actual "real world" test case would be really sweet! Ironically I have yet to think of one. Ideas are invited...

e.g. from Wikipedia's Balanced ternary page: For example, a classical "2-pan" balance, with one weight for each power of 3, can weigh relatively heavy objects accurately with a small number of weights, by moving weights between the two pans and the table. For example, with weights for each power of 3 through 81, a 60-gram object (60₁₀ = 11110) will be balanced perfectly with an 81 gram weight in the other pan, the 27 gram weight in its own pan, the 9 gram weight in the other pan, the 3 gram weight in its own pan, and the 1 gram weight set aside. This is an optimal solution in terms of the number of weights needed to weigh any object.

NevilleDNZ 04:44, 1 November 2011 (UTC)

Test case discussion

Floating point test case: With balanced ternaries a from string "+-0++0+.+-0++0+", b from native integer -436.436, c "+-++-.+-++-":

write out a, b and c in decimal notation;
calculate a × (b − c), write out the result in both ternary and decimal notations.

NevilleDNZ 04:52, 1 November 2011 (UTC)

Eh that's asking for a lot of trouble. -436.436 decimal doesn't actually termintate in base 3. --Ledrug 04:59, 1 November 2011 (UTC)

I suspect that "+-0++0+.+-0++0+" and "+-++-.+-++-" in decimal don't terminate either. /* In for a penny, in for a £... ;-) */ Maybe the precision could be user defined, and set at about 81 digits after the point for the test case? NevilleDNZ 05:15, 1 November 2011 (UTC)

A floating point involves too many things. Seemingly simple stuff like "0.1" has no exact finite representation in either base 2 (IEEE) or base 3, thus the meaning of "436.436" in a task requirement is dubious to begin with: Rdm will come along and bury me with questions, so I'd rather not do that.

We could dodge this issue by limiting digit length after decimal point, which is essentially treating them as rationals, then we'd have different problems: either we don't cancel out common factors in numerator and denominator, which is obviously unsatisfactory; or we do cancel them out, which requires division and modulo, which would be difficult and long-winded. I don't want to make the task require more effort than necessary. In any event, if the task proves to be so popular that people flock to it like hot cakes (I doubt it), one could always make another task to extend it to floating point numbers. --Ledrug 16:42, 1 November 2011 (UTC)