Mathias Brandewinder on .NET, F#, VSTO and Excel development, and quantitative analysis / machine learning.
by Mathias 31. December 2009 11:56

It’s this time of the year again, which is traditionally an occasion to look back at what went down during the year, and set the sights for the year to come. 2009 has been a good year to me professionally. In spite of a gloomy economic context, Clear Lines is still alive and kicking, and revenue has remained stable, without requiring any particular marketing effort. I completed a few consulting projects without any noticeable glitch, managed to find time to release the first official version of Akin – and I am extremely motivated to begin 2010 on the right foot. So many things to do!


by Mathias 24. December 2009 08:28

After spending a few years working mostly with C#, it has become a natural, comfortable way to think about programming problems. I won’t complain about it -- comfort is nice. At the same time, I strongly believe in questioning what you do, especially the un-stated assumptions. When you start doing things a certain way without asking yourself if this is indeed the way to go, you are on a dangerous path, especially in a fast-evolving field like software engineering. So when I read the advice to “learn one new language every year”, it resonated, and I decided to give a shot at F#. I purchased “Programming F#”, and I am working my way through the Project Euler problems as an exercise.

This is my first exposure to functional languages, and it has proven a very stimulating mental exercise so far. One particular aspect I have struggled with is if … then statements. Chris Smith says that “if expressions work just as you would expect”. That’s sort of true, except for the fact that an if … then statement with no else clause can’t return a value.

This made me realize how much I use single-pronged if statements in C#, guard clauses being a prime example.


by Mathias 12. December 2009 11:43

A few days back, I stumbled upon this page, where Frank Rice describes how to use VBA to list all VBA macros and functions a Workbook contains. I thought that was interesting: it’s not the type of VBA code most commonly seen, and the idea of VBA code interacting with VBA code is fun. So I tweeted it, and Charts GrandMaster Jon Peltier, in his own words,  could not “leave anything alone, and made some changes to how the procedure worked”. Nice changes, if I might add.

I am not one to leave anything alone, either, and wanted to check how well that would work using C#.

Disclaimer: I have done enough checking to know that the code works in non-twisted cases, but this is far from polished. This would need some handling for exceptions before making it to anything shipped to a client you care about, for instance. My goal was to provide a solid code outline, feel free to modify to fit your needs.

The class/method below takes in a fully-qualified file name (i.e. with the full path, just what you would get from an OpenFileDialog), and searches for all the procedures (sub or function) defined in VBA.

As a bonus, I added some extra code to extract the signature of the procedure, and the header comments. The signature - what arguments it takes as input, and what it returns - is a much better summary than simply its name, and I figured that if the author bothered to add comments, it was probably extracting that, too. It also illustrates nicely some of the functionalities of the API.


by Mathias 8. December 2009 13:58

How to value life is a thorny issue for economists and non-economists, but I hadn’t expected the question to be also a matter of lively discussion among dinosaurs. And considering the state of decision theory at the time, they do a pretty good job at it.


by Mathias 1. December 2009 11:33

I have been using test-driven development since I read Kent Beck’s book on the topic. I loved the book, I tried it, and adopted it, simply because it makes my life easier. It helps me think through what I am trying to achieve, and I like the safety net of having a test suite which tells me exactly what I have broken. It also fits well with the type of code I write, which is usually math-oriented, with nice, tight domain objects.

So when I decided recently to write a C# implementation of the Simplex algorithm, a classic method to resolve linear programming optimization problems, I expected a walk in the park.

(Side note:I am aware that re-implementing the Simplex is pointless, I am doing this as an exercise/experiment)

Turns out, I was mistaken. I have been struggling with this project pretty much from the beginning, and unit testing hasn’t really helped so far. Unfortunately, I didn’t reach a point where I fully understand what it is that is not flowing, but I decided I would share some of the problems I encountered. Maybe brighter minds than me can help me see what I am doing wrong!More...


Comment RSS