[Tutor] lambdas, generators, and the like

[spir]

On 01/12/2014 10:04 AM, Keith Winston wrote:
> I've got this line:
>
> for k in range(len(tcombo)):
>      tcombo_ep.append(list(combinations(tcombo, k+1)))
>
> generating every possible length combination of tcombo. I then test
> them, and throw most of them away. I need to do this differently, it
> gets way too big (crashes my computer).
>
> I'm going to play some more, but I think I need to test the
> combinations as they're generated... and then only add them to a list
> (probably better: a set) if they meet a requirement (something like
> sum(specific.combination(tcombo) == goal)) AND if they are not already
> part of that list (the uniqueness issue is why a set might be better)
>
> I'm partially asking in order to clarify the question in my mind, but
> any help will be appreciated. I don't really understand lambda
> functions yet, but I can sort of imagine they might work here
> somehow... or not.

You say yourself that, on the application side, the semantics are that relevant 
items (individual combinations) are a subset of the ones otherwise produced, 
right? Thus they are conceptually the output of a *filter*. Whether they are 
stored (in a list --> list comprehension) or directly processed (from a 
generator --> generator expression), you should only ever deal with the relevant 
ones.

       production                filter
data     --->     combinations   --->   [storage] usage

If the filter's criterion is 'crit':
	combs = (comb for comb in combinations(tcombo, k+1)) if crit(comb))

This, in addition to the requirement of uniqueness which as you say is probably 
best met using a set (after filter). This may lead to you chosing to store, even 
if otherwise not truely necessary. An question is: what kind of data are 
combinations, and how do you compare them? If there is a possibly cheap shortcut 
by comparing only a little bit of combination data, then you may make a set of 
those little bits only and avoid storing the whole of combinations.

Denis