[Tutor] problem solving with lists

[dn]

On 21/03/2022 21.51, marcus.luetolf at bluewin.ch wrote:
> ...yes, the weekly Draws below  are exactly what I have in mind !!!
> And I realised earlier that "I asked the wrong questions". But with your
> Cooments about the solution I think I can find a solution myself. 
> It was never my intention to let tutor do my "homework", I had learned nothing.
> Thanks, Marcus.

Excellent news!

Keep going! (here)

Follow earlier suggestions of defining meaningful terminology by first
writing (specifying) the problem, as completely as you can. All those
detailed clauses, as we say in English: "the if-s, the but-s, and the
maybe-s" are the details which cause trips and stumbles.

A lot of programmers rush to start coding. The above is well-worth
spending the time - and if the spec[ification] has come from someone
else (as it would in a commercial environment), this is where we find,
as early as possible, that the client hasn't given us the full-story!

As you say, the key to it all is to ask the 'right' questions and
document the requirements and 'rules'.

Once the problem is clearly understood, we can start looking for
solutions. Often there is more than one, and certainly more than one way
to approach building a solution.

These are the major steps of "program[me] design". Again, it is worth
checking and re-checking, because errors caught early in the development
process are cheaper (time and/or $) to fix, than those not realised
until later. Thus, the completed work described earlier was a second,
and longer, version of the first - so a complete re-write became
necessary because I did not understand what was needed!

Now you understand why there was evidence of frustration in the way
people were replying to you!


Next try to break-up the chosen solution into stages or phases. In this
case, I think of a League (or competition) which will take
(number_of_weeks) five weeks before all 'unique' combinations of players
can be played. Each week requires its own "draw", which will consist of
(number_of_groupings) four groups of players. Each group of players will
consist of (players_per_grouping) four players - who have never played
with each-other before (in this league/competition).

You can see that the overall solution consists of sub-solutions to
sub-problems. It's a bit like those inter-locking Russian dolls, or
(?Swiss) chocolates with a center and multiple layers/flavors inside a
hard chocolate coating. We also refer to it as like an onion. This
approach to problem-solving is called "stepwise decomposition" (or "-
refinement). It is the process of dividing a large problem into smaller
problems, and those into smaller... until the small problem is one that
is easy to solve.

The beauty of this is that if you have a correct and sensible design
(easily said, not so easily done!), it should be possible to write and
test (or 'prove') each 'unit' or sub-solution of the code, by itself -
which is a good deal easier than trying to test the whole 'onion' and
not being sure where some failure or error is caused within the mass of
code! What happens when you have to cut-up a (real) onion?

I tend to code each 'layer' as a function. Indeed after choosing the
name of the function (and writing the def ... line), I'll add a
docstring which is basically that section of the 'design' (from
earlier). I'll repeat this until the whole problem has been covered.
Only then, do I sit down to start writing code for the smallest of the
sub-solutions (or, the inner-most layer of the onion/chocolate).


Now, to help you on your way, here are a few other data-structures which
I used:

weekly_draws = list()

- to hold the [five] weeks' draws
- perhaps only necessary if you're going to do something with this data
(I was only printing it out)

player_history = { player:{ player } for player in players }

- to hold the set of players who this player has previously played
- rather than complicating loop-controls (or maybe adding lots of
one-time if-conditions) within the code, it seemed easier to initialise
each player's set with him-/her-self - after all, under the 'rules' you
cannot play someone you've already played, nor can you play yourself.
(two 'rules' for the price of one!)
- this 'one-liner' code-construction is called a "set-comprehension" and
I very rarely see/use one - whereas their close-relatives,
"list-comprehensions", are very common.


If you'd like to post your sub-solutions (text-design, plus
Python-code), we'll be happy to help you along...
-- 
Regards,
=dn