[Tutor] problem solving with lists

dn PythonList at DancesWithMice.info
Fri Mar 25 00:26:35 EDT 2022


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


More information about the Tutor mailing list