[WORK] groupBy is in! Next: aggregate

[MattCoder via Digitalmars-d]

On Friday, 23 January 2015 at 22:20:19 UTC, H. S. Teoh wrote:
> It's kind of a misnomer, because it actually only considers 
> *consecutive
> runs* of equivalent elements; it doesn't look at the whole 
> range before
> deciding what goes in which group. So technically it should be 
> called
> consecutiveGroupBy or consecutivePartitionBy, but that's too 
> big a
> mouthful to be a usable name.
>
> What you describe could be an interesting candidate to add, 
> though. It
> could iterate over distinct values of the predicate, and 
> traverse the
> forward range (input ranges obviously can't work unless you 
> allocate,
> which makes it no longer lazy) each time. This, however, has 
> O(n*k)
> complexity where k is the number of distinct predicate values. 
> If it's
> anything bigger than bool or a relatively small enum, it would 
> be
> impractical. Moreover, the requirement to traverse the range 
> multiple
> times kinda sux; you might as well just call filter() with 
> different
> expected values yourself, in a loop. In fact, you could 
> ostensibly
> implement it something along these lines:
>
> 	auto globalPartition(alias pred, R)(R range) {
> 		alias Values = typeof(pred(range.front, range.front));
>
> 		return iota(Values.min, Values.max)
> 			.map!(v => range.save.filter!(pred(e) == v));
> 	}
>...

Alright and thanks for the whole explanation.

Matheus.