Tuesday, November 3, 2009

Slowness? Nope. Just writing up.

It's been a while since I wrote something about of the stuff I'm up to. Currently, finalizing my MSc dissertation is taking priority, but I'll be back to hacking away on some CIlib code soon enough.

The main topics at the moment are the need to correctly fix some of the measurement APIs within the library and of course the pending refactor for dependency injection. Feel free to add some issues (if you have any) at the CIlib Google Code page.

In the meantime, here are some links to my more favored blogs:That should keep you busy :P

Saturday, September 26, 2009

Bootstrapping, the new frontier

Bootstrapping CIlib is providing some interesting challenges.

We need to have a selection of predefined bindings and then have them dynamically overridden when needed. This is only on the specification usage of CIlib, so the API usage will remain relatively unchanged (for the moment - some setters might be removed in future versions)

To address these issues, we have written some interesting code to get the overrides working correctly. This is still very much a work in progress, but I feel we are on the right track at least.

Nothing is set in stone at the moment, but the Bootstrapping API is changing a lot. It's exciting to get the new framework up and running :D

Tuesday, August 25, 2009

Core issues and Dependency Injection

It's something that has been a long time coming, but CIlib is in need of a little core refactoring to ensure that the code is maintainable and most importantly, testable.

I've spent a long time examining the various Dependency Injection (DI) frameworks that are available and I've finally decided on using Guice.

The core of CIlib will rely completely on injection to get the required instances in the required places. This does, however, mean that some serious changes will be needed on the inside, but they will be changes that users will not even notice.

CIlib has some static code (in the form of singleton instances and static accessors - Algorithm.get()) and this will be removed to ensure that the library is what it is supposed to be.

More to come on this refactoring as I get into it.

Also, it's almost time to commit the missing code / algorithms :) Keep an eye out for the new Evolutionary Programming and Evolutionary Strategies algorithms that will make their way into the master branch soon.

Monday, August 17, 2009

Moving home and keeping cool

Well, after some discussion we decided to move CIlib to the domain cilib.net.

It's sorta a blessing actually :) The new host provides us with a lot more freedom and we can install / use what we want.

So, additionally to moving the website, a request was made to create a set of forums. As a result we now have some discussion forums for CIlib on the website. Feel free to head on over to the forums to create an account and get the discussion rolling.

Tuesday, July 21, 2009

Generic selection in CIlib

So, you are busy with a an algorithm and you need to apply a selection to a group of objects.

Generally, you would write some code that implements a selection strategy. Class names such as TournamentSelection, RouletteWheelSelection and RandomSelection seem to be the norm. I've seen these classes many, many times. Feels like a waste doesn't it? I mean how many TournamentSelection classes should a person write in a lifetime? There has to be a better way!

Well, that's what we thought as we thought about the notion of "selection" in CIlib. You may want to select a variety of things, not just specific object such as Individuals. Java generics and a nifty fluent interface come to the rescue.

Fluent interfaces are interfaces that read like natural language. Martin Fowler and Eric Evans first described this kind of API structure. The JMock guys, for example, have developed a very good API for mocking using fluent interfaces. So, how can we use this in CIlib? It's quite simple, actually.

There are a few key concepts that we need to take note of regarding selection:
  • Orderings: This is related to how a list of entries can be arranged.
  • Weighing: Entries may or may not have different levels of importance.
  • Randomness: There may be a need to have a collection of entries and a set of x random entries need to be returned.
  • Number of returned elements: One entry? Two? Twelve?
  • Should the selection be such that only unique entries are returned?
That's a bit to keep track of. Thankfully, most of the hard work has been done.

Keeping the points above in mind, a TournamentSelection is actually a multi-part process. Firstly, a random sub-group of elements needs to be selected. Then from this sub-group, the elements are ordered based on some criteria and the element which is the "best" is then the winner of the tournament and should be returned as the final result for the selection. I'll be honest, it's easy to implement but what about if you want to use a different random number generator? These type of options need to be simple to define.

How about a tournament selection in a one-liner:
Selection.from(elements)
.orderBy(new RandomOrdering<E>(this.random))
.last(tournamentSize)
.orderBy(new SortedOrdering<E>(this.comparator))
.last().singleSelect();

Mixing the Ordering, Weighing and type of selection means that we can do some very interesting selections with what ever the selection type E might be.

For more information regarding all the combinations, please have a look at the CIlib JavaDoc and documentation, or drop us an email on the mailing lists.

Monday, July 13, 2009

First blog entry

I hope this blog will help keep people up to date with the various things currently going on in my mind and that of other developers.

I plan to make this blog something that will enable a lot of discussion, especially about CIlib - as we work towards the future releases of the library.