On 12/8/2025 8:14 PM, Dan Sommers wrote:
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).
There's a time and a place, right? If one needs very good performance,
not all sorts are equivalent. An efficient, elegant algorithm well
executed can be essential and its elegance to be appreciated. In this
(and so many others), the highest performance is not required, so other
considerations can potentially carry more weight.
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).
Documentation is good, code that is clear enough to be fairly
self-documenting is better. Again, use what's needed where it is needed.
There are well-known drawbacks to documentation: keeping it in sync, and
getting people to read it. But let's not try to lay too much on our OP,
who has been struggling a little bit here.
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
