On Thu, Jan 16, 2014 at 5:44 AM, spir <denis.s...@gmail.com> wrote: > 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.
Hmmm. My guess is you're reaching for a teachable moment here... I ended up leaving this entire approach behind, for what I think is your point: I can simply iterate through the combinations and test them before I even get to the next one. Sadly, this didn't nearly address my problem, which I think is that my solution set is still ending up N^2 time on a rather large data set. Danny offered a different approach entirely, which I haven't implemented. I THINK that I optimized this approach by not using any lists, testing iterations as they were generated, changing my data order so I generate shorter combinations first, and I STILL couldn't get past something like the first 3 coins out of 8. It's all good, I learned a lot in the process. -- Keith _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
