Mathias Brandewinder on .NET, F#, VSTO and Excel development, and quantitative analysis / machine learning.
31. July 2009 18:00

I have been slammed with work lately, and couldn’t find the time to do this, even though I have wanted to for a while. Well, it’s done – this blog now runs on BlogEngine.Net 1.5.1.14! One of the reasons I wanted to give it a try is the multiple-widget zone feature, which is unfortunately not yet in the 1.5 “official” release, so I went the adventurous route, and here we are! I still need to do some minor polishing on the styling in the next few days, but so far, everything looks like it’s running smoothly.

29. July 2009 11:24

Today I came across a post which demonstrates how to use Goal Seek to determine how to save for your retirement. Goal Seek is essentially a simplified solver: point Goal Seek at a cell, tell it how much you want it to be and what cells it can tinker with, and Goal Seek will try to find values that reach that goal. The post is an excellent illustration of what’s great about it: it’s super easy to use, and very practical.

However, there is no such thing as a perfect tool, and Goal Seek can fail miserably at finding the optimal answer to very simple problems. After reading this, I thought it would be a good public service to illustrate what its shortcomings are, especially if you are going to trust it for questions as important as your retirement!

For our illustration, we will use the following setup.

Now let’s say we want to find a value such that B2 = 250. Following Pointy Haired Dilbert, let’s use Goal Seek:

Put in a value of 1 in cell B1, and run Goal Seek - here is what happens:

Goal Seek fails to find a value in B1 such that B2 = 250. Complete failure.

More...

24. July 2009 15:54

I really like the addition of [TestCase] in NUnit 2.5. A significant part of the code I write is math or finance oriented, and I find Data-Driven tests more convenient that “classic” unit tests to validate numeric procedures.

However, I got a bit frustrated today, because of the lack of tolerance mechanism in data-driven tests. Tolerance allows you to specify a margin of error (delta) on your test, and is supported in classic asserts:

[Test]
public void ClassicToleranceAssert()
{
double numerator = 10d;
double denominator = 3d;
Assert.AreEqual(3.33d, numerator / denominator, 0.01);
Assert.That(3.33d, Is.EqualTo(numerator / denominator).Within(0.01));
}

You can specify how close the result should be from the expected test result, here +/- 0.01.

I came into some rounding problems with data driven tests today, and hoped I would be able to resolve them with the same mechanism. Here is roughly the situation:

[TestCase(10d, 2d, Result = 5d)]
[TestCase(10d, 3d, Result = 3.33d)]
public double Divide(double numerator, double denominator)
{
return numerator / denominator;
}

Not surprisingly, the second test case fails – and when I looked for a similar tolerance mechanism, I found zilch.

The best solution I got was to do something like this:

[TestCase(10d, 2d, Result = 5d)]
[TestCase(10d, 3d, Result = 3.33d)]
public double Divide(double numerator, double denominator)
{
return Math.Round(numerator / denominator, 2);
}

Of course, this works – but this is clumsy. I was really hoping that TestCase would support the same functionality as Assert, with a built-in delta tolerance. It seems particularly relevant: rounding error issues are typical in numerical procedures, a field where data-driven tests are especially adapted.

Maybe the feature exists, but is undocumented. If you know how to do this, sharing your wisdom will earn you a large serving of gratitude, and if it the feature doesn’t exist yet… maybe in NUnit 2.5.1?

14. July 2009 06:58

While shopping at PetCo the other day, I saw this scene, and couldn’t get enough of it. It’s a great illustration of what happens when teamwork goes wrong. If I saw this in real life, I would feel sorry for the team, but the mice don’t seem to be suffering (besides some confusion), so sit back and enjoy the show, guilt-free.

7. July 2009 11:25

I was going through my digital camera today when I came across this:

I took this picture in the Seattle public library elevator. It’s a great building, with lots of unusual features.

Why did I take it? Because I thought the design was interesting. The typical elevator button panels has a series of buttons, each of them the same size, ordered with the corresponding floor elevation. This panel has buttons of various sizes, and given what I saw in the building, I guess the size corresponds to the frequentation of each floor, or, if you prefer, the relative likelihood that you want to go to each floor.

In my opinion, there are some flaws in the design (for instance, the buttons are very far from the labels saying what is on the floor, which slows down figuring out which button you really want to push), but I thought the idea of various button sizes was smart, and bizarrely under-utilized in computer user interfaces. If you are going to expose different functionalities to your user, chances are, some will be used more often than others, and giving them a larger button should make the user’s navigation easier.

I found an example of this on Netflix’s website, for instance:

Note how the 2 right-most elements of the tab are smaller than the rest?

So why is this design style rare? I guess it has to do with the fact that regularity looks good, without much effort. Give your buttons the same size and font, and everything looks organized, and easy on the eye. Once you start playing with elements of various sizes, it is much harder to achieve balance and cohesion. Usability might be improved, but chances are, you will need someone with a sense of visual design to help you make it look good – whereas even the most lacking in aesthetic sense can align buttons.

#### Need help with F#?

The premier team for
F# training & consulting.