I recently revisited the Simulated Annealing heuristic algorithm using C#. This algorithm is traditionally the choice for solving the Traveling Salesman problem, but I wanted to tackle another large combinatorial problem, Poker Solitaire.
For a description of the problem, visit Dr. Dobbs original article at:
http://www.ddj.com/184408203?pgno=16
How do you calculate a result with a solution set of 25 factorial (15,511,210,043,330,983,907,819,520)?
The Visual Studio 2008 solution (see below) provides a console application that repeatable executes a single annealing process, each time trying to optimize a 5x5 matrix of playing cards. The algorithm attempts to lay the cards out to optimize 12 poker hands (5 rows, 5 columns, 2 diagonals).
You can execute the console application using the syntax below, passing it the name of a text file that represents 25 cards for the 5x5 matrix.
C:> SimulatedSolitaire.Console.exe TestData\BestCards.txt
Download the Visual Studio 2008 solution by clicking here.
Monday, September 14, 2009
Wednesday, September 2, 2009
Is "simple" better?
Just thought I'd pass along a lesson that I continue to learn.
A couple of years ago I had the need to know my ever-changing home IP address. Granted there are some free tools like Dynamic DNS and others that do this, but I had some special requirements that the IP had to be placed on another server for special reasons.
When I wrote the code, I created a service that ran on my home server. I used a C# interface so that I could "one day" move other types of data from my home PC to a server. I also had to have Visual Studio create the service installer and manually install the service. I created my Visual Studio solution with nicely decoupoled projects (assemblies). I was a genius.
Recently I had to change some stuff in that piece of code. The more I thought about it (and tried to remember all the code parts), I realized had I just taken a pure TDD (test-driven development) approach I could have done it much simpler. I then sat down and wrote a simple console app main() with about 4 lines of code to call a web page with a magical query parameter that did everything I needed. A quick job creation in Windows Task Manager and things were now running nicely.
Much less code and more importantly, much easier to maintain and make sense of. I know we all hear often (and I preach it as well) that we are to develop "extensible" code, but the reality of it is that probably 90% of the code we write will never even need to be extended. Given that, a TDD attribute is warranted in many cases (if not all of them).
I'm still learning that "simple is better" a lot of the time.
A couple of years ago I had the need to know my ever-changing home IP address. Granted there are some free tools like Dynamic DNS and others that do this, but I had some special requirements that the IP had to be placed on another server for special reasons.
When I wrote the code, I created a service that ran on my home server. I used a C# interface so that I could "one day" move other types of data from my home PC to a server. I also had to have Visual Studio create the service installer and manually install the service. I created my Visual Studio solution with nicely decoupoled projects (assemblies). I was a genius.
Recently I had to change some stuff in that piece of code. The more I thought about it (and tried to remember all the code parts), I realized had I just taken a pure TDD (test-driven development) approach I could have done it much simpler. I then sat down and wrote a simple console app main() with about 4 lines of code to call a web page with a magical query parameter that did everything I needed. A quick job creation in Windows Task Manager and things were now running nicely.
Much less code and more importantly, much easier to maintain and make sense of. I know we all hear often (and I preach it as well) that we are to develop "extensible" code, but the reality of it is that probably 90% of the code we write will never even need to be extended. Given that, a TDD attribute is warranted in many cases (if not all of them).
I'm still learning that "simple is better" a lot of the time.
Subscribe to:
Posts (Atom)