Freewill in progress (2)

(Click to enlarge)

What’s up?

As you can see, Freewill now supports 17 different selection policies.  At this point, all of them are coded but only half of them have been tested.

The 11 available termination policies are coded, half of them tested.

So far, only 2 mutation policies are available.  Both of them are coded and tested. I will probably need a few extras for TSP type of problems as well as numerically parametrized problems (e.g. De Jong functions with a domain for each variable).  I’ll probably add 3-4 other ones specific to the problem that started all this adventure!

Only one immigration policy (no immigration!) is available and it will stay that way for a long time.  I’ll wait until I am hyper confident that this framework is rock solid before introducing parallelism and exchange of individuals between « islands » (i.e. simulations).  This one is a faaaaaaar away!

Six crossover policies are available as of now .  This area will require some (minor I think at first glance) changes for the TSP type of problems : not quite decided on the approach I will take to solve this.  Since crossover is often very problem/chromosome specific, I’ll probably delay those change until the end, once I have all examples coded and ready to be tested to have a better idea of what is needed.  But I will definitely add a few (3-4) crossover policies tailored for the Ruzzle problem.

I have solved the discrepancy (see here and here) between my results and the TSPLIB ones regarding the tour length of the Burma14 problem.  Will probably add a lot bigger TSP problem to see how the framework can handle an extremely huge search space! Oh!  And I need to clean up all the crap I added/modified while looking for the problem of « distance difference » : 2 classes were butchered in the process!

I need to add a few « crash test dummy » classes to test all those different selection policies (and crossover) in a simpler and more efficient manner!  Or I should kick myself in the %*&#$!@ and code the « bits » example classes…

I will soon work on a customizable display of statistics.  All that’s needed is already there, it’s just a matter of gluing everything together!

Once I’m done with the 8 queens problems, I’ll attack the numerically parametrized problems.  Will probably have 2-3 examples (from De Jong functions) as well as the INSANE Griewank function.

The classes used for randomly choosing the next parent chromosomes as well as scaling/ranking can be optimized.  But since they just work great since day 1, I’ll keep that for the very end.  But I know they can be a lot faster than what they are right now.

I also plan on having a very basic export mechanism so I can dump all those ruzzle chromosomes in a MySQL database to be able to do some reporting and study the various policies and their effects.

I started adding comments to the classes, mostly to keep references, maintain a todo list per class and add some notes for myself to quickly remember why things work that way!

I’ll probably have an image by tomorrow that will run simulations for the ruzzle problem full-time. I wanna beat that record!

 

Save

Save

Save

Save

Publicité

Does 1/7 + 6/7 = 1 ?

(Click on image to enlarge)

We often forget how Smalltalk handles some stuff with class (no pun intended!), efficiency and precision…  Mostly because it’s always been that way!  That’s a given for Smalltalkers!

Recently, I was brutally reminded how sad this world is while trying to solve the Burma14 TSP problem.  I couldn’t figure out why I kept having a +24 km difference for the optimal tour so I started looking on the internet.  My program was finding the optimal tour but I could never get a tour length of 3323 km!

I first thought I wasn’t using the proper function to calculate distances.  Then I thought the reference ellipsoid I was using might be different than the one used to come up with 3323 km.  Then I though it could be caused by rounding errors in my code so I used ScaledDecimal, then I thought this, then I thought that, then I read more, then followed links, then more links, then more debugging, then…

Then I found the TSPLIB FAQ.  The culprit happens to be in the degrees to radians conversion method that is used in TSPLIB calculations. It’s not precise.  It’s not very precise at least.  And the value of Pi used in the calculations seems good enough to do the job but, quite frankly, I don’t think it is!  If I can get a 24km difference for a tour of only 14 cities, what would it be like for a tour of a few thousand cities?

Smalltalkers often forget that, in our world, 1/7 + 6/7 equals 1.  And that evaluating 1000!/999! doesn’t bomb and it equals 1000.  And I’m grateful that things are as they should be… in Smalltalk!

Note: if you look at the image at the beginning of this post, you’ll see that in Smalltalk evaluating 1/7 + 6/7 = 1 and  1000!/999! = 1000. And Pi is a little bit more than 3.141592.

Save

Save

Freewill in progress

Freewill was able to solve the Burma14 TSP problem for the first time tonight!

(Click on image to enlarge)

Now, it’s just a matter of discovering why my distance calculations are a little bit different than those from the TSPLIB ones.  Either TSPLIB is using a different formula to calculate its distances (I’m using Haversine) or it’s using different ellipsoid data (I’m using those from WGS84).  But since everybody uses WGS84 nowadays and my distance results are a little bit greater than those from TSPLIB, I suspect it’s using one of the Vincenty formulas.  That’s what I’ll investigate next!

Besides, while looking at the GeoSphere documentation, I was thinking it would be cool to port that stuff to Smalltalk!  Does anyone need this?!?!  Drop me a line if it’s the case!