Would an aggregation pattern fit into Guava?

[Emily Soldal]

The past year and a bit I've found myself taking advantage of an aggregation pattern I would like to see in Guava but I'm not entierly possitive on how it should be implemented.

Iterable<Iterable<T>> aggregate = Iterables.aggregate(Iterable<T>, Equivalence<T>) 

or 

Iterable<Iterable<T>> aggregate = Iterables.aggregate(Iterable<T>, Comparator<T>)  

This would return an iterable view containing chunks of the underlying iterable which evaluate as similar with the supplied Equivalence or Comparator. This has been phenomenally useful for me in reducing the amount of complexity I have to deal with.

[Gregory Kick]

So, Multimaps.index() is pretty close.  Could your Equvialences and Comparators be traded for Functions<T, K>s?

--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")

--
Greg Kick
Java Core Libraries Team

[Emily Soldal]

I see what you mean, although I don't think that would work. How would you decide what K should be? 

[Torbjorn Gannholm]

On Fri, Apr 20, 2012 at 11:46 AM, Emily Soldal <em...@soldal.org> wrote:

I see what you mean, although I don't think that would work. How would you decide what K should be? 

The identityHashCode of the Comparator, perhaps?
 

On Friday, 20 April 2012 11:42:58 UTC+2, Gregory Kick wrote:

So, Multimaps.index() is pretty close.  Could your Equvialences and Comparators be traded for Functions<T, K>s?

[Kevin Bourrillion]

I always suspected in the back of my mind we'd need this, but over the years, every time it's come up so far, index() has turned out to be fine.  So can we have some more fleshed-out code examples that illustrate the need?

--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")

--
Kevin Bourrillion @ Google

Java Core Libraries Team
http://guava-libraries.googlecode.com

[Emily Soldal]

I can whip something up. I'm almost tempted to say this method should be called chunk() rather than aggregate though. The reason being that I'd rather not do any sorting before hand, if its named chunk() then it explains how it divides the underlying Iterable into sections along the boundaries defined by the comparator/equivalence.

[Kevin Bourrillion]

Check out http://code.google.com/p/guava-libraries/issues/detail?id=521 also.

[Emily Soldal]

Oh I like the idea of a Partition. It would also compliment nicely with Iterables.partition(Iterable,int) to be able to supply Iterables.partition(Iterable,Comparator) or Iterables.partition(Iterable.Partition.from(Comparator))

This hinges on making a complimentary Partition class of course

[Kevin Bourrillion]

imho, it just presents a further argument why the existing Iterables.partition() shouldn't be called partition at all. :-(

[Emily Soldal]

I'm quite happy with it being named partition and wouldn't mind seeing some of the following additions to it either:

Iterables.partition(Iterable,Comparator);

Iterables.partition(Iterable,Equivalence);

Iterables.partition(Iterable,Partition);

Iterables.partition(Iterable<? extends Comparable>);

But perhaps thats a bit off topic. What are the reasons for calling it something else? And if a Partition class is required for DisjointSet it makes sense that it should work for this too but I'm not entierly sure how it should behave. I don't  think DisjointSet overlaps with this proposal in terms of functionality because partition preserves both order and multiplicity.

[Emily Soldal]

*bump*

I'm happy to open an issue and complete this myself, name not withstanding ofcourse. 

[Louis Wasserman]

I guess I'd feel a lot happier with half a dozen real-world use cases where we could compare APIs side by side and see what the different code would look like.  This doesn't strike me as a trivial API design problem.

Louis Wasserman
wasserm...@gmail.com
http://profiles.google.com/wasserman.louis

[Emily Soldal]

Places where you might find aggregation patterns in disguise:

* Where MultiMap.index().asMap().values() is used twice and where the actual map isn't used but rather the indexing ability.

* Optimization of compound-key queries on large data, some form of equivalence or grouping will likely be used to reduce complexity in each query, eliminating as many variables as possible.

* Looking for sequences of like elements in a collection without concatonating all like elements; think of checks done in a loop looking for similarities between the current value and some previous value.