LINQ Farm: More on the LINQ Aggregate Operators

DotNetKicks.com — Fri, 25 Jul 2008 03:54:11 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Clarifying the semantics of ICollection.Count

Jonathan Pryor — Fri, 25 Jul 2008 18:08:21 GMT

Would it be possible to clarify the semantics of ICollection<T>.Count for collections with more than int.MaxValue elements? If we required that ICollection<T>.Count throw an InvalidOperationException or something if the collection size was too large, then the Enumerate.LongCount() extension method could rely on ICollection<T>.Count for collections with fewer than int.MaxValue elements, e.g.:

public static long LongCount<T> (this IEnumerable<T> source)

{

ICollection<T> c = source as ICollection<T>;

if (c != null) {

try { return c.Count; }

catch { /* ignore; manually count elements */ }

}

long n = 0;

foreach (var e in source) ++n;

return n;

}

(Note: the above misses a potential optimization for when `source` is a T[], in which Array.LongLength can be used directly; it is merely provided for discussion purposes.)

Not only could this vastly increase the performance of LongCount() in the majority of cases (how often do you have collections with more than int.MaxValue elements?), but it's already possible _now_ for collection types to have more than int.MaxValue items -- LinkedList<T> should be able to store as many items as memory permits (which is quite a bit on 64-bit platforms), yet it also provides ICollection<T>.Count. What should ICollection<T>.Count do when it has more than int.MaxValue items?

I can't speak for .NET here, but I know that Mono's LinkedList<T> source will in fact wrap around if you add more int.MaxValue+1 items, so ICollection<T>.Count will return int.MinValue, which can't be good/sensible/sane for any client code. (Even more bizarrely, if you add uint.MaxValue+1 items, .Count will return 0 -- the joys of integer math.)

Fixing the LINQ samples

Valkyrie-MT — Wed, 30 Jul 2008 16:51:14 GMT

Charlie, this is a bit off topic, but I saw that you used Enumerable.Range and it reminded me of my first encounter with this and how frustrated I was trying to get the example from the LINQ 101 samples to work because they use the old Sequence.Range instead of Enumerable.Range. Can you ask someone to fix it because it is still out of date...

Thanks!

re: LINQ Farm: More on the LINQ Aggregate Operators

pkellner — Sat, 02 Aug 2008 05:18:07 GMT

Nice article. Great to see aggregate's explained so clearly and with good examples.

Know When to Fold

Cay Horstmann's Blog — Mon, 06 Oct 2008 06:26:54 GMT

I demonstrate the usefulness of the nifty "fold" operator in Scala and ruminate on functional programming support in blue collar languages.

re: LINQ Farm: More on the LINQ Aggregate Operators

Sam — Thu, 29 Oct 2009 16:27:30 GMT

Given a list of items, you showed how to get a min value with LE as follows.

items.Min(l => l.Length).

This is good so far.

But how do we use LINQ and LE to get THE ITEM with min length and not the value of min length as you showed?

Basically how do you fill in the question marks here?

Item lItemWithMinLength = items.???

Thanks! I'd appreciate it your answer on this one.

re: LINQ Farm: More on the LINQ Aggregate Operators

John Lin — Thu, 12 Nov 2009 04:29:42 GMT

Try this:

items.Aggregate((a,b) => a.Length < b.Length? a : b);