[Tutor] problem solving with lists, coding problems

Wed Apr 6 14:43:14 EDT 2022

Hello Experts again,
after a break  I've resumed my task and broken up my problem into several
steps  folowing your advises below but I'm running now into coding problems:

In my first step to draw players for the 4 tflights/sublists for day_1
(instead of week_1) I was to create a player_history  beginning with the
first player ('a')
oft he first flight/sublist ( (player_history_a).
 Using set comprehension as mentioned in your text below a dictionary was
returned:
> player_history_a:  {'a': {'a'}, 'b': {'b'}, 'c': {'c'}, 'd': {'d'}}

I expected:  player_history_a:  {'a': { 'b', 'c', 'd'}}, so I got something
wrong.

My code (not having it converted to a function yet): 

>all_players = list('abcdefghijklmnop')  # this variable as a string throws
errors
>c_all_players = all_players[:]

>flight_1_day_1 = []
>flight_2_day_1 = []
>flight_3_day_1 = []
>flight_4_day_1 = []

>for player in c_all_players[0:4]:
>    flight_1_day_1.append(player)
>    player_history_a = {player:{player} for player in flight_1_day_1}
>print('player_history_a: ',player_history_a)         
>del c_all_players[0:4]

>for player in c_all_players[0:4]:
>    flight_2_day_1.append(player)
>del c_all_players[0:4]

>for player in c_all_players[0:4]:
>    flight_3_day_1.append(player)
>del c_all_players[0:4]

>for player in c_all_players[0:4]:
>    flight_4_day_1.append(player)

>print('flight_1_day_1: ', flight_1_day_1)
>print('flight_2_day_1: ', flight_2_day_1)
>print('flight_3_day_1: ', flight_3_day_1)
>print('flight_4_day_1: ', flight_4_day_1)

So,please  where is my error ?

Regards, Marcus.

-----Ursprüngliche Nachricht-----
Von: Tutor <tutor-bounces+marcus.luetolf=bluewin.ch at python.org> Im Auftrag
von dn
Gesendet: Montag, 21. März 2022 11:14
An: tutor at python.org
Betreff: Re: [Tutor] problem solving with lists

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
_______________________________________________
Tutor maillist  -  Tutor at python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor