Redesign of CIlib core for 0.8 release

The release of CIlib 0.7.5 will be out soon. We anticipate that this will be the last release of the 0.7.x series of CIlib and work will begin on the new 0.8.x series soon.

With 0.8, a few (large) changes will happen to the core CIlib library. Firstly, we are decoupling the simulator from the library completely. This means that the core library will be exactly that, a core library. Some design desicions made in the past are coming back to haunt us, so we'd rather just fix the problem instead of making it a known issue and living with it.

Additionally, the objects in CIlib currently know far too much about the objects they use etc. The core will migrate to use dependency injection (the hollywood principle) so that:

1. Testability will be a primary concern.
2. Lots of redundant code will disappear.
3. The cleanup will mean better code for the users of the library.

I encourage you to chat to us on the mailing list about these changes, they are long overdue and I'm looking forward to making the changes which will mean a better library.

License updates

After receiving numerous requests to have the default license of CIlib altered, we have changed the license to the LGPL from the GPL.

This change should result in our users linking to the library much more simply. Well, that's about that. Head on over to the website and the forums for more info.

Getting functional

Recently, I've been doing some work in other languages such as Python. I must say, after the initial annoyance, the languages have become rather pleasant to use.

The biggest benefit was the ability to quickly get complex movements of data performed with very little effort in terms of the amount of code that I needed to write. The "functional" way as it were is, in one word, fantastic.

The paradigm advocates immutability (which I absolutely agree with) and concise statements whereby boilerplate code is kept to an absolute minimum. As a result of this, together with my enjoyment of Java has spurred me on to start learning Scala, the best of both worlds as it were. By learning a new language, I hope to improve the APIs available in CIlib. Such improvements will ensure that we focus on the intentions of the algorithms etc and not get bogged down with the implementation related difficulties.

I'd love to one day write concise statements like:

topology.foreach(calculateFitness)

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

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.

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.

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.