On 2025-12-08 at 18:57:34 -0500,
Thomas Passin <[email protected]> wrote:
> On 12/8/2025 6:16 PM, MRAB wrote:
> > On 08/12/2025 21:18, Thomas Passin wrote:
[...]
> > There's another way of determining who won.
> >
> > Give each of the choices a value, such as:
> >
> > OPTION_VALUES = {ROCK: 0, PAPER: 1, SCISSORS: 2}
> >
> > Look at the difference between the values of what the bot chose and what
> > the player chose.
> >
> > There are 5 possible differences, from -2 to +2.
> >
> > From that difference you can determine who won or whether it's a tie.
>
> Sure, there are lots of possibilities. Using a little arithmetic would be
> nice and concise and well-suited to a C program or even assembler. It's
> mostly personal taste, and mine is to make the program easy to write and
> later on, read.
I, for one, appreciate (if not revel in) concise, elegant, and superior
algorithms. Bubble and Insertion sorts are easy to write and easy to
read; QuickSort, Gap Sort, and a plethora of others are better sorting
algorithms (although on this list, I have no doubt that someone will
present a specific use case (or an entire class of use cases) in which
Bubble Sort is the most appropriate sorting algorithm).
Has the art of documentation been lost? What about maintainability?
Explain the arithmetic in plain English (or some other language) in a
comment. Take the time to lay out an exhaustive matrix. Set a good
example, not to mention the groundwork for future maintainers (even if
that only means you) to be enlightened (or to have a flash of insight
triggered by a novel solution to an old problem).
The rules of Rock, Paper, Scissors are unlikely to change (Rock, Paper,
Scissors, Lizard, Spock notwithstanding) over time, so there is little
chance that such a comment will fall out of sync with the code.
Hang on... How did that used to go? Oh, yeah....
Not As Jokingly As You Think'ly Yours,
Dan
--
https://mail.python.org/mailman3//lists/python-list.python.org
