[Tutor] problem solving with lists

[marcus.luetolf at bluewin.ch]

Thanks, very helpfull.
Two points I don't understand:
1. in your 4th and  inner loop " select /p/ from (pg * g) players" what does
(pg * g) mean ? the value for pg is 4 but g should initially be an empty
list or set ???
    If I use combinations() I get 1820 lists or sets out of 16 players and
sg = 4.
2. in sets there is no order. If I use sets instead of lists how could I
find/reject sets with equal pairings of elements ?
Regards, Marcus.


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

On 25/03/2022 06.26, Dennis Lee Bieber wrote:
> On Thu, 24 Mar 2022 11:41:45 -0400, Dennis Lee Bieber 
> <wlfraed at ix.netcom.com> declaimed the following:
...

> you should be thinking of using SET as a data structure.

+1


> 	You state you are trying to come up with an algorithm, but your 
> description is always at the level of implementation at the low-level 
> of the language itself -- and you have already defined a one-use 
> implementation.
> 
> 	An algorithm would be something like:
> 
> {	
> 	/w/ 	<= a week
> 	/nw/	<= number of weeks
> 	/g/		<= a group
> 	/ng/	<= number of groups
> 	/pg/	<= player in group
> 	/sg/	<= size of group
> 	/p/		<= a player
> }
> 	for each /w/ in /nw/ weeks
> 		for each /g/ in /ng/ groups 
> 			for each /pg/ in  /sg/ players-in-group
> 				select /p/ from (pg * g) players
> 					such that /p/ is only selected once
in the current week
> 					AND
> 					any pair of /p/ in /pg/ does not
appear in any prior week's 
> groups

Except use descriptive names inside the algorithm/code rather than
abbreviations!


> 	At an implementation level -- .combinations() does most of the 
> 		for each /pg/ ...
> 			select /p/ ...
> in that it will return /sg/ size groups of /p/, and within the group, 
> there are no duplicates. You are still responsible for testing that 
> they are unique across the groups in each week (that means rejecting 
> many of the groups that .combinations() will provide). If you use set 
> logic, you don't even have to index the members within each group.

Maybe it comes down to @Dennis' brain working differently/better than my
own, or even a matter of taste, but...

The outer-loop (weeks) is constructed gradually.
The next loop (groups) is constructed gradually.
The next loop (players into a group) is constructed gradually.
The inner-loop (player) is constructed gradually.

Whereas substituting the two inner-most loops for:

    itertools.combinations(players, nr_of_players_in_a_group)

and then having to reject some combinations because they fail either/both of
the selection rules, is subtractive (cf constructive).

The combinations-implementation makes sense to people with statistics
knowledge/skills. For example, we recognise the difference between a
"combination" and a "permutation" - even though that significance is not
readily-apparent in every-day English-language usage. Should we
expect/demand that of 'the average programmer'? In a statistics-oriented
team, "yes". In a business team? Probably not!

Speaking personally, I'd be happy to see the solution and read the code
expressed, either way. However, if 'readability' becomes a deciding-factor,
the 'consistency' of the first implementation of the algorithm, is likely to
be preferred.

(Hey, maybe I'm becoming a hobgoblin!)
--
--
Regards,
=dn
_______________________________________________
Tutor maillist  -  Tutor at python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor