In the last few days, I started playing with the new framework for optimization (i.e., business decision making) by Microsoft. It is called Microsoft Solver Foundation, and encompasses a number of technologies that make the connection between traditional optimization and mathematical programming and business-oriented tools, such as databases and spreadsheets.

The premise of MSF is that it is a framework is necessary to integrate the several areas where decision make technologies are required. Also, the tools used for optimization are varied, and it is useful to have a framework capable of doing the connection between these services.

Of course, from a strategic standpoint, MS is interested in offering solutions in an area in which IBM has already a good position. Particularly after the recent acquisition of Ilog, the leading producer of optimization software.

Some Features of MSF

The product is clearly still not mature, but it has some interesting features that play into MS core competencies:

• Support for most commercial solvers
• Unified programming paradigm for connecting mathematical decision into commercial computing services.
• Integration with Office – this is important if spreadsheets area used by your company to make decision base on OR models.

However, some deficiencies are also apparent:

• Lack of high quality solvers for some classes of problems. This is probably the biggest initial problem for Microsoft. They have a partnership with Gurobi, the new solver by the same guys that created Cplex. However, despite its potential, it still isn’t as fast as Cplex, and who knows how long its gonna take to catch up on that speed. Solvers for classes of non-linear optimization are also necessary.
• High licensing costs: The license for MSF is by CPU, and it looks like it is in the 5 digits range. This may be a huge investment for some customers, specially the ones that still need to pay for an Ilog license. I really expected something at a lower cost and targeted at a larger demographic group, coming from Microsoft. Let us see how this issue plays out.

Conclusion

I am still learning MSF, and it matches very nicely with C#. Many people will also use the product as a plug in for Excel, with works just fine for simple optimization models. In future posts, I will provide some concrete examples of how MSF works within a C# or C++ application.

References

• Microsoft Main Page for MSF
• Download page for express version
• Discussion forum

Related Posts

• New Features of C# 4.0
• Software Performance, the Web and Microsoft

C# was created by Microsoft to become the main language of their .NET framework. It is a simple language, following the tradition of Java in many aspects, but it has a particular feel that makes it really cool to use. Moreover, although it was created by Microsoft, C# can now be used successfully in other systems, such as Linux?—?thanks to the Mono guys.

In this article, I want to share with you some of the features that are being integrated into C# for its next major release, version 4.0 that will be available with the next version of visual studio. There is a lot of stuff being cooked on the Redmond labs, but the most visible features are related to dynamic method invocation and parameter passing.

Dynamic Programming in C#

The main feature that will be available for C# 4.0 is access to code created on non-typed programming languages such as Python and Ruby. The mechanism that provides this functionality is the support of the compiler and runtime, designated by the dynamic keyword. By using the dynamic keyword instead of providing a statically defined type name, you are saying to the C# compiler that the object is defined at run time, and is able to respond to dynamic messages.

For example, suppose you want to instantiate an object create by Iron-Python (the .NET-enabled version of Python). You can send messages to the object using code similar to the following:

dynamic employee = getEmployee();
employee.calculateSalary();

The important part of this code is “dynamic employee”, where the variable employee is declared as being of a dynamic type. What this says to the C# compiler is that the type of employee is unknown at compile time, but that it can dispatch dynamic messages sent to it.

Therefore, in the second line, the method call calculateSalary is not resolved at compile time. Instead, the call to calculateSalary is resolved only during execution. This way, a dynamic run time will have the opportunity to receive information about the call, such as its name and parameters. With that information, a particular run time back end (such Iron-Python) can call the right function, and the program can continue.

With this new feature, C# becomes more useful as a language that can connect to statically typed as well as dynamically executed languages. In the new version of C#, this feature will be used to provide special ways to handle XML and SQL data.

Default Parameters

Another area where C# will simplify the life of programmers is in the way parameters are passed to functions. C# rules for declaring and passing parameters are similar to Java rules. In particular there currently are no default parameters to simplify message calls.

C# 4.0 introduces default values for parameters. In this way, instead of typing

class Employee {
  public void calculateSalary(double rate, double hours)
  { /*... */ }
  public void calculateSalary(double rate) {
    calculateSalary(rate, 40.0);
  }
}

one can use a default parameter for hours, so that only one method needs to be declared:

class Employee {
  public void calculateSalary(double rate, double hours = 40.0)
  { /* ... */ }
}

Another nice feature is the introduction of named parameters. With named parameters, one can skip parameters that have default values, and name only the parameters that have non-default values. This is useful in the world of Office-scripting, where most parameters are set to default values.

Going back to our example, suppose that both parameters have default values:

class Employee {
  public void calculateSalary(double rate=1.25,
     double hours = 40.0) { /* ... */ }
}

Then, one can make the following method call:

Employee e = getEmployee();
e.calculateSalary(hours:30.0);

The new syntax also works nicely as an additional form of documentation for the method call, so you can reduce the pain of methods with many parameters (that, if you remember , you shouldn’t have anyway). The syntax is also similar to the standard Smalltalk way of message passing.

Conclusion

C# is a language that is evolving rapidly. It has a great set of tools, being the primary language used by Microsoft. It is nice to know that they are trying to make the language more useful for the integration with dynamic language. Also, I hope that such features will someday get its way into Java. Although I am certainly not holding my breath.

References

• Article from Microsoft
• List of articles on C# 4.0

Related Articles

• Reducing the Size of Parameter Lists
• Why a large code base is a liability

I am a big fan of Git, the distributed source control system created by Linus Torvalds and using on the Linux kernel. The system is really fast, and it is so configurable that it makes life really easy (at least after you learned enough about how it works).

But the reality of the of industry is still very different from what we can do on open source. Companies don’t want a distributed system, because they like to have control of code in a central location. That is why not even Google is using Git these days (they use Perforce, a closed source control system).

The big advantage of Git, however, it that is doesn’t need permission from management to be used in your local machine. And since Git works on a local machine is well as in a server, this is all you need to have a lot of fun.

Playing with Git and Svn

My first try at Git was as a local client for Svn. The general idea is that you can get Git to checkout your project and translate all Svn information into its internal format. That way, you can work with Git locally, and after doing your local development, push the commits to the Svn server.

That worked for me for some time, as I was learned as all pieces worked together. The problem that I had, however, was due to the fact that the Svn importer for Git is not as stable as Svn itself. That is, from time to time there would be some problem in the import/fetch phases, and since you depend on the importer to get anything from Svn, you are in pretty bad shape if that happens.

It also contributed to my problem the fact that my project uses non-standard names for branches, and that they are moved from time to time (don’t ask me why).

I learned the hard way that it maybe easy to use any one of two version control systems, but it is not so easy to mix them…

Trying Git a Second Time

My next try was to use something a little easier. Instead of using Git full time as an svn client, what I do now is to use svn as always (through Tortoise-svn). Then, on top of Svn, I use git to handle changes between Svn commits.

The setup is really easy. The first step is to have a normal Svn tree. Then, use the command

git init

to create a .git directory. Since Git uses only a single directory to hold all its internal information, it will not interfere with the information kept by svn itself in its .svn directories.

Now, I can just hack and commit code on git as I go. Then, when a feature is complete after several small iterations, I can do a Svn commit. I can even decide to spend a long time working on Git, and then go back and make incremental Svn changes. I can also decide to keep hidden branches on Git alone, and merge then only when needed to check in to Svn.

All this can be done without much trouble. The only added work is that I need to do some extra commits to Svn, to make sure that my work is integrated with the other developers, but the fact that everything was ready on Git makes things much easier — I can even use the same summaries.

Conclusion

As any interesting idea, this is one is not new. I just did a quick search on “using git with svn” and found at least another person that uses this idea (see references). Which also means that I am not the craziest developer either.

I am still tweaking my setup with Git and Svn. For example, it is useful to add the .svn directories to .gitignore, as well as other binary files. However, everything has worked Ok, and I feel that this is a good solution for some problems we have when using Svn alone.

References

• Version Control with Git: Powerful Tools and Techniques for Collaborative Software Development
• Progit: tutorial

Related Articles

• Why a large code base is a liability
• Using SVN merge tracking effectively
• Keeping your users in control