[Tutor] problem solving with lists

[dn]

On 25/03/2022 04.41, Dennis Lee Bieber wrote:
> On Wed, 23 Mar 2022 20:54:01 +0100, <marcus.luetolf at bluewin.ch> declaimed
> the following:
...

> 	And again you are back to where the only data structure to be used for
> everything is a LIST.
> 
> 	Keep your players as a string. Think of your "team" as a unit, made out
> of a string.
> 
> 	Strings are indexable -- the syntax looks just like what you'd use with
> a list of 1-char strings).

+1
Whereas I disagree with people using single-letter identifiers (for
example), sample-data has very little meaning and little impact on the
overall result.

Another angle to the point is that it is a lot easier to scan a line of
letters, or in groups of four, both for omissions and for duplications,
than it is to scan a list of letters (because of all those
apostrophes/single-quotation marks)! Certainly to these old eyes...

In this case, once the code is tested and working, it is an easy change
to 'upgrade' from single-letter strings, to proper names of people.


>>> for day_1 :
>>> ° create 4 lists named team_lists, containing 4 subsequent letters/players
>>> 	by iterating over every 4th letter/player
>>> 	identifying its indices in players_list (0, 4, 8, 12)
>>>             list/print  team_lists of 4 subsequent Letters/elements each starting
>>>                  at every 4th letter/player in players_list
>>> ° assign all 4 letter/player of  the first team lists as lead_player (‘a’, ‘b’, ‘c’, ‘d’)
> 
> 	Since you are defining a on-off process, and not something programmatic
> (that is -- there is nothing in the above that can be CHANGED from run to
> run), you might as well hard-code this step.
> 
>>>> day1 = [ pch[0:4], pch[4:8], pch[8:12], pch[12:16] ]
>>>> day1
> ['abcd', 'efgh', 'ijkl', 'mnop']


Am not sure about this - as a tactic - can't/won't argue with the logic!

The solution is going to require a series of nested iterations (outlined
earlier). These will produce the 'alphabetic' first week's groups as a
matter of course.

Thus, stating the first week's 'solution' as a constant/taken as read/a
natural part of the process is reasonable, but the code for every week
thereafter then has to include logic (or 'magic constants') which
enables the first week to be 'different', ie an exception to the norm.

The same result will be printed, either way!

NB I recall that my code includes a 'special' function to select the
first player in each new group (as distinct from the second, third, ...
number of players in each group) - so sit back and count my two faces!


Further, if we consider that arranging players into a logical order,
before selection, is also a likely and 'natural' approach; this would
seem to imply that every time they enter a tournament, 'a' and 'b' will
play each other in the first game. That may not be a good thing! (may
not even be seen as "fair" - by those who don't think in statistics)

Accordingly, I'm wondering how 'expensive' it would be to 'throw' all
the player's names into a 'pool' and make repeated random drawings to
form the groupings? Each such selection, will either be 'accepted' if
the player may be added to the group currently being constructed, or
'rejecting' if the player is not suitable/permitted to be added (and
returning to the 'pool').

Yes, each 'rejection' would be a cost with no benefit, and the ratio of
rejections to acceptances will grow ~exponentially week-by-week...

This is the way kids typically separate themselves into teams for a
'pick up' game (of whatever sport), there's no concept of taking 'from
left to right' - except for the (proposed) randomisation of selection,
rather than kids using previous-knowledge or assessing 'looks like might
be a good player'.


Yes, I so like the 'story' - but...it would be so much easier/cheaper to
take the original-string/list of names, as produced by the tournament
organisers, and at the beginning of the program[me] rearrange it into a
random sequence!
-- 
Regards,
=dn