Posted on 3/12/2010 12:15:07 AM by Justin Etheredge
If you want to learn all about LINQ, first go check out my series on TekPub and then come back here!
So, I blogged a while ago about the LINQ SelectMany operator. The LINQ SelectMany operator is one of the most useful, misunderstood, and underused operators in your LINQ repertoire. In my previous post I gave you a decent idea of what you can do with the LINQ SelectMany operator, but I'm not quite sure that I did a very good job at really showing you how it works. In this post, I want to give you a more visual explanation of the LINQ SelectMany operator, and what it can do for you.
A Visual Explanation of SelectMany
As I said in my previous post about the SelectMany operator, MSDN describes it like this: "Projects each element of a sequence to an IEnumerable<T> and flattens the resulting sequences into one sequence." Again, once you are familiar with SelectMany, this is a great explanation, but it can still be a bit hard to visualize. So, let's see...
1) it takes a sequence:
2) And then it iterates over each element in this sequence:
3) While it is iterating, it projects each element into an IEnumerable<T>:
4) And then flattens the resulting IEnumerables back into a single sequence:
Pretty easy to see now, right? The SelectMany operator allows us to produce a single sequence with 1 to n items for each item in the original sequence. It really allows us to sort-of multiply each item in a sequence, or at least project it into multiple items. If we did something like this with Select then we would end up producing a sequence with multiple sub-sequences, like this:
While this might be useful, it is not exactly what we want in this case. We want a single contiguous sequence which we can then operate on using other LINQ operators.
Different Kinds Of Projections
Remember that all you have to do is get a list from each item in a list. You can do this by accessing a list that is on each item, like this:
Or you could do it by generating a list, for example, what if each item was an integer, we could generate a range based on each number:
Pretty cool, and powerful. It also lets us chain calls to SelectMany, like this:
So basically, it let's you continue to generate n number of sequences, and then combine them all back together. Since each call to SelectMany generates a single sequence, then you can call SelectMany on that resulting sequence and continue to do so as many times as you want.
Summary
While most of the operators in LINQ let you get one output element for each element you have in your sequence, or they let you filter out elements, but SelectMany is the only operator that lets you produce n output elements for each element in your input sequence. This fact opens up all kinds of possibilities with LINQ that otherwise wouldn't be available to you. I hope this helps you out!
Posted on 3/11/2010 11:05:09 AM by Justin Etheredge
You might be thinking, what kind of silly question is that? The census is produced by the government, and everyone knows that the government can't do much of anything correct. Right? Well, today I received in the mail the same letter from the U.S. Census Bureau that people across the net have been decrying for a while now. It is a thin envelope, and inside of it is a letter letting me know that in about a week I will be receiving a census form. At first glance you might think "What a waste! They mailed you a letter to tell you that they were going to mail you something?!" In the immortal words of Tracey Morgan, "That's just crazy!" And at first, it does seem that way, but I think that the truth is a bit more involved.
Continue reading the rest of this post...
Posted on 3/9/2010 8:35:48 AM by Justin Etheredge
As many of you may or may not know, I was the technical editor on Shay Friedman's book "IronRuby Unleashed". I am a huge fan of the Ruby language, and as you probably have guessed, I am also a big fan of the CLR. So when I found out that they were bringing the Ruby language over to the CLR, I was absolutely ecstatic. I spent quite a bit of time with IronRuby, leveraging it for little utilities, exploring a bit, and I even wrote up a fairly popular blog post series about using IronRuby. I was approached about the potential of writing the IronRuby Unleashed book for Sams, but I felt under qualified and way too busy to try to write an entire book on IronRuby. Now that I have the book in my hands, I can firmly say that I was definitely under qualified to write a book on IronRuby. I was amazed at Shay's depth of knowledge on a topic which is so young, as well as his thoroughness in explaining the topic. Shay was more than qualified to write this book, and you can tell that he poured his heart and soul into it.
Synopsis
While I may be a bit biased, I have to say that the book is great. :-) Shay definitely knows his IronRuby and shows it. He manages to write a book which delves into some deep technical content, but starts off high level enough that even someone who has never used Ruby could pick up the book and learn it. The book is very well organized, and starts off with a quick introduction to Ruby, the .Net Framework, and the DLR (Dynamic Language Runtime). He then immediately goes into getting IronRuby up and running on your system, along with a reference to how to use the IronRuby executable, and even how to get IronRuby to run inside some 3rd party IDEs.
Continue reading the rest of this post...
Posted on 2/25/2010 11:46:53 PM by Justin Etheredge
I want to show you an algorithm, it is a pretty simple algorithm. It is an implementation of the Damerau–Levenshtein edit distance algorithm from the pseudocode on Wikipedia:
public static int EditDistance(string string1, string string2)
{
var s1Length = string1.Length;
var s2Length = string2.Length;
var matrix = new int[s1Length + 1, s2Length + 1];
for (int i = 0; i <= s1Length; i++)
matrix[i, 0] = i;
for (int j = 0; j <= s2Length; j++)
matrix[0, j] = j;
for (int i = 1; i <= s1Length; i++)
{
for (int j = 1; j <= s2Length; j++)
{
int cost = (string2[j - 1] == string1[i - 1]) ? 0 : 1;
matrix[i, j] = (new[] { matrix[i - 1, j] + 1,
matrix[i, j - 1] + 1,
matrix[i - 1, j - 1] + cost}).Min();
if ((i > 1) && (j > 1) &&
(string1[i - 1] == string2[j - 2]) &&
(string1[i - 2] == string2[j - 1]))
{
matrix[i, j] = Math.Min(
matrix[i, j],
matrix[i - 2, j - 2] + cost);
}
}
}
return matrix[s1Length, s2Length];
}
Continue reading the rest of this post...
Posted on 2/22/2010 9:08:01 PM by Justin Etheredge
I recently put up a post on my blog about some of the new concurrent collections in .NET 4.0, and I noticed that a lot of people were being sent by Google to those posts who were only searching for System.Collections. I figured that maybe people could use a similar overview of the collections available to them in the System.Collections.Generic namespace, since it seems to me that no one uses anything other than List and Dictionary. So, in this post, I am going to take a look at a few of those collections, and explain exactly why you would want to use them.
Keep in mind as you read through this list that you shouldn't just start switching out collection types in code that you already have working. If something is working and performing properly for you, it is almost always better to take the easier route until you have proof that the easy approach does not work for you.
System.Collections.Generic.List<T>
The first collection that we are going to look at is List<T>. Like I said before, this collection seems to be the fallback, and with good reason. It is unsorted (but supports sorting), items can be added, removed, or inserted at a specific index. It also has indexed access, meaning that items can be accessed directly using a numeric index. You can add Ranges, perform binary searches, perform sequential searches, built in sorting, get the count of items, check for items within it, pass a delegate to it to perform actions, etc... It really is the Swiss Army knife of collections.
Continue reading the rest of this post...