Yesterday morning a coworker forwarded to me an article about a recently patched security hole in Windows, and wondered if I had any thoughts on it. Oh, did I! I read about the exploit with an odd mixture of nostalgia — because I worked on the code in question back in the 1990s — and horror at how long this exploitable bug had been in Windows.

To be clear, I did not write the actual exploitable code; it predates my time at Microsoft. But I was worried while I was reading the article that it might turn out to be my bad! This is the second time that has happened to me, and it is not a pleasant feeling.

Coverity has a research team devoted specifically to security-impacting bugs, and they were kind enough to ask me to write up my thoughts for their blog. You can read about my guess at what the buggy code looked like here.

If you have examples of “missing restore”-style bugs — security-impacting or not — in real-world code in any language, I would *love* to see them. Please leave examples in the comments here or on the security blog. Thanks!

]]>

*In this series of activities, select whether each person should:*

*Stop now because the action is inappropriate**Proceed with caution because the action is questionable**Go ahead because the action is appropriate*

A scenario is then given, with the following UI element:

That is, the program is testing whether or not the user can correctly apply company policy to the given scenario.

In what ways is this traffic light element wrong from *a UX perspective?* I am curious to see what you come up with. Please leave problems with this UX in the comments.

Here, I’ll start.

The meaning of a solid yellow light on a three-lamp traffic signal is not “*proceed with caution*” — that’s the meaning of flashing single-lamp yellow light. A solid light on a three-lamp traffic signal means “*you are hereby warned that this signal is about to turn red, so stop now if you can do so safely*“. The analogy is therefore subtly flawed.

]]>

It is pretty obvious just from looking at this graph that if you start from the Troll Room and follow the arrows, there are four rooms that you must enter no matter what combination of edges you take: the East-West Passage, the Dam, the Dam Lobby and the Maintenance Room. And moreover, we’ll encounter them in that order. Let’s call these nodes “the inevitable nodes of the Troll Room”.

Actually, do we know *for sure* that we’ll encounter them in that order? It seems plausible that the inevitable nodes come in a particular order, but naybe that’s true on *this* graph but not true in general. I propose the following theorem: suppose a node X has two distinct inevitable nodes, Y and Z. Then either Y is an inevitable node of Z, or Z is an inevitable node of Y, but not both. And therefore, all the inevitable nodes of a particular node can be put into the unique order in which they must inevitably be visited.

It’s not hard to prove this fact by considering the cases: if neither Y nor Z are inevitable nodes of each other then there must be a path that goes from A through Y and never goes through Z, which contradicts the supposition that Z is an inevitable node of A. If Y and Z are both inevitable nodes of each other then there is a cycle path, contradicting the supposition that we’re in a DAG. The only remaining possibility is that exactly one is an inevitable node of the other.

Today I am interested in DAGs where there is one node that is an inevitable node of *every* other node in the graph. (Naturally no node can be an inevitable node of itself, as that would imply that there is a cycle in the graph.) Our little graph here is such a graph: no matter where you start, you inevitably end up in the Maintenance Room and then can go no further. Let’s call such a node a “final inevitable node”.

My question is: suppose we have a DAG that contains a final inevitable node. I want an algorithm that takes as its input any other node, and outputs the *closest* inevitable node to that node; that is, the first inevitable node that will be encountered. We know that there must be a unique first inevitable node because given any two inevitable nodes, one is after the other.

For example, the Troll Room has four inevitable nodes, the closest obviously being the East West Passage. This is not very interesting because there is only one edge out of the Troll Room! But consider the Round Room; now it is not so clear that the closest inevitable node of the Round Room is the Dam. And so on.

There are a number of ways to solve this problem; we’ll consider a few ideas over the next few episodes.

]]>

public static IEnumerable<ImmutableStack<KeyValuePair<E,N>>> AllEdgeTraversals<E, N>( N start, Func<N, IReadOnlyDictionary<E, N>> getEdges) { var edges = getEdges(start); if (edges.Count == 0) { yield return ImmutableStack<KeyValuePair<E, N>>.Empty; } else { foreach (var pair in edges) foreach (var path in AllEdgeTraversals(pair.Value, getEdges)) yield return path.Push(pair); } }

We don’t need a monolithic, precomputed graph data structure at all. We can compute the edge set of a given node on demand, as it were.

Of course we can use this static method with our graph structure easily enough:

foreach (var path in AllEdgeTraversals("Troll Room", n => map.Edges(n))) Console.WriteLine(string.Join(" ", from pair in path select pair.Key));

And we get the same result as before.

Here’s a graph that I am interested in exploring. The nodes are the points on the two-dimensional lattice of non-negative integers. Each node has zero, one or two edges that point to a neighbouring node, and the labels are either “Left” or “Down”:

This is an infinite graph, and so we cannot really represent it in our immutable graph structure easily. But that’s OK; every traversal on the graph is finite because they all eventually get to (0,0), and we can create new nodes and edges as needed:

Func<Tuple<int, int>, IReadOnlyDictionary<string, Tuple<int, int>>> getEdges = latticePoint => { var edges = ImmutableDictionary<string, Tuple<int, int>>.Empty; if (latticePoint.Item1 > 0 { edges = edges.Add( "Left", Tuple.Create(latticePoint.Item1 - 1, latticePoint.Item2)); } if (latticePoint.Item2 > 0) { edges = edges.Add( "Down", Tuple.Create(latticePoint.Item1, latticePoint.Item2 - 1)); } return edges; };

What are all the traversals from (3, 2) to (0, 0)?

foreach (var path in AllEdgeTraversals(Tuple.Create(3, 2), getEdges)) Console.WriteLine(string.Join(" ", from pair in path select pair.Key));

Run that and we get

Left Left Left Down Down Left Left Down Left Down Left Left Down Down Left Left Down Left Left Down Left Down Left Down Left Left Down Down Left Left Down Left Left Left Down Down Left Left Down Left Down Left Down Left Left Down Down Left Left Left

Wait a minute… that looks suspiciously familiar. If we replaced the lefts with “true” and the downs with “false”… oh my goodness, I’ve *accidentally and totally not on purpose* solved the “enumerate all bit sequences of size n that have exactly k true bits” problem again, which in turn gives us a solution to the “enumerate all the combinations of k elements from an n-element sequence” problem. Enumerating the traversals on this graph starting at (k, n-k) is exactly the same as enumerating all the sequences of n bits with exactly k true bits.

Is that ever weird!

Finally, one more. Recall that we also solved the “enumerate the combinations of k items from a sequence of n” by solving the problem “enumerate the sets of size k drawn from the integers 0 through n-1“. We can solve that problem by enumerating all the traversals of this graph starting from (n, k):

Doing so is left as an exercise. Do you see the connection between these recursive graph traversal algorithms and the equivalent recursive combination algorithms from the previous series?

**Next time:** we’ll look at another problem involving paths on a DAG.

]]>

The question at hand is: given a node in a finite DAG, what are all the possible traversals of *edges* through the graph starting from that node? We know that any traversal of a finite DAG must eventually terminate in a node that has no outgoing edge, and that there are finitely many such traversals.

Suppose we start from the Troll Room on this map; clearly if we follow the arrows we inevitably end up at the Maintenance Room. The question is: what are all the possible sequences of edges that get us from here to there? We’ll represent a sequence of edges as an immutable stack, again from the NuGet package. So we’ll start by adding a method to our graph type with signature:

public IEnumerable<ImmutableStack<KeyValuePair<E, N>>> AllEdgeTraversals(N start) {

Let’s reason recursively. What is the base case? If we are in a room with no outgoing passages, then there is exactly one path we can go on, and that’s the empty path.

var edges = Edges(start); if (edges.Count == 0) { yield return ImmutableStack<<KeyValuePair<E, N>>.Empty; }

That was easy, as the base case should be. What’s the recursive case? If we know all the traversals of all the nodes that are reachable immediately from this one, then we can simply add the edges that get us to each of them to the traversals.

// The key is the edge, the value is the node. else { foreach (var pair in edges) foreach (var path in AllEdgeTraversals(pair.Value)) yield return path.Push(pair); }

And we’re done. If we then run this method on our previously-created Zork map:

foreach (var path in map.AllEdgeTraversals("Troll Room")) { Console.WriteLine( string.Join(" ", from pair in path select pair.Key)); }

Then we get every possible traversal through this map that ends in the dead end which is the Maintenance Room:

East East East Up East North East East East East Up East North North East East East Up Northwest East North East East East East Up Northwest East North North East East North Northeast East North East East East North Northeast East North North East East North Northeast Northwest East North East East East North Northeast Northwest East North North East East North North Northeast East North East East East North North Northeast East North North East North Northeast East North East East North Northeast East North North

And sure enough, those are all the possible ways to get from the Troll Room to the Maintenance Room in this DAG version of the map. Solving the “find all traversals on a cyclic graph that do not go into cycles” is a slightly trickier problem but perhaps you can see how to modify the algorithm to do so. At that point you could put the rest of the edges from the original map into the graph and see how many ways there are to leave the Troll Room and run around the Great Underground Empire without crossing your own path.

**Next time:** We could make this algorithm slightly more general, and in doing so, discover a surprising result.

]]>

- How can we create an immutable data structure which represents
*a directed graph with labels on the edges*? - Given a directed acyclic graph (DAG),
*what are all the possible*?**edge**traversals through that graph starting from a particular node

First things first. Like I said, there are a zillion different ways to represent a graph. I want to do so immutably — again, an immutable data type is one where “mutations” return a new object that is a mutated version of the original object, which stays the same. For my purposes today, I want to be able to take an existing graph, possibly empty, and insert new nodes and edges into that graph. The data structure I’m going to choose for my internal representation is that a graph consists of:

- an unordered, no-duplicates set of nodes of
*arbitrary type*. Just like you can have a list of strings or a list of pairs of integers, I want to have a graph where the nodes are strings or giraffes or whatever. - every node has an unordered, no-duplicates set of outgoing edges of arbitrary type. Again, I want to be able to make the edges anything I want. If I want a graph where the nodes are apples and the edges are tigers, I should be able to get that.
- an edge that leaves one node in a graph goes to another (or the same) node in the graph. That is, the edges have a direction to them; every edge starts at one node and goes to another.

Suppose my edges are integers and my nodes are strings. The constraints above imply that there can be edges 123 and 345 that both leave node “ABC” and arrive at node “XYZ”. But there cannot be an edge 123 from “ABC” to “DEF” and an edge 123 from “ABC” to “XYZ”; the edges leaving node “ABC” must be distinct in their values.

Like I said earlier, there are lots of different kinds of graphs, and these constraints work well for my purposes in this series. If, for example, I wanted edge labels to be costs, say, then this would not work well; if edge labels are costs then you want the opposite characteristics. That is, you want there to be only one edge between any pair of nodes, where that edge indicates the cost of traversal, and it is perfectly reasonable to have two edges leaving the same node with the same cost. But in my case I want the edges to uniquely identify a path through the graph.

With that set of characteristics in mind, we quickly realize that we could say that an immutable directed graph is nothing more than an immutable dictionary, where the dictionary keys are nodes and the dictionary values are themselves immutable dictionaries where the nested dictionary keys are edge values and the nested dictionary values are the destination nodes of those edges.

Rather than making my own immutable dictionary — because that’s not the point of this series — I’ll just use the System.Collections.Immutable package downloadable from NuGet to define my graph. Since this is first, just a super-thin wrapper around a dictionary reference, and second, logically a value, I’ll make it a struct.

using System; using System.Collections.Generic; using System.Collections.Immutable; struct ImmutableDirectedGraph<N, E> { public readonly static ImmutableDirectedGraph<N, E> Empty = new ImmutableDirectedGraph<N, E>( ImmutableDictionary<N, ImmutableDictionary<E, N>>.Empty); private ImmutableDictionary<N, ImmutableDictionary<E, N>> graph; private ImmutableDirectedGraph( ImmutableDictionary<N, ImmutableDictionary<E, N>> graph) { this.graph = graph; }

To add a new node to the graph we first check to see if the graph already contains this node; if it does, we leave it alone. If not, we add it to the map with an empty set of outgoing edges.

public ImmutableDirectedGraph<N, E> AddNode(N node) { if (graph.ContainsKey(node)) return this; return new ImmutableDirectedGraph<N, E>( graph.Add(node, ImmutableDictionary<E, N>.Empty)); }

To add an edge to the graph, we first make sure that both nodes are in the graph. Once that’s taken care of, we get the edge set for the start node and add to it the new edge.

public ImmutableDirectedGraph<N, E> AddEdge(N start, N finish, E edge) { var g = this.AddNode(start).AddNode(finish); return new ImmutableDirectedGraph<N, E>( g.graph.SetItem( start, g.graph[start].SetItem(edge, finish)))); }

Remember, setting an item on an immutable dictionary gives you back a different dictionary with the new item added.

Finally, given a graph and a node, what are the outgoing edges? We could give an error if the node is not even in the graph, but I think it is reasonable to say that the edge set of a node that is not in the graph is the empty set:

public IReadOnlyDictionary<E, N> Edges(N node) { return graph.ContainsKey(node) ? graph[node] : ImmutableDictionary<E,N>.Empty; }

I’m not going to need edge and node removal for my purposes; doing so is left as an exercise to the reader. Note that the data structure I’ve sketched out here does not have an efficient mechanism for removing the edges that are pointing to a removed node; modifying the data structure to make that efficient is an interesting challenge that I’m not going to get into in this series.

As you’ve likely come to expect, to use this thing we start with the empty graph and add edges (and, if we like, nodes with no edges).

Here is a portion of the Zork map where I’ve removed a whole bunch of edges to make a DAG. (Click for larger.)

We can build that map in our graph structure like this:

var map = ImmutableDirectedGraph<string, string>.Empty .AddEdge("Troll Room", "East West Passage", "East") .AddEdge("East West Passage", "Round Room", "East") .AddEdge("East West Passage", "Chasm", "North") .AddEdge("Round Room", "North South Passage", "North") .AddEdge("Round Room", "Loud Room", "East") .AddEdge("Chasm", "Reservoir South", "Northeast") .AddEdge("North South Passage", "Chasm", "North") .AddEdge("North South Passage", "Deep Canyon", "Northeast") .AddEdge("Loud Room", "Deep Canyon", "Up") .AddEdge("Reservoir South", "Dam", "East") .AddEdge("Deep Canyon", "Reservoir South", "Northwest") .AddEdge("Dam", "Dam Lobby", "North") .AddEdge("Dam Lobby", "Maintenance Room", "East") .AddEdge("Dam Lobby", "Maintenance Room", "North");

Notice how there are two paths from the Dam Lobby to the Maintenance room, but our data structure handles that just fine.

**Next time:** we’ll see how to find all the traversals through that graph starting from any given node.

]]>

`{50, 60, 70, 80, 90}`

had combinations of exactly three elements as follows:
{ // 50, 60, 70, 80, 90 {50, 60, 70}, // T T T F F {50, 60, 80}, // T T F T F {50, 60, 90}, // T T F F T {50, 70, 80}, // T F T T F {50, 70, 90}, // T F T F T {50, 80, 90}, // T F F T T {60, 70, 80}, // F T T T F {60, 70, 90}, // F T T F T {60, 80, 90}, // F T F T T {70, 80, 90} // F F T T T }

The table of bits on the right hand side is true if the element is included in the combination and false if it is not. We recursively divided finding all combinations of a particular size up into two sub-problems: first we enumerated all the cases where the left bit was true, and then all the cases where the left bit was false. We used that insight to recursively construct every sequence of n Booleans where there were exactly k true values.

If you treat the chart above as bits in an integer with the least-significant bit on the right, we have the values 28, 26, 25, 22, 21, 19, 14, 13, 11, 7 — that is, we have produced the sequence in order of descending value when interpreted as bits this way.

I have in mind a slightly different order. What if we treated those Booleans as bits in an integer with the least-significant bit on the *left*, and then re-ordered them into *ascending* order by integer value? Here I’ve reversed the bits left-to-right in the chart, and reordered the rows into ascending order by bit value:

{ // 90, 80, 70, 60, 50 {50, 60, 70}, // F F T T T {50, 60, 80}, // F T F T T {50, 70, 80}, // F T T F T {60, 70, 80}, // F T T T F {50, 60, 90}, // T F F T T {50, 70, 90}, // T F T F T {60, 70, 90}, // T F T T F {50, 80, 90}, // T T F F T {60, 80, 90}, // T T F T F {70, 80, 90} // T T T F F }

You’ll note that this order is very similar but not identical to our previous ordering.

Suppose we treat these not as sequences of bits, but as sets of bit numbers, where the low bit is bit zero, the next is bit one, and so on up to bit four:

{ {50, 60, 70}, // 2 1 0 {50, 60, 80}, // 3 1 0 {50, 70, 80}, // 3 2 0 {60, 70, 80}, // 3 2 1 {50, 60, 90}, // 4 1 0 {50, 70, 90}, // 4 2 0 {60, 70, 90}, // 4 2 1 {50, 80, 90}, // 4 3 0 {60, 80, 90}, // 4 3 1 {70, 80, 90} // 4 3 2 }

Previously we noted that the job of producing all combinations is equivalent to producing all bit sequences with a given number of true bits; well, *that* is in turn equivalent to producing *all sets of integers with a given number of elements and a certain bound*. In this case, all the sets of integers that have exactly three elements, and are between zero and four inclusive. Moreover, the integers are indexes into the original sequence!

Let’s make a recursive method to produce these bit sets. The recursion is a pretty straightforward modification of our previous algorithm:

// Takes integers n and k, both non-negative. // Produces all sets of exactly k elements consisting only of // integers from 0 through n - 1. private static IEnumerable<TinySet> Combinations(int n, int k) { // Base case: if k is zero then there can be only one set // regardless of the value of n: the empty set is the only set // with zero elements. if (k == 0) { yield return TinySet.Empty; yield break; } // Base case: if n < k then there can be no set of exactly // k elements containing values from 0 to n - 1, because sets // do not contain repeated elements. if (n < k) yield break; // A set containing k elements where each is an integer from // 0 to n - 2 is also a set of k elements where each is an // integer from 0 to n - 1, so yield all of those. foreach(var r in Combinations(n-1, k)) yield return r; // If we add n - 1 to all the sets of k - 1 elements where each // is an integer from 0 to n - 2, then we get a set of k elements // where each is an integer from 0 to n - 1. foreach(var r in Combinations(n-1, k-1)) yield return r.Add(n-1); }

Previously we produced a sequence of bools indicating whether a particular item has been chosen or not. Now we have a sequence of indicies, so it seems reasonable to require an indexed collection. Writing the code to deal efficiently with a non-indexed sequence is left as an exercise.

public static IEnumerable<IEnumerable<T>> Combinations<T>( this IList<T> items, int k) { if (k < 0) throw new InvalidOperationException(); if (items == null) throw new ArgumentNullException("items"); int n = items.Count; if (n > TinySet.Maximum) throw new InvalidOperationException(); return from combination in Combinations(n, k) select (from index in combination select items[index]); }

We can then run this just as we did before:

var sequence = new[] { 50, 60, 70, 80, 90 }; foreach(var combination in sequence.Combinations(3)) Console.WriteLine(string.Join(",", combination));

And get, as we expect:

50,60,70 50,60,80 50,70,80 60,70,80 50,60,90 50,70,90 60,70,90 50,80,90 60,80,90 70,80,90

Notice how this is in a slightly different order than our original algorithm. The original algorithm produced everything that contained 50 first; this algorithm produces everything that contains 90 last.

**Next time on FAIC:** We’ll keep exploring recursive algorithms that use stacks, but this time we’ll solve a problem on graphs.

]]>

I’ve put a pair of binoculars facing the sun on my desk on a notebook, masked one of the lenses with a post-it note, and propped it up with a box of business cards. By rotating the notebook I can follow the sun, and by rotating the corner of the box on the left side and keeping the corner on the right side fixed, I can very slightly adjust the height. Since the sun moves left-to-right much faster than up-and-down at 1:40 in the afternoon, that’s handy. I then focus the image on the wall.

I’ll keep posting images as the eclipse continues this afternoon, as long as those clouds hold back!

UPDATE: It begins! The blurry dark bit is a sunspot.

UPDATE: NOOOOOOO

That’s a big cloud. This might be done just as it was getting started. Vexing!

UPDATE:YAAAAAY!

The sun peeked out a few minutes before maximum eclipse, and then disappeared again:

For comparison, here’s an image from the Griffith Observatory shot at the same time:

This image shot through a telescope is of course inverted compared to mine shot with binoculars. Notice that the sunspot that is just a blur in my images is sharp here. Also, since Los Angeles is quite a ways south of Seattle, the percentage of the sun’s disk covered at maximum eclipse is quite different.

And of course, ten minutes after the eclipse ended the sun came out in the most dramatic possible fashion:

while it was still pouring rain in the east:

I picked the wrong day to leave my good camera at home!

]]>

Now, on the one hand, who the heck cares whether we use 4 bytes per bit stack or 400 for this problem? The lowest common denominator 32 bit machine has two billion bytes of address space, and it seems unlikely that the difference between success and failure in the market is going to be the difference between 4 bytes and 400 bytes.

On the other hand, representing a combination in a single int is an interesting challenge and lets me demonstrate a nice variant of the algorithm I presented last time. (Incidentally, an alert reader pointed out a harmless but vexing bug in my algorithm of last time, which I have fixed; see the post for details.)

Last time we used an immutable stack of Booleans; this time we’re going to use an immutable set of integers. (Recall that a *set* is a collection which has no particular order imposed on its elements, and there are no duplicate elements.) Our immutable stack was designed so that pushing did not mutate the stack; rather, it produced a new stack with the pushed element on it. Similarly, our immutable set will have an “add” method that does not mutate the set; rather, it returns a new set with the item added. We’ll make this set a struct so that it really does consume no more memory than its single int field:

using System; using System.Collections; using System.Collections.Generic; using System.Linq; internal struct TinySet : IEnumerable<int> { public static readonly TinySet Empty = new TinySet(0); public const int Minimum = 0; public const int Maximum = 31; private readonly int bits; private TinySet(int bits) { this.bits = bits; } public bool Contains(int item) { if (item < Minimum || item > Maximum) return false; return (bits & (1 << item)) != 0; } public TinySet Add(int item) { if (item < Minimum || item > Maximum) throw new InvalidOperationException(); return new TinySet(bits | (1 << item)); } public TinySet Remove(int item) { if (item < Minimum || item > Maximum) return this; return new TinySet(bits & ~(1 << item)); } IEnumerator IEnumerable.GetEnumerator() { return this.GetEnumerator(); } public IEnumerator<int> GetEnumerator() { for(int item = Minimum; item <= Maximum; ++item) if (Contains(item)) yield return item; } }

Long time readers will recognize this as the same tiny set I used in my series on graph colouring. We’re not going to need removal but I added it anyways just for the heck of it. Adding other features like union, intersection, and so on, is easily done and left for the reader.

We can then use this set the same way we used our stack; the code

TinySet mySet = TinySet.Empty.Add(1).Add(0).Add(3);

produces the set `{0, 1, 3}`

.

**Next time:** Now that we have this data structure we can modify our algorithm of last time to produce all the combinations.

]]>

- Is the problem trivial? If so, solve it.
- Otherwise, break the problem down into one or more smaller problems, solve them recursively, and aggregate those solutions into the solution of the larger problem

Let’s start with a signature. What do we have? integers n and k. What do we want? A sequence of Boolean stacks such that the size is n, and there are k bits turned on. We therefore require that n and k both be non-negative, and that n be greater than or equal to k.

private static IEnumerable<ImmutableStack<bool>> Combinations (int n, int k) {

**UPDATE: A commenter noted that though my program worked, the private helper method did not actually fulfill its contract, and its caller was therefore “working by accident”. Apologies for the error; I’ve fixed it.**

What is the trivial case? If we are trying to make a sequence of zero bits, with zero of them on, there is only one possibility, which is the empty sequence. And we know that if n is smaller than k, then we are trying to make a sequence with n bits that has more than all of them true, which is impossible, so that sequence is empty. Those sound pretty trivial! Since this is a private method we can eschew the error checking; the caller will be responsible for ensuring that the arguments are non-negative.

if (k == 0 && n == 0) { yield return ImmutableStack<bool>.Empty; yield break; } if (n < k) yield break;

We need to break the problem down into smaller problems. Let’s go back to our original chart from part one for inspiration:

{ // 50, 60, 70, 80, 90 {50, 60, 70}, // T T T F F {50, 60, 80}, // T T F T F {50, 60, 90}, // T T F F T {50, 70, 80}, // T F T T F {50, 70, 90}, // T F T F T {50, 80, 90}, // T F F T T ---------- {60, 70, 80}, // F T T T F {60, 70, 90}, // F T T F T {60, 80, 90}, // F T F T T {70, 80, 90} // F F T T T }

I’ve divided that into two parts based on whether the first element is true or false. Being able to find the point where you “divide and conquer” is the key to a lot of recursive algorithms, and this seems like a good spot to do it. For the cases where the first element is true, the remaining four elements have to be from the sequences of four Booleans where exactly two are true. For the cases where the first element is false, the remaining four elements have to be from the sequences of four Booleans where exactly three are true. In both cases we’ve decreased the size of the sequence and are therefore heading rapidly towards our recursive base case. We can now easily write the rest of the algorithm based on this insight:

if (k > 0) foreach(var r in Combinations(n-1, k-1)) yield return r.Push(true); foreach(var r in Combinations(n-1, k)) yield return r.Push(false); }

(Do you see why we don’t need to check whether n > 0 in either recursive case?)

We’ve solved an equivalent problem of the original problem given; the original problem was to produce combinations of a sequence, not bits. Let’s actually solve that problem, shall we? We need a combination of the `Zip`

and `Where`

extension methods on sequences, which is easily written: (Error handling omitted again.)

private static IEnumerable<T> ZipWhere<T>( this IEnumerable<T> items, IEnumerable<bool> selectors) { using (var e1 = items.GetEnumerator()) using (var e2 = selectors.GetEnumerator()) while (e1.MoveNext() && e2.MoveNext()) if (e2.Current) yield return e1.Current; }

And now, finally we have enough gear to solve the original problem:

public static IEnumerable<IEnumerable<T>> Combinations<T>( this IEnumerable<T> items, int k) { if (k < 0) throw new InvalidOperationException(); return from combination in Combinations(items.Count(), k) select items.ZipWhere(combination); }

And now we can use our new method:

var sequence = new[] { 50, 60, 70, 80, 90 }; foreach(var combination in sequence.Combinations(3)) Console.WriteLine(string.Join(",", combination

and as we expect, we get

50,60,70 50,60,80 50,60,90 50,70,80 50,70,90 50,80,90 60,70,80 60,70,90 60,80,90 70,80,90

All the code put together in runnable form with proper error handling is here.

**Next time: **we’ll take a similar but different approach to solving the same problem, just for the heck of it.

]]>