The 2015 Moisture Festival is over; if you’re not familiar with the festival, it’s a month-long celebration of old-timey and modern vaudeville, comedy, variety, burlesque and circus arts at multiple venues here in Seattle. Hundreds of artists come in from around the world, and often end up staying in my spare bedroom to cut down on their costs. This year I had the pleasure of spending a week with one of the world’s greatest jugglers, Niels Duinker, during the festival and I thought I’d post some links to his videos. When I was a college student I taught myself to juggle, but that was before all the great youtube tutorials that are now available.

Here is Niels on how to do three — start here if you’ve never juggled before.

Back in the day I got a few pretty solid four ball patterns going but I never managed to get more than eight throws with five, or six throws with three in one hand. Maybe I’ll give it another shot!

]]>

]]>

There are a bunch of reasons; here are the ones that immediately come to mind.

First reason: constant integer arithmetic is always checked by default. This can be irritating. Suppose for example you have some interop code and you wish to create a constant for the `E_FAIL`

:

const int E_FAIL = 0x80004005;

That’s an error because that number is *too big* to fit into an `int`

. But you might not want to use a `uint`

. You might think well I’ll just say

const int E_FAIL = (int)0x80004005;

But that is also illegal because *constant arithmetic conversions are also always checked by default*. So we still have a conversion that is going to fail. What you have to do is turn off checked constant arithmetic:

const int E_FAIL = unchecked((int)0x80004005);

Second reason: you might have a block of code in which you want all the arithmetic to be checked, but there is one part — say, the inside of a performance-sensitive loop — where you want to get the maximum speed, and are willing to turn off checked arithmetic there and there alone.

Third reason: C# allows you to change the default to checked arithmetic for non-constant integer math via a compiler flag. If you’ve done so, and you need to turn it back off again on a temporary basis, then you have to use the unchecked keyword.

Fourth reason: the unchecked block can be used as a form of self-documenting code, to say “I am aware that the operation I’m doing here might overflow, and that’s fine with me.” For example, I’ll often write something like:

int GetHashCode() { unchecked { int fooCode = this.foo == null ? 0 : this.foo.GetHashCode(); int barCode = this.bar == null ? 0 : this.bar.GetHashCode(); return fooCode + 17 * barCode; } }

The “unchecked” emphasizes to the reader that we fully expect that multiplying and adding hash codes could overflow, and that this is OK; we want to be truncating to 32 bits and we expect that the numbers will be large.

There were a bunch of good comments to the previous post; among the questions posed in those comments were:

**What do you think of the compiler switch that changes from unchecked to checked arithmetic as the default?**

I’m not a big fan of this approach, for several reasons. First, hardly anyone knows about the switch; there’s a user education problem here. Second, I like it when the text of the program can be understood correctly by the reader without having to know the details of the compilation process. Third, it adds testing burden; now there are two ways that every program can be compiled, and that means that there are more test cases in the test matrix.

The C# team is often faced with problems where they have to balance breaking backwards compatibility with improving a feature, and many times the users advocating for the feature suggest “put in a compiler switch that preserves the backwards compatibility” (or, more rarely “put in a switch that turns on the feature”, which is the safer option.) The C# team has historically been quite resistant to adding more switches. We’re stuck with the “checked” switch now, but I think there’s some regret about that.

**Should checked arithmetic have been the default?**

I understand why the desire was there to make unchecked arithmetic the default: it’s familiar, it’s faster, a new language is going to be judged in part on benchmarks, and so on. But with hindsight, I would rather that checked arithmetic have been the default, and users be forced to turn it off for precisely those situations where the inner-loop performance is genuinely impacted by this nano-optimization. We have other safety features like array bounds checking on by default; it makes sense to me that arithmetic bounds checking would be on by default as well. But again, we’re stuck with it now.

]]>

One of the biggest problems with C and C++ is that you don’t even know for sure what the range is of an integer; every compiler can differ, which makes it tricky to write truly portable code. C# solves this problem by simply removing the ambiguity. In C#, an int is a 32 bit twos-complement, number, end of story. So that problem is solved. But many more remain.

The fundamental problem is that integer arithmetic in C, C++ and C# behaves only superficially like the integer arithmetic you learned in school. In normal arithmetic there are nice properties like “adding two positive numbers results in a third positive number”, which do not hold in these languages because of integer overflow. Even the property that there is no highest integer is a very useful mathematical property that does not hold. (A mathematician would note that the integer arithmetic that we have in C# is a commutative ring, but few developers have studied ring theory.)

This is bad because it leads to bugs. It is good because the vast majority of integer arithmetic done in any of these languages involves integers whose magnitudes are tiny compared to the possible range of the integer type, and because this kind of arithmetic can be done extremely quickly by computers. So then question then for the designers of C# is: how do we keep the desirable high performance while still enabling developers to detect and prevent bugs?

Of course, one choice would be to simply reject the premise that speed is the most important thing, and make math work correctly across the board. A “big integer” could be the default integer type, as it is in some other languages. Frankly, I spend billions of nanoseconds waiting for stuff to stream down from the network every day; I don’t really care if my arithmetic takes a few extra nanoseconds. It might be worthwhile to say that the default type is big integers, and if you want high performance integers, then you have to use a special type.

But when C# was developed, I doubt that this was even considered for a moment. Keeping the performance up, and being able to interface easily with existing libraries of unmanaged code, and leveraging the existing knowledge of developers used to 32 bit integers, were all high priorities. And we lived in a world where high latency was due mostly to the CPU taking a long time, not waiting for network I/O so much.

The decision the C# designers actually made was to have two kinds of integer arithmetic: checked, and unchecked. Unchecked arithmetic has all the speed and danger that you have learned to love from C and C++, and checked arithmetic throws an exception on overflow. It is slightly slower, but a lot safer.

How exactly is that safer? Because it is better to crash the program and bring the bug to the attention of the users and the developers, than to muddle on through. If the programmer believed that all arithmetic operations should be on integers that are tiny compared to the range of an integer, and in fact they are not, then something is fundamentally wrong with the program, it is unreliable, and it should be stopped before it does any more harm.

So it seems pretty clear why we would want to have a “checked” keyword in C#; it says “in this bit of the code, I assert that my integer arithmetic does not overflow, and if it does, I’d rather crash the program than muddle on through”. But what possible use is the unchecked keyword? Unchecked arithmetic is the default!

Next time on FAIC, we’ll answer that question.

]]>

Ricky Jay has a line in *The Spanish Prisoner* where he says that when your hobbies interfere with your work, that’s fine, but when they interfere with each other, you have a big problem. I had that terrible problem back in November and something had to give, so I stopped blogging and woodworking for a while there. The combination of a tight deadline at work, helping Mark get the next edition of Essential C# ready for later this year, and working on a series of educational videos ended up consuming all my available bandwidth for technical stuff.

A few months later, the next version of the Coverity C# analyzer is in good shape, Essential C# is down to only a few chapters yet to review, and my first series of beginner videos is not just in the can, but on the web!

Speaking of which: the nice people at O’Reilly asked me to do a series of video courses for absolute beginner C# programmers, like, never-programmed-before programmers. This was a big challenge for me, first because I’ve never done video at this kind of scale before, and second because it has been a long, long time since I was a C# beginner. I’m pretty pleased with the result though and I am now working on the next course, which will cover OOP.

Finally, I am unfortunately abandoning that series I started on graph traversal. One of the reasons why I delayed publishing the last episodes there was because I found a bug in the algorithm I was going to present, and upon further reflection, I think the algorithm I came up with is just plain wrong. I might do some more research — graph theory is not my strong suit by far — and see if I can find a correct algorithm. But for now, I’m going to let it go and pick up with other topics from my queue.

]]>

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.

]]>