On 8/25/13 8:10 AM, Gilles wrote:
> On Sat, 24 Aug 2013 21:55:36 -0000, pste...@apache.org wrote:
>
>> [...]
>
> I wonder whether the utility should involve the creation of
> an instance of a bona fide "Combination" class.
> I.e. instead of a "naked"
> Iterator<int[]> combinationIterator(int n, int k)
> there would be
> Iterator<Combination> combinationIterator(int n, int k)
> where "Combination" would provide an accessor
> public int[] toArray() {
> // ...
> }
I need the "naked arrays" generated very quickly with minimal
overhead for the K-S use case. My use case uses the arrays
directly, but others could use the indices to extract objects from
lists. For example, what I thought would be natural would be to add
public static <T> Iterator<List<T>> combinationsIterator(List<T>
list, int k)
What you would get out of this is element lists. And the
implementation could postpone copy / creation until the indices have
been selected using the existing method. I am not yet sold on the
value of "Combination" as an abstraction, since what you really use
is just the list of selected elements. Cf what [collections] did
for its PermutationIterator.
Phil
>
> The advantage is that "Combination" could also implement
> Comparable<Combination>
> with code similar to the "lexNorm" method defined for the tests.
>
> Or did I miss something?
>
>
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
