Improve GroupAdjacent about morelinq

[jods4]

ah, I had forgotten this :)

What I want can be implemented on top of AggregateAdjacent, if that's what you mean:

IEnumerable<IGrouping<G, E>> GroupByAdjacent<T, K, G, E>(
  this IEnumerable<T> source,
  Func<T, K> key,
  Func<T, G> group,
  Func<T, E> element)
{
  return source.AggregateAdjacent(
    key,
    (k, x) => new Grouping(group(x)),
    (k, g, x) => 
    { 
      g.Add(element(x)); 
      return g; 
    },
    (k, g) => g
  );
}

[atifaziz]

Sorry, but I am having trouble to understand the problem and what you're asking for.

If this is the input:

aKey
a1
a2
a3
b1
b2
b3

What do you expect the output to be?

[jods4]

Basically, I added this to my project. It's a slightly less efficient way of doing Proposed Solution 1:

IEnumerable<IGrouping<G, E>> GroupAdjacent<T, K, G, E>(
  this IEnumerable<T> source,
  Func<T, K> key,
  Func<T, G> group,
  Func<T, E> element)
{
  K cachedKey = default;
  G cachedGroup = default;
  return source.GroupAdjacent(
    x => 
    {
      var nextKey = key(x);
      if (nextKey != cachedKey || cachedGroup is null)
        (cachedKey, cachedGroup) = (nextKey, group(x));
      return cachedGroup;
    },
    element
}

The key point is that I don't want to create a G instance for every item in the source enumeration, only once per group.

[atifaziz]

Thanks for sharing the code. It helps to understand the mechanics a bit. So if the grouped elements were exposed as a list instead of a sequence, like your proposed solution 2, then it would solve your problem?

GroupAdjacent signatures were modeled after GroupBy, which is why the group elements are typed as IEnumerable<>.

[jods4]

Yes, if GroupAdjacent exposed IList we could efficiently build the groups by peeking elements[0]. (Proposed Solution 2).

I like Proposed Solution 1 a little more because it's simpler on consumer side. With Solution 2 consumer has to take care of the IGrouping construction.

Independently of Solution 1 or 2: if buffering is not an implementation detail that will change, MoreLinq might as well expose IList. It opens up more flexibility to efficiently consume GroupAdjacent results on the consumer side.

I think it's fair to commit to buffering, because streaming is a valuable alternative but it comes with strict constraints on the way you consume it.
For instance, you can't enumerate one group elements anymore after you've moved to the next group. And you can only enumerate once.
For these reasons, a non-buffering implementation would IMHO have to be offered by a new API.

[atifaziz]

Thanks for the clarifications.

I think we've been down this road before, meaning that what you want here is (more generally speaking) AggregateAdjacent?

[atifaziz]

@jods4 Yes, that's it!

[viceroypenguin]

What about the following with the existing api:

seq.GroupAdjacent(
  x => (x.aKey, x.a1, x.a2, x.a3),
  x => new B(x.b1, x.b2, x.b3),
  (k, g) => (new A(k.aKey, k.a1, k.a2, k.a3), g));

Unless a1, a2, or a3 are non-comparable, this will work fine.

[jods4]

@viceroypenguin
Minor point: I have more a_n properties than I want to copy each iteration (ValueTuple is a struct)...
Major point: MoreLinq would then compare all a_n (default struct comparison) for each element, I want to compare aKey only.