Stephan van Hulst wrote:Welcome to CodeRanch!
You can generate combinations lazily using streams relatively easily, assuming that your list of lists is not too long.
Does your list of lists always have a fixed length (meaning, are the resulting combinations a fixed length) or is the length determined dynamically?
Campbell Ritchie wrote:Please explain more. What sort of objects do you mean? What does it mean that you are using Integers instead?
There are three kinds of actuaries: those who can count, and those who can't.
There are three kinds of actuaries: those who can count, and those who can't.
There are three kinds of actuaries: those who can count, and those who can't.
There are three kinds of actuaries: those who can count, and those who can't.
Piet Souris wrote:No multithreading
There are three kinds of actuaries: those who can count, and those who can't.
Tim Moores wrote:For this kind of problem, and given the small data volume involved, I doubt that using multithreading would provide a noticeable speedup anyway.
Sot Nikele wrote: I have to add that I don't want to save the combinations in a new List, because there are millions of combinations. Just need to iterate through all combinations very fast.
There are three kinds of actuaries: those who can count, and those who can't.
Piet Souris wrote:
In that last case, an idea to save a lot of space is not to store a succesful combination, but an integer that denotes that combination. For instance, if we have the lists {(1, 2), (a, b, c)} then (1, a) has index 0, (1, b) has index 1, (1, c) 2, and (2, c) has index 5.
There are three kinds of actuaries: those who can count, and those who can't.
There are three kinds of actuaries: those who can count, and those who can't.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |