branecloud Wiki Rss Feed

Updated Wiki: Home

bstabile — Thu, 26 Jul 2012 03:05:07 GMT

Project Description

Industrial-Strength Evolutionary Computation for .NET 4.0

This is an independent port of Sean Luke's venerable ECJ project (GMU EC Lab) Version 20

NOTE: This conversion to C# cannot and will not in any way be supported by Sean or any other member of his team at GMU. Please do not even ask! It is incredible that software of this caliber is made available in open-source form, and that is more than enough support!

It is hard to imagine how many hours Sean and his team have put into this over the course of 13 years. But suffice it to say:
ECJ is an 800 lb Gorilla in the realm of Evolutionary Computation and Stochastic Optimization.

MILD WARNING: ECJ is used for some very serious business (and this C# version has, or will shortly have, all of the same capabilities). But you don't need to get scared off by that. A comprehensive collection of samples is provided with ECJ, and the documentation that you can browse on Sean's site covers all of the basics and well beyond. I highly recommend that newbies work with ECJ in JAVA before you decide if this converted fork makes sense for you. The need for tight native .NET platform integration is potentially uncalled for, and you must ask yourself, "Do I really Need This?". Chances are, you don't. But I personally really DO need this, and I’m happy to spare others with similar requirements all of the heavy lifting required to get it this far. Trust me, it is a DAUNTING challenge to preserve delicate algorithms when there are so many moving parts.

I have made all of the samples bundled in the original Java version equally accessible to those of you who need orientation in C#. Each sample is set up as a bare-bones console app that you can "fiddle" with to your heart's content. But also, and this is something that is NOT provided in the original software, there are over 500 unit tests that I wrote during the conversion process. This turns out to be quite a useful side-effect of going through the whole torturous exercise in the first place! These tests, although perhaps still a little incoherent in places (because they focus on specific conversion issues), make it even easier to dig deep without stumbling around in total bewilderment (well, you may still stumble around, but they do provide a bit of a handrail to lean on when you start feeling sick to your stomach). \'-)

Side Note: There are likely to wind up being several thousands of tests associated with this software. I only covered what was causing difficulty during the conversion process, and that is but a small fraction of the full coverage this software deserves. ("sheesh", as Sean is wont to say, I must be freaking crazy!)

If you are not familiar with the purpose of this software, you can purchase Sean's excellent book entitled The Essentials of Metaheuristics (or download the electronic version for free). You can also find numerous articles and academic papers on the website listed above, covering a variety of related topics. If you plan on doing really serious work in this field, you might also consider starting out with the early works of John Koza (Genetic Programming I, II, et al) and then move on through the ever-expanding body of research that grew from there. Or if you really get serious about this stuff, you will probably want to start all the way back with John Holland, who as many of you may already know, is generally considered the "father" of research into the field of Genetic Algorithms.

ECJ targets Java, because large scale evolutionary processes often need to interoperate seamlessly between workstations, which may or may not be hosting Windows, and back-end "heavy metal" hosting one of the UNIX/LINUX variants. Such environments are typical in many large enterprise and academic research settings, as you all well know (or know all too well!). If that kind of heterogeneous environment describes where YOU develop complex systems to solve difficult problems, then you will definitely want to trot on over to Sean's lab and familiarize yourself with the Java "source" code.

On the other hand..., if you develop your software for homogenous environments with Windows7 and Server 2003/2008/2008R2, then you may want to consider downloading the converted Open Source C# code hosted here to take full advantage of tight integration with the latest features provided by .NET 4.0.

Obviously I won't be able to deliver anywhere near the same level of support that a dedicated team can provide (almost none at all in fact). But if you are willing to work hard at it, or if you just want to experiment with the basics, everything you need to go the full distance is (or will shortly be) available in the download. I didn't leave anything out. But I should repeat the warning given above: some things have NOT YET been covered in the unit tests. I haven't had the time, for example, to test whether the Master / Slave communications are working (it uses simple sockets, so I'm not too worried about that, because I'll be migrating it to WCF4). Same goes for Island Exchange for speciation, coevolution, and maybe another thing or two. The ECJ team was actively revamping some of the code for a robotics exercise while I was still in the middle of the conversion. Those gaps in coverage will be closed in due course.

I'll also revisit the ECJ SVN repository in coming weeks to pick up any new bits that show up and integrate any bug fixes and significant changes.

The goal for this project is to try and deliver a conversion of the latest bits as they accrue in ECJ, while maintaining a robust and flexible platform on which to develop in C#, F#, IronPython, IronRuby, VB.NET and so on. I will also be keeping my eye out for other juicy plums that will integrate nicely with this software. In fact, ECJ has a sibling project for "Multi-Agent Simulation of Neighborhoods, or Networks (or something)" (aka MASON) that fits the bill perfectly ("sheesh", I must be out of my freaking mind!). And integration with Microsoft's Project Trident collaborative scientific research platform seems like a yes-braner. But there are also many other interesting possibilities. Stay tuned!

NOTE: This software is a central feature in a much larger development picture that is partially laid out in the Vision statement. Additional information will be made available in the Documentation.

BTW: BraneCloud is linked to a registered domain (net|com) for future things like name/schema resolution in the cloud. So the only thing I ask if you want to derive your own fork from this one is that you please use a different root namespace to avoid collisions. Other that that, you are free to do with this what you will, so long as it abides by the stated licensing terms:

ECJ License (AFL 3.0)
BraneCloud.Evolution.EC (Apache 2.0)

(Sean informs me that he may eventually be switching to the Apache license when he gets around to it.)

Updated Wiki: Home

bstabile — Thu, 26 Jul 2012 03:02:11 GMT

Project Description

Industrial-Strength Evolutionary Computation for .NET 4.0

This is an independent port of Sean Luke's venerable ECJ project (GMU EC Lab) Version 20

NOTE: This conversion to C# cannot and will not in any way be supported by Sean or any other member of his team at GMU. Please do not even ask! It is incredible that software of this caliber is made available in open-source form, and that is more than enough support!

It is hard to imagine how many hours Sean and his team have put into this over the course of 13 years. But suffice it to say:
ECJ is an 800 lb Gorilla in the realm of Evolutionary Computation and Stochastic Optimization.

MILD WARNING: ECJ is used for some very serious business (and this C# version has, or will shortly have, all of the same capabilities). But you don't need to get scared off by that. A comprehensive collection of samples is provided with ECJ, and the documentation that you can browse on Sean's site covers all of the basics and well beyond. I highly recommend that newbies work with ECJ in JAVA before you decide if this converted fork makes sense for you. The need for tight native .NET platform integration is potentially uncalled for, and you must ask yourself, "Do I really Need This?". Chances are, you don't. But I personally really DO need this, and I’m happy to spare others with similar requirements all of the heavy lifting required to get it this far. Trust me, it is a DAUNTING challenge to preserve delicate algorithms when there are so many moving parts.

I have made all of the samples bundled in the original Java version equally accessible to those of you who need orientation in C#. Each sample is set up as a bare-bones console app that you can "fiddle" with to your heart's content. But also, and this is something that is NOT provided in the original software, there are over 500 unit tests that I wrote during the conversion process. This turns out to be quite a useful side-effect of going through the whole torturous exercise in the first place! These tests, although perhaps still a little incoherent in places (because they focus on specific conversion issues), make it even easier to dig deep without stumbling around in total bewilderment (well, you may still stumble around, but they do provide a bit of a handrail to lean on when you start feeling sick to your stomach). \'-)

Side Note: There are likely to wind up being several thousands of tests associated with this software. I only covered what was causing difficulty during the conversion process, and that is but a small fraction of the full coverage this software deserves. ("sheesh", as Sean is wont to say, I must be freaking crazy!)

If you are not familiar with the purpose of this software, you can purchase Sean's excellent book entitled The Essentials of Metaheuristics (or download the electronic version for free). You can also find numerous articles and academic papers on the website listed above, covering a variety of related topics. If you plan on doing really serious work in this field, you might also consider starting out with the early works of John Koza (Genetic Programming I, II, et al) and then move on through the ever-expanding body of research that grew from there. Or if you really get serious about this stuff, you will probably want to start all the way back with John Holland, who as many of you may already know, is generally considered the "father" of research into the field of Genetic Algorithms.

ECJ targets Java, because large scale evolutionary processes often need to interoperate seamlessly between workstations, which may or may not be hosting Windows, and back-end "heavy metal" hosting one of the UNIX/LINUX variants. Such environments are typical in many large enterprise and academic research settings, as you all well know (or know all too well!). If that kind of heterogeneous environment describes where YOU develop complex systems to solve difficult problems, then you will definitely want to trot on over to Sean's lab and familiarize yourself with the Java "source" code.

On the other hand..., if you develop your software for homogenous environments with Windows7 and Server 2003/2008/2008R2, then you may want to consider downloading the converted Open Source C# code hosted here to take full advantage of tight integration with the latest features provided by .NET 4.0.

Obviously I won't be able to deliver anywhere near the same level of support that a dedicated team can provide (almost none at all in fact). But if you are willing to work hard at it, or if you just want to experiment with the basics, everything you need to go the full distance is (or will shortly be) available in the download. I didn't leave anything out. But I should repeat the warning given above: some things have NOT YET been covered in the unit tests. I haven't had the time, for example, to test whether the Master / Slave communications are working (it uses simple sockets, so I'm not too worried about that, because I'll be migrating it to WCF4). Same goes for Island Exchange for speciation, coevolution, and maybe another thing or two. The ECJ team was actively revamping some of the code for a robotics exercise while I was still in the middle of the conversion. Those gaps in coverage will be closed in due course.

I'll also revisit the ECJ SVN repository in coming weeks to pick up any new bits that show up and integrate any bug fixes and significant changes.

The goal for this project is to try and deliver a conversion of the latest bits as they accrue in ECJ, while maintaining a robust and flexible platform on which to develop in C#, F#, IronPython, IronRuby, VB.NET and so on. I will also be keeping my eye out for other juicy plums that will integrate nicely with this software. In fact, ECJ has a sibling project for "Multi-Agent Simulation of Neighborhoods, or Networks (or something)" (aka MASON) that fits the bill perfectly ("sheesh", I must be out of my freaking mind!). And integration with Microsoft's Project Trident collaborative scientific research platform seems like a yes-braner. But there are also many other interesting possibilities. Stay tuned!

ECJ License (AFL 3.0)
BraneCloud.Evolution.EC (Apache 2.0)

(Sean informs me that he may eventually be switching to the Apache license when he gets around to it.)

Updated Wiki: Home

bstabile — Thu, 24 May 2012 18:55:41 GMT

Project Description

Industrial-Strength Evolutionary Computation for .NET 4.0

This is an independent port of Sean Luke's venerable ECJ project (GMU EC Lab) Version 20

NOTE: This conversion to C# cannot and will not in any way be supported by Sean or any other member of his team at GMU. Please do not even ask! It is incredible that software of this caliber is made available in open-source form, and that is more than enough support!

It is hard to imagine how many hours Sean and his team have put into this over the course of 13 years. But suffice it to say:
ECJ is an 800 lb Gorilla in the realm of Evolutionary Computation and Stochastic Optimization.

MILD WARNING: ECJ is used for some very serious business (and this C# version has, or will shortly have, all of the same capabilities). But you don't need to get scared off by that. A comprehensive collection of samples is provided with ECJ, and the documentation that you can browse on Sean's site covers all of the basics and well beyond. I highly recommend that newbies work with ECJ in JAVA before you decide if this converted fork makes sense for you. The need for tight native .NET platform integration is potentially uncalled for, and you must ask yourself, "Do I really Need This?". Chances are, you don't. But I personally really DO need this, and I’m happy to spare others with similar requirements all of the heavy lifting required to get it this far. Trust me, it is a DAUNTING challenge to preserve delicate algorithms when there are so many moving parts.

I have made all of the samples bundled in the original Java version equally accessible to those of you who need orientation in C#. Each sample is set up as a bare-bones console app that you can "fiddle" with to your heart's content. But also, and this is something that is NOT provided in the original software, there are over 500 unit tests that I wrote during the conversion process. This turns out to be quite a useful side-effect of going through the whole torturous exercise in the first place! These tests, although perhaps still a little incoherent in places (because they focus on specific conversion issues), make it even easier to dig deep without stumbling around in total bewilderment (well, you may still stumble around, but they do provide a bit of a handrail to lean on when you start feeling sick to your stomach). \'-)

Side Note: There are likely to wind up being several thousands of tests associated with this software. I only covered what was causing difficulty during the conversion process, and that is but a small fraction of the full coverage this software deserves. ("sheesh", as Sean is wont to say, I must be freaking crazy!)

If you are not familiar with the purpose of this software, you can purchase Sean's excellent book entitled The Essentials of Metaheuristics (or download the electronic version for free). You can also find numerous articles and academic papers on the website listed above, covering a variety of related topics. If you plan on doing really serious work in this field, you might also consider starting out with the early works of John Koza (Genetic Programming I, II, et al) and then move on through the ever-expanding body of research that grew from there. Or if you really get serious about this stuff, you will probably want to start all the way back with John Holland, who as many of you may already know, is generally considered the "father" of research into the field of Genetic Algorithms.

ECJ targets Java, because large scale evolutionary processes often need to interoperate seamlessly between workstations, which may or may not be hosting Windows, and back-end "heavy metal" hosting one of the UNIX/LINUX variants. Such environments are typical in many large enterprise and academic research settings, as you all well know (or know all too well!). If that kind of heterogeneous environment describes where YOU develop complex systems to solve difficult problems, then you will definitely want to trot on over to Sean's lab and familiarize yourself with the Java "source" code.

On the other hand..., if you develop your software for homogenous environments with Windows7 and Server 2003/2008/2008R2, then you may want to consider downloading the converted Open Source C# code hosted here to take full advantage of tight integration with the latest features provided by .NET 4.0.

Obviously I won't be able to deliver anywhere near the same level of support that a dedicated team can provide (almost none at all in fact). But if you are willing to work hard at it, or if you just want to experiment with the basics, everything you need to go the full distance is (or will shortly be) available in the download. I didn't leave anything out. But I should repeat the warning given above: some things have NOT YET been covered in the unit tests. I haven't had the time, for example, to test whether the Master / Slave communications are working (it uses simple sockets, so I'm not too worried about that, because I'll be migrating it to WCF4). Same goes for Island Exchange for speciation, coevolution, and maybe another thing or two. The ECJ team was actively revamping some of the code for a robotics exercise while I was still in the middle of the conversion. Those gaps in coverage will be closed in due course.

I'll also revisit the ECJ SVN repository in coming weeks to pick up any new bits that show up and integrate any bug fixes and significant changes.

The goal for this project is to try and deliver a conversion of the latest bits as they accrue in ECJ, while maintaining a robust and flexible platform on which to develop in C#, F#, IronPython, IronRuby, VB.NET and so on. I will also be keeping my eye out for other juicy plums that will integrate nicely with this software. In fact, ECJ has a sibling project for "Multi-Agent Simulation of Neighborhoods, or Networks (or something)" (aka MASON) that fits the bill perfectly ("sheesh", I must be out of my freaking mind!). And integration with Microsoft's Project Trident collaborative scientific research platform seems like a no-brainer. But there are also many other interesting possibilities. Stay tuned!

ECJ License (AFL 3.0)
BraneCloud.Evolution.EC (Apache 2.0)

(Sean informs me that he may eventually be switching to the Apache license when he gets around to it.)

Updated Wiki: Home

bstabile — Wed, 29 Jun 2011 17:38:01 GMT

Project Description

Industrial-Strength Evolutionary Computation for .NET 4.0

This is an independent port of Sean Luke's venerable ECJ project (GMU EC Lab) Version 20

NOTE: This conversion to C# cannot and will not in any way be supported by Sean or any other member of his team at GMU. Please do not even ask! It is incredible that software of this caliber is made available in open-source form, and that is more than enough support!

It is hard to imagine how many hours Sean and his team have put into this over the course of 13 years. But suffice it to say:
ECJ is an 800 lb Gorilla in the realm of Evolutionary Computation and Stochastic Optimization.

MILD WARNING: ECJ is used for some very serious business (and this C# version has, or will shortly have, all of the same capabilities). But you don't need to get scared off by that. A comprehensive collection of samples is provided with ECJ, and the documentation that you can browse on Sean's site covers all of the basics and well beyond. I highly recommend that newbies work with ECJ in JAVA before you decide if this converted fork makes sense for you. The need for tight native .NET platform integration is potentially uncalled for, and you must ask yourself, "Do I really Need This?". Chances are, you don't. But I personally really DO need this, and I’m happy to spare others with similar requirements all of the heavy lifting required to get it this far. Trust me, it is a DAUNTING challenge to preserve delicate algorithms when there are so many moving parts.

I have made all of the samples bundled in the original Java version equally accessible to those of you who need orientation in C#. Each sample is set up as a bare-bones console app that you can "fiddle" with to your heart's content. But also, and this is something that is NOT provided in the original software, there are over 500 unit tests that I wrote during the conversion process. This turns out to be quite a useful side-effect of going through the whole torturous exercise in the first place! These tests, although perhaps still a little incoherent in places (because they focus on specific conversion issues), make it even easier to dig deep without stumbling around in total bewilderment (well, you may still stumble around, but they do provide a bit of a handrail to lean on when you start feeling sick to your stomach). \'-)

Side Note: There are likely to wind up being several thousands of tests associated with this software. I only covered what was causing difficulty during the conversion process, and that is but a small fraction of the full coverage this software deserves. ("sheesh", as Sean is wont to say, I must be freaking crazy!)

If you are not familiar with the purpose of this software, you can purchase Sean's excellent book entitled The Essentials of Metaheuristics (or download the electronic version for free). You can also find numerous articles and academic papers on the website listed above, covering a variety of related topics. If you plan on doing really serious work in this field, you might also consider starting out with the early works of John Koza (Genetic Programming I, II, et al) and then move on through the ever-expanding body of research that grew from there. Or if you really get serious about this stuff, you will probably want to start all the way back with John Holland, who as many of you may already know, is generally considered the "father" of research into the field of Genetic Algorithms.

ECJ targets Java, because large scale evolutionary processes often need to interoperate seamlessly between workstations, which may or may not be hosting Windows, and back-end "heavy metal" hosting one of the UNIX/LINUX variants. Such environments are typical in many large enterprise and academic research settings, as you all well know (or know all too well!). If that kind of heterogeneous environment describes where YOU develop complex systems to solve difficult problems, then you will definitely want to trot on over to Sean's lab and familiarize yourself with the Java "source" code.

On the other hand..., if you develop your software for homogenous environments with Windows7 and Server 2003/2008/2008R2, then you may want to consider downloading the converted Open Source C# code hosted here to take full advantage of tight integration with the latest features provided by .NET 4.0.

Obviously I won't be able to deliver anywhere near the same level of support that a dedicated team can provide (almost none at all in fact). But if you are willing to work hard at it, or if you just want to experiment with the basics, everything you need to go the full distance is (or will shortly be) available in the download. I didn't leave anything out. But I should repeat the warning given above: some things have NOT YET been covered in the unit tests. I haven't had the time, for example, to test whether the Master / Slave communications are working (it uses simple sockets, so I'm not too worried about that, because I'll be migrating it to WCF4). Same goes for Island Exchange for speciation, coevolution, and maybe another thing or two. The ECJ team was actively revamping some of the code for a robotics exercise while I was still in the middle of the conversion. Those gaps in coverage will be closed in due course.

I'll also revisit the ECJ SVN repository in coming weeks to pick up any new bits that show up and integrate any bug fixes and significant changes.

The goal for this project is to try and deliver a conversion of the latest bits as they accrue in ECJ, while maintaining a robust and flexible platform on which to develop in C#, F#, IronPython, IronRuby, VB.NET and so on. I will also be keeping my eye out for other juicy plums that will integrate nicely with this software. In fact, ECJ has a sibling project for "Multi-Agent Simulation of Neighborhoods, or Networks (or something)" (aka MASON) that fits the bill perfectly ("sheesh", I must be out of my freaking mind!). And integration with Microsoft's Project Trident collaborative scientific research platform seems like a no-brainer. But there are also many other interesting possibilities. Stay tuned!

ECJ License (AFL 3.0)
BraneCloud.Evolution.EC (Apache 2.0)

(Sean informs me that he may eventually be switching to the Apache license when he gets around to it.)

Updated Wiki: Documentation

bstabile — Thu, 26 May 2011 22:57:21 GMT

There are definitely some things you are going to need to know about before you will understand all of what needed to be done for the conversion to C#/.NET4.

I'll add some real help to describe the ways that this version differs from what you can read about in the Java original, on the ECJ site at GMU. But for now, a few notes will have to do…

NOTES: "FUNCTIONAL EQUIVALENCE"

Almost everything in this software is configurable, making if extremely flexible. The way that BraneCloud achieves equivalent configuration behavior is interesting:

In ECJ the “*.param” files contain simple type assignments by namespace such as "ec.Population". At runtime the code directly instantiates a Population because that type name in the assignment corresponds directly to a type that is locatable (without any need for aliasing).

But in .NET, we need to map those "canonical names" (as they exist in ECJ) to real (.NET) type names before we can search for, and instantiate, each type. Oddly enough, the solution to this issue creates added flexibility.

As follows ...

An attribute, ECConfiguration, is attached to all types that might need to be specified in the configuration files (it does no harm, of course, to alias ANY type). A static class called ECActivator maps a canonical name, specified in the attribute, to a .NET type found in assemblies which are added at runtime.

For Example:

namespace MyNamespace
{
[ECConfiguration("ec.MyType")]
public class MyClass {}
}

Now in the bootstrapping we need to add whatever assembly contains "MyClass" to the activator:

public static Main(...)
{
// ... blah, blah, blah

ECActivator.AddSourceAssembly(Assembly ecAssembly);
ECActivator.AddSourceAssembly(Assembly myAssembly);

// ... blah, blah, blah
}

You will note that I'm adding the main assembly, BraneCloud.Evolution.EC (passed in as "ecAssembly" in this case). This is where most of the important core model types live. And then I'm adding myAssembly where our custom "auxilliary" type is defined. The first step, adding the main EC assembly, could be easily avoided. But it is actually "intentional", because it removes any dependency from the BraneCloud.Evolution.EC.Configuration assembly where the activator is defined. I'm a big believer in Separation of Concerns, and there is absolutely no reason that ECActivator needs to know the identity of ANY assembly ahead of time. You will ALSO note that I'm mapping the "MyClass" type to a canonical name of "MyType". In like manner, we could change the entire canonical path to whatever we want, although one must wonder: for what reason? ;-)

NOTES: "ARCHETYPES"

(To be fair, one often sees this kind of assembly popping up in a myriad of guises - usually named somthing like "contracts", which has slightly more speicalized implications. I am only surprised that Martin Fowler, or someone, hasn't had more to say about it, and I'm surprised that computer science programs haven't been able to compel "better practice" in this area. A lot of "spaghetti" dependency problems can be avoided in this way, and it seems like a standardized name for it would avoid much confusion.)

NOTES: "NAMESPACES"

While the algorithms and apparti provided by ECJ are central to the evolutionary optimization strategy in BraneCloud, there are additional namespaces currently taking shape in my private development branch. It would have been nice to tag this conversion with a simple name like ECCSharp, or something. But that would have created a disconnect from some of the extensions, integrations, and specializations that are planned. If, or when, I release some of these other things, it will become more obvious why added differentiation was required. For example, there are already other conversions in progress and original code existing under the following namespaces:

BraneCloud.Deduction
BraneCloud.Induction
BraneCloud.Presentation
BraneCloud.Representation
BraneCloud.Simulation
BraneCloud.Workflow
Etc.

A significant number of additional namespaces will be added in the future. Things would quickly devolve into mayhem if I tried to use an "alphabet soup" approach.

(MORE NOTES LATER…)

Updated Wiki: Documentation

bstabile — Thu, 26 May 2011 22:55:08 GMT

NOTES: "FUNCTIONAL EQUIVALENCE"

Almost everything in this software is configurable, making if extremely flexible. The way that BraneCloud achieves equivalent configuration behavior is interesting:

As follows ...

For Example:

namespace MyNamespace
{
[ECConfiguration("ec.MyType")]
public class MyClass {}
}

Now in the bootstrapping we need to add whatever assembly contains "MyClass" to the activator:

public static Main(...)
{
// ... blah, blah, blah

ECActivator.AddSourceAssembly(Assembly ecAssembly);
ECActivator.AddSourceAssembly(Assembly myAssembly);

// ... blah, blah, blah
}

NOTES: "ARCHETYPES"

I'm really not sure why it is not a universal practice, but I usually create a separate assembly called "Archetype" for any non-trivial project (the suitability of the name seems remarkably obvious to me). In it go any types that have no outside dependencies aside from the standard "platform" provisions. This allows us to avoid many annoying circular reference problems that ultimately result in bad design as projects grow increasingly complex (when they begin to require more sophisticated factoring). The assembly should remain extremely lightweight no matter how large the project grows (because it is meant to hold mainly interfaces, enumerations, constants, and perhaps a few simple abstract base classes. I'm making note of this here, so that no one gets the wrong idea about what purpose this assembly is meant to serve. There's nothing mystical about it. It's purpose is as simple as simple gets! (To be fair, one often sees this kind of assembly popping up in a myriad of guises - usually named somthing like "contracts", which has slightly more speicalized implications. I am only surprised that Martin Fowler, or someone, hasn't had more to say about it, and I'm surprised that computer science programs haven't been able to compel "better practice" in this area. A lot of "spaghetti" dependency problems can be avoided in this way, and it seems like a standardized name for it would avoid much confusion.)

NOTES: "NAMESPACES"

BraneCloud.Deduction
BraneCloud.Induction
BraneCloud.Presentation
BraneCloud.Representation
BraneCloud.Simulation
BraneCloud.Workflow
Etc.

A significant number of additional namespaces will be added in the future. Things would quickly devolve into mayhem if I tried to use an "alphabet soup" approach.

(MORE NOTES LATER…)

Updated Wiki: Documentation

bstabile — Thu, 26 May 2011 22:53:05 GMT

NOTES: "FUNCTIONAL EQUIVALENCE"

Almost everything in this software is configurable, making if extremely flexible. The way that BraneCloud achieves equivalent configuration behavior is interesting:

As follows ...

For Example:

namespace MyNamespace
{
[ECConfiguration("ec.MyType")]
public class MyClass {}
}

Now in the bootstrapping we need to add whatever assembly contains "MyClass" to the activator:

public static Main(...)
{
// ... blah, blah, blah

ECActivator.AddSourceAssembly(Assembly ecAssembly);
ECActivator.AddSourceAssembly(Assembly myAssembly);

// ... blah, blah, blah
}

You will note that I'm adding the main assembly, BraneCloud.Evolution.EC (passed in as "ecAssembly" in this case). This is where most of the important core model types live. And the n I'm adding myAssembly where our custom "auxilliary" type is defined. The first step, adding the main EC assembly, could be easily avoided. But it is actually "intentional", because it removes any dependency from the BraneCloud.Evolution.EC.Configuration assembly where the activator is defined. I'm a big believer in Separation of Concerns, and there is absolutely no reason that ECActivator needs to know the identity of ANY assembly ahead of time. You will ALSO note that I'm mapping the "MyClass" type to a canonical name of "MyType". In like manner, we could change the entire canonical path to whatever we want, although one must wonder: for what reason? ;-)

NOTES: "ARCHETYPES"

NOTES: "NAMESPACES"

BraneCloud.Deduction
BraneCloud.Induction
BraneCloud.Presentation
BraneCloud.Representation
BraneCloud.Simulation
BraneCloud.Workflow
Etc.

A significant number of additional namespaces will be added in the future. Things would quickly devolve into mayhem if I tried to use an "alphabet soup" approach.

(MORE NOTES LATER…)

Updated Wiki: Documentation

bstabile — Thu, 26 May 2011 22:51:33 GMT

NOTES: "FUNCTIONAL EQUIVALENCE"

Almost everything in this software is configurable, making if extremely flexible. The way that BraneCloud achieves equivalent configuration behavior is interesting:

But in .NET, we need to map those "canonical names" (as they exist in ECJ) to real type names before we can search for, and instantiate, each type. Oddly enough, the solution to this issue creates added flexibility.

As follows ...

For Example:

namespace MyNamespace
{
[ECConfiguration("ec.MyType")]
public class MyClass {}
}

Now in the bootstrapping we need to add whatever assembly contains "MyClass" to the activator:

public static Main(...)
{
// ... blah, blah, blah

ECActivator.AddSourceAssembly(Assembly ecAssembly);
ECActivator.AddSourceAssembly(Assembly myAssembly);

// ... blah, blah, blah
}

You will note that I'm adding the main assembly, BraneCloud.Evolution.EC (passed in as "ecAssembly" in this case). This is where most of the important core model types live. And the n I'm adding myAssembly where our custom "auxilliary" type is defined. The first step, adding the main EC assembly, could be easily avoided. But it is actually "intentional", because it removes any dependency from the BraneCloud.Evolution.EC.Configuration assembly where the activator is defined. I'm a big believer in Separation of Concerns, and there is absolutely no reason that ECActivator needs to know the identity of ANY assembly ahead of time. You will ALSO note that I'm mapping the "MyClass" type to a canonical name of "MyType". In like manner, we could change the entire canonical path to whatever we want, although one must wonder: for what reason? ;-)

NOTES: "ARCHETYPES"

NOTES: "NAMESPACES"

BraneCloud.Deduction
BraneCloud.Induction
BraneCloud.Presentation
BraneCloud.Representation
BraneCloud.Simulation
BraneCloud.Workflow
Etc.

A significant number of additional namespaces will be added in the future. Things would quickly devolve into mayhem if I tried to use an "alphabet soup" approach.

(MORE NOTES LATER…)

Updated Wiki: Home

bstabile — Mon, 23 May 2011 20:23:32 GMT

Project Description

Industrial-Strength Evolutionary Computation for .NET 4.0

This is an independent port of Sean Luke's venerable ECJ project (GMU EC Lab) Version 20

NOTE: This conversion to C# cannot and will not in any way be supported by Sean or any other member of his team at GMU. Please do not even ask! It is incredible that software of this caliber is made available in open-source form, and that is more than enough support!

It is hard to imagine how many hours Sean and his team have put into this over the course of 13 years. But suffice it to say:
ECJ is an 800 lb Gorilla in the realm of Evolutionary Computation and Stochastic Optimization.

MILD WARNING: ECJ is used for some very serious business (and this C# version has, or will shortly have, all of the same capabilities). But you don't need to get scared off by that. A comprehensive collection of samples is provided with ECJ, and the documentation that you can browse on Sean's site covers all of the basics and well beyond. I highly recommend that newbies work with ECJ in JAVA before you decide if this converted fork makes sense for you. The need for tight native .NET platform integration is potentially uncalled for, and you must ask yourself, "Do I really Need This?". Chances are, you don't. But I personally really DO need this, and I’m happy to spare others with similar requirements all of the heavy lifting required to get it this far. Trust me, it is a DAUNTING challenge to preserve delicate algorithms when there are so many moving parts.

I have made all of the samples bundled in the original Java version equally accessible to those of you who need orientation in C#. Each sample is set up as a bare-bones console app that you can "fiddle" with them to your heart's content. But also, and this is something that is NOT provided in the original software, there are over 500 unit tests that I wrote during the conversion process. This turns out to be quite a useful side-effect of going through the whole torturous exercise in the first place! These tests, although perhaps still a little incoherent in places (because they focus on specific conversion issues), make it even easier to dig deep without stumbling around in total bewilderment (well, you may still stumble around, but they do provide a bit of a handrail to lean on when you start feeling sick to your stomach). \'-)

Side Note: There are likely to wind up being several thousands of tests associated with this software. I only covered what was causing difficulty during the conversion process, and that is but a small fraction of the full coverage this software deserves. ("sheesh", as Sean is wont to say, I must be freaking crazy!)

If you are not familiar with the purpose of this software, you can purchase Sean's excellent book entitled The Essentials of Metaheuristics (or download the electronic version for free). You can also find numerous articles and academic papers on the website listed above, covering a variety of related topics. If you plan on doing really serious work in this field, you might also consider starting out with the early works of John Koza (Genetic Programming I, II, et al) and then move on through the ever-expanding body of research that grew from there. Or if you really get serious about this stuff, you will probably want to start all the way back with John Holland, who as many of you may already know, is generally considered the "father" of research into the field of Genetic Algorithms.

ECJ targets Java, because large scale evolutionary processes often need to interoperate seamlessly between workstations, which may or may not be hosting Windows, and back-end "heavy metal" hosting one of the UNIX/LINUX variants. Such environments are typical in many large enterprise and academic research settings, as you all well know (or know all too well!). If that kind of heterogeneous environment describes where YOU develop complex systems to solve difficult problems, then you will definitely want to trot on over to Sean's lab and familiarize yourself with the Java "source" code.

On the other hand..., if you develop your software for homogenous environments with Windows7 and Server 2003/2008/2008R2, then you may want to consider downloading the converted Open Source C# code hosted here to take full advantage of tight integration with the latest features provided by .NET 4.0.

Obviously I won't be able to deliver anywhere near the same level of support that a dedicated team can provide (almost none at all in fact). But if you are willing to work hard at it, or if you just want to experiment with the basics, everything you need to go the full distance is (or will shortly be) available in the download. I didn't leave anything out. But I should repeat the warning given above: some things have NOT YET been covered in the unit tests. I haven't had the time, for example, to test whether the Master / Slave communications are working (it uses simple sockets, so I'm not too worried about that, because I'll be migrating it to WCF4). Same goes for Island Exchange for speciation, coevolution, and maybe another thing or two. The ECJ team was actively revamping some of the code for a robotics exercise while I was still in the middle of the conversion. Those gaps in coverage will be closed in due course.

I'll also revisit the ECJ SVN repository in coming weeks to pick up any new bits that show up and integrate any bug fixes and significant changes.

The goal for this project is to try and deliver a conversion of the latest bits as they accrue in ECJ, while maintaining a robust and flexible platform on which to develop in C#, F#, IronPython, IronRuby, VB.NET and so on. I will also be keeping my eye out for other juicy plums that will integrate nicely with this software. In fact, ECJ has a sibling project for "Multi-Agent Simulation of Neighborhoods, or Networks (or something)" (aka MASON) that fits the bill perfectly ("sheesh", I must be out of my freaking mind!). And integration with Microsoft's Project Trident collaborative scientific research platform seems like a no-brainer. But there are also many other interesting possibilities. Stay tuned!

ECJ License (AFL 3.0)
BraneCloud.Evolution.EC (Apache 2.0)

(Sean informs me that he may eventually be switching to the Apache license when he gets around to it.)

Updated Wiki: Home

bstabile — Mon, 23 May 2011 20:19:35 GMT

Project Description

Industrial-Strength Evolutionary Computation for .NET 4.0

This is an independent port of Sean Luke's venerable ECJ project (GMU EC Lab) Version 20

NOTE: This conversion to C# cannot and will not in any way be supported by Sean or any other member of his team at GMU. Please do not even ask! It is incredible that software of this caliber is made available in open-source form, and that is more than enough support!

It is hard to imagine how many hours Sean and his team have put into this over the course of 13 years. But suffice it to say:
ECJ is an 800 lb Gorilla in the realm of Evolutionary Computation and Stochastic Optimization.

MILD WARNING: ECJ is used for some very serious business (and this C# version has, or will shortly have, all of the same capabilities). But you don't need to get scared off by that. A comprehensive collection of samples is provided with ECJ, and the documentation that you can browse on Sean's site covers all of the basics and well beyond. I highly recommend that newbies work with ECJ in JAVA before you decide if this converted fork makes sense for you. The need for tight native .NET platform integration is potentially uncalled for, and you must ask yourself, "Do I really Need This?". Chances are, you don't. But I personally really DO need this, and I’m happy to spare others with similar requirements all of the heavy lifting required to get it this far. Trust me, it is a DAUNTING challenge to preserve delicate algorithms when there are so many moving parts.

I have made all of the samples bundled in the original Java version equally accessible to those of you who need orientation in C#. Each sample is set up as a bare-bones console app that you can "fiddle" with them to your heart's content. But also, and this is something that is NOT provided in the original software, there are over 500 unit tests that I wrote during the conversion process. This turns out to be quite a useful side-effect of going through the whole torturous exercise in the first place! These tests, although perhaps still a little incoherent in places (because they focus on specific conversion issues), make it even easier to dig deep without stumbling around in total bewilderment (well, you may still stumble around, but they do provide a bit of a handrail to lean on when you start feeling sick to your stomach). \'-)

Side Note: There are likely to wind up being several thousands of tests associated with this software. I only covered what was causing difficulty during the conversion process, and that is but a small fraction of the full coverage this software deserves. ("sheesh", as Sean is wont to say, I must be freaking crazy!)

If you are not familiar with the purpose of this software, you can purchase Sean's excellent book entitled The Essentials of Metaheuristics (or download the electronic version for free). You can also find numerous articles and academic papers on the website listed above, covering a variety of related topics. If you plan on doing really serious work in this field, you might also consider starting out with the early works of John Koza (Genetic Programming I, II, et al) and then move on through the ever-expanding body of research that grew from there. Or if you really get serious about this stuff, you will probably want to start all the way back with John Holland, who as many of you may already know, is generally considered the "father" of research into the field of Genetic Algorithms.

ECJ targets Java, because large scale evolutionary processes often need to interoperate seamlessly between workstations, which may or may not be hosting Windows, and back-end "heavy metal" hosting one of the UNIX/LINUX variants. Such environments are typical in many large enterprise and academic research settings, as you all well know (or know all too well!). If that kind of heterogeneous environment describes where YOU develop complex systems to solve difficult problems, then you will definitely want to trot on over to Sean's lab and familiarize yourself with the Java "source" code.

On the other hand..., if you develop your software for homogenous environments with Windows7 and Server 2003/2008/2008R2, then you may want to consider downloading the converted Open Source C# code hosted here to take full advantage of tight integration with the latest features provided by .NET 4.0.

Obviously I won't be able to deliver anywhere near the same level of support that a dedicated team can provide (almost none at all in fact). But if you are willing to work hard at it, or if you just want to experiment with the basics, everything you need to go the full distance is (or will shortly be) available in the download. I didn't leave anything out. But I should repeat the warning given above: some things have NOT YET been covered in the unit tests. I haven't had the time, for example, to test whether the Master / Slave communications are working (it uses simple sockets, so I'm not too worried about that). Same goes for Island Exchange for speciation, coevolution, and maybe another thing or two. The ECJ team was actively revamping some of the code for a robotics exercise while I was still in the middle of the conversion. Those gaps in coverage will be closed in due course.

I'll also revisit the ECJ SVN repository in coming weeks to pick up any new bits that show up and integrate any bug fixes and significant changes.

The goal for this project is to try and deliver a conversion of the latest bits as they accrue in ECJ, while maintaining a robust and flexible platform on which to develop in C#, F#, IronPython, IronRuby, VB.NET and so on. I will also be keeping my eye out for other juicy plums that will integrate nicely with this software. In fact, ECJ has a sibling project for "Multi-Agent Simulation of Neighborhoods, or Networks (or something)" (aka MASON) that fits the bill perfectly ("sheesh", I must be out of my freaking mind!). And integration with Microsoft's Project Trident collaborative scientific research platform seems like a no-brainer. But there are also many other interesting possibilities. Stay tuned!

ECJ License (AFL 3.0)
BraneCloud.Evolution.EC (Apache 2.0)

(Sean informs me that he may eventually be switching to the Apache license when he gets around to it.)

Updated Wiki: Documentation

bstabile — Sat, 21 May 2011 23:16:48 GMT

There are definitely some things your are going to need to know about before you will understand all of what needed to be done for the conversion to C#/.NET4.

I'll add some real help to describe the ways that this version differs from what you can read about in the Java original, on the ECJ site at GMU. But for now, a few notes will have to do…

NOTES: "FUNCTIONAL EQUIVALENCE"

Almost everything in this software is configurable, making if extremely flexible. The way that BraneCloud achieves equivalent configuration behavior is interesting:

As follows ...

For Example:

namespace MyNamespace
{
[ECConfiguration("ec.MyType")]
public class MyClass {}
}

Now in the bootstrapping we need to add whatever assembly contains "MyClass" to the activator:

public static Main(...)
{
// ... blah, blah, blah

ECActivator.AddSourceAssembly(Assembly ecAssembly);
ECActivator.AddSourceAssembly(Assembly myAssembly);

// ... blah, blah, blah
}

You will note that I'm adding the main assembly, BraneCloud.Evolution.EC (passed in as "ecAssembly" in this case). This is where most of the important core model types live. And the n I'm adding myAssembly where our custom "auxilliary" type is defined. The first step, adding the main EC assembly, could be easily avoided. But it is actually "intentional", because it removes any dependency from the BraneCloud.Evolution.EC.Configuration assembly where the activator is defined. I'm a big believer in Separation of Concerns, and there is absolutely no reason that ECActivator needs to know the identity of ANY assembly ahead of time. You will ALSO note that I'm mapping the "MyClass" type to a canonical name of "MyType". In like manner, we could change the entire canonical path to whatever we want, although one must wonder: for what reason? ;-)

NOTES: "ARCHETYPES"

NOTES: "NAMESPACES"

BraneCloud.Deduction
BraneCloud.Induction
BraneCloud.Presentation
BraneCloud.Representation
BraneCloud.Simulation
BraneCloud.Workflow
Etc.

A significant number of additional namespaces will be added in the future. Things would quickly devolve into mayhem if I tried to use an "alphabet soup" approach.

(MORE NOTES LATER…)

Updated Wiki: Documentation

bstabile — Sat, 21 May 2011 23:11:11 GMT

NOTES: "FUNCTIONAL EQUIVALENCE"

Almost everything in this software is configurable, making if extremely flexible. The way that BraneCloud achieves equivalent configuration behavior is interesting:

As follows ...

For Example:

namespace MyNamespace
{
[ECConfiguration("ec.MyType")]
public class MyClass {}
}

Now in the bootstrapping we need to add whatever assembly contains "MyClass" to the activator:

public static Main(...)
{
// ... blah, blah, blah

ECActivator.AddSourceAssembly(Assembly ecAssembly);
ECActivator.AddSourceAssembly(Assembly myAssembly);

// ... blah, blah, blah
}

You will note that I'm adding the main assembly, BraneCloud.Evolution.EC (passed in as "ecAssembly" in this case). This is where most of the important core model types live. And the n I'm adding myAssembly where our custom "auxilliary" type is defined. The first step, adding the main EC assembly, could be easily avoided. But it is actually "intentional", because it removes any dependency from the BraneCloud.Evolution.EC.Configuration assembly where the activator is defined. I'm a big believer in Separation of Concerns, and there is absolutely no reason that ECActivator needs to know the identity of ANY assembly ahead of time. You will ALSO note that I'm mapping the "MyClass" type to a canonical name of "MyType". In like manner, we could change the entire canonical path to whatever we want, although one must wonder: for what reason? ;-)

NOTES: "ARCHETYPES"

I'm really not sure why it is not a universal practice, but I usually create a separate assembly called "Archetype" for any non-trivial project (the suitability of the name seems remarkably obvious to me). In it go any types that have no outside dependencies aside from the standard "platform" provisions. This allows us to avoid many annoying circular reference problems that ultimately result in bad design as projects grow increasingly complex (when they begin to require more sophisticated factoring). The assembly should remain extremely lightweight no matter how large the project grows (because it is meant to hold mainly interfaces, enumerations, constants, and perhaps a few simple abstract base classes. I'm making note of this here, so that no one gets the wrong idea about what purpose this assembly is meant to serve. There's nothing mystical about it. It's purpose is as simple as simple gets! (To be fair, one often sees this kind of assembly popping up in a myriad of guises. I am only surprised that Martin Fowler, or someone, hasn't had more to say about it, and I'm surprised that computer science programs haven't been able to compel "better practice" in this area. A lot of "spaghetti" dependency problems can be avoided in this way, and it seems like a standardized name for it would avoid much confusion.)

NOTES: "NAMESPACES"

BraneCloud.Deduction
BraneCloud.Induction
BraneCloud.Presentation
BraneCloud.Representation
BraneCloud.Simulation
BraneCloud.Workflow
Etc.

A significant number of additional namespaces will be added in the future. Things would quickly devolve into mayhem if I tried to use an "alphabet soup" approach.

(MORE NOTES LATER…)

Updated Wiki: Documentation

bstabile — Sat, 21 May 2011 23:10:38 GMT

NOTES: "FUNCTIONAL EQUIVALENCE"

Almost everything in this software is configurable, making if extremely flexible. The way that BraneCloud achieves equivalent configuration behavior is interesting:

But in .NET, we need to map those "canonical names" (as they exist in ECJ) to real type names before we can search for, and instantiate,

each type. Oddly enough, the solution to this issue creates added flexibility.

As follows ...

For Example:

namespace MyNamespace
{
[ECConfiguration("ec.MyType")]
public class MyClass {}
}

Now in the bootstrapping we need to add whatever assembly contains "MyClass" to the activator:

public static Main(...)
{
// ... blah, blah, blah

ECActivator.AddSourceAssembly(Assembly ecAssembly);
ECActivator.AddSourceAssembly(Assembly myAssembly);

// ... blah, blah, blah
}

You will note that I'm adding the main assembly, BraneCloud.Evolution.EC (passed in as "ecAssembly" in this case). This is where most of the important core model types live. And the n I'm adding myAssembly where our custom "auxilliary" type is defined. The first step, adding the main EC assembly, could be easily avoided. But it is actually "intentional", because it removes any dependency from the BraneCloud.Evolution.EC.Configuration assembly where the activator is defined. I'm a big believer in Separation of Concerns, and there is absolutely no reason that ECActivator needs to know the identity of ANY assembly ahead of time. You will ALSO note that I'm mapping the "MyClass" type to a canonical name of "MyType". In like manner, we could change the entire canonical path to whatever we want, although one must wonder: for what reason? ;-)

NOTES: "ARCHETYPES"

I'm really not sure why it is not a universal practice, but I usually create a separate assembly called "Archetype" for any non-trivial project (the suitability of the name seems remarkably obvious to me). In it go any types that have no outside dependencies aside from the standard "platform" provisions. This allows us to avoid many annoying circular reference problems that ultimately result in bad design as projects grow increasingly complex (when they begin to require more sophisticated factoring). The assembly should remain extremely lightweight no matter how large the project grows (because it is meant to hold mainly interfaces, enumerations, constants, and perhaps a few simple abstract base classes. I'm making note of this here, so that no one gets the wrong idea about what purpose this assembly is meant to serve. There's nothing mystical about it. It's purpose is as simple as simple gets! (To be fair, one often sees this kind of assembly popping up in a myriad of guises. I am only surprised that Martin Fowler, or someone, hasn't had more to say about it, and I'm surprised that computer science programs haven't been able to compel "better practice" in this area. A lot of "spaghetti" dependency problems can be avoided in this way, and it seems like a standardized name for it would avoid much confusion.)

NOTES: "NAMESPACES"

BraneCloud.Deduction
BraneCloud.Induction
BraneCloud.Presentation
BraneCloud.Representation
BraneCloud.Simulation
BraneCloud.Workflow
Etc.

A significant number of additional namespaces will be added in the future. Things would quickly devolve into mayhem if I tried to use an "alphabet soup" approach.

(MORE NOTES LATER…)

Updated Wiki: Home

bstabile — Fri, 20 May 2011 21:10:23 GMT

Project Description

Industrial-Strength Evolutionary Computation for .NET 4.0

This is an independent port of Sean Luke's venerable ECJ project (GMU EC Lab) Version 20

NOTE: This conversion to C# cannot and will not in any way be supported by Sean or any other member of his team at GMU. Please do not even ask! It is incredible that software of this caliber is made available in open-source form, and that is more than enough support!

It is hard to imagine how many hours Sean and his team have put into this over the course of 13 years. But suffice it to say:
ECJ is an 800 lb Gorilla in the realm of Evolutionary Computation and Stochastic Optimization.

MILD WARNING: ECJ is used for some very serious business (and this C# version has, or will shortly have, all of the same capabilities). But you don't need to get scared off by that. A comprehensive collection of samples is provided with ECJ, and the documentation that you can browse on Sean's site covers all of the basics and well beyond. I highly recommend that newbies work with ECJ in JAVA before you decide if this converted fork makes sense for you. The need for tight native .NET platform integration is potentially uncalled for, and you must ask yourself, "Do I really Need This?". Chances are, you don't. But I personally really DO need this, and I’m happy to spare others with similar requirements all of the heavy lifting required to get it this far. Trust me, it is a DAUNTING challenge to preserve delicate algorithms when there are so many moving parts.

I have made all of the samples bundled in the original Java version equally accessible to those of you who need orientation in C#. Each sample is set up as a bare-bones console app that you can "fiddle" with to your heart's content. But also, and this is something that is NOT provided in the original software, there are over 500 unit tests that I wrote during the conversion process. This turns out to be quite a useful side-effect of going through the whole torturous exercise in the first place! These tests, although perhaps still a little incoherent in places (because they focus on specific conversion issues), make it even easier to dig deep without stumbling around in total bewilderment (well, you may still stumble around, but they do provide a bit of a handrail to lean on when you start feeling sick to your stomach). \'-)

Side Note: There are likely to wind up being several thousands of tests associated with this software. I only covered what was causing difficulty during the conversion process, and that is but a small fraction of the full coverage this software deserves. ("sheesh", as Sean is wont to say, I must be freaking crazy!)

If you are not familiar with the purpose of this software, you can purchase Sean's excellent book entitled The Essentials of Metaheuristics (or download the electronic version for free). You can also find numerous articles and academic papers on the website listed above, covering a variety of related topics. If you plan on doing really serious work in this field, you might also consider starting out with the early works of John Koza (Genetic Programming I, II, et al) and then move on through the ever-expanding body of research that grew from there. Or if you really get serious about this stuff, you will probably want to start all the way back with John Holland, who as many of you may already know, is generally considered the "father" of research into the field of Genetic Algorithms.

ECJ targets Java, because large scale evolutionary processes often need to interoperate seamlessly between workstations, which may or may not be hosting Windows, and back-end "heavy metal" hosting one of the UNIX/LINUX variants. Such environments are typical in many large enterprise and academic research settings, as you all well know (or know all too well!). If that kind of heterogeneous environment describes where YOU develop complex systems to solve difficult problems, then you will definitely want to trot on over to Sean's lab and familiarize yourself with the Java "source" code.

On the other hand..., if you develop your software for homogenous environments with Windows7 and Server 2003/2008/2008R2, then you may want to consider downloading the converted Open Source C# code hosted here to take full advantage of tight integration with the latest features provided by .NET 4.0.

Obviously I won't be able to deliver anywhere near the same level of support that a dedicated team can provide (almost none at all in fact). But if you are willing to work hard at it, or if you just want to experiment with the basics, everything you need to go the full distance is (or will shortly be) available in the download. I didn't leave anything out. But I should repeat the warning given above: some things have NOT YET been covered in the unit tests. I haven't had the time, for example, to test whether the Master / Slave communications are working (it uses simple sockets, so I'm not too worried about that). Same goes for Island Exchange for speciation, coevolution, and maybe another thing or two. The ECJ team was actively revamping some of the code for a robotics exercise while I was still in the middle of the conversion. Those gaps in coverage will be closed in due course.

I'll also revisit the ECJ SVN repository in coming weeks to pick up any new bits that show up and integrate any bug fixes and significant changes.

The goal for this project is to try and deliver a conversion of the latest bits as they accrue in ECJ, while maintaining a robust and flexible platform on which to develop in C#, F#, IronPython, IronRuby, VB.NET and so on. I will also be keeping my eye out for other juicy plums that will integrate nicely with this software. In fact, ECJ has a sibling project for "Multi-Agent Simulation of Neighborhoods, or Networks (or something)" (aka MASON) that fits the bill perfectly ("sheesh", I must be out of my freaking mind!). And integration with Microsoft's Project Trident collaborative scientific research platform seems like a no-brainer. But there are also many other interesting possibilities. Stay tuned!

ECJ License (AFL 3.0)
BraneCloud.Evolution.EC (Apache 2.0)

(Sean informs me that he may eventually be switching to the Apache license when he gets around to it.)

Updated Wiki: Home

bstabile — Thu, 19 May 2011 11:42:03 GMT

Project Description

Industrial-Strength Evolutionary Computation for .NET 4.0

This is an independent port of Sean Luke's venerable ECJ project (GMU EC Lab) Version 20

NOTE: This conversion to C# cannot and will not in any way be supported by Sean or any other member of his team at GMU. Please do not even ask! It is incredible that software of this caliber is made available in open-source form, and that is more than enough support!

It is hard to imagine how many hours Sean and his team have put into this over the course of 13 years. But suffice it to say:
ECJ is an 800 lb Gorilla in the realm of Evolutionary Computation and Stochastic Optimization.

MILD WARNING: ECJ is used for some very serious business (and this C# version has, or will shortly have, all of the same capabilities). But you don't need to get scared off by that. A comprehensive collection of samples is provided with ECJ, and the documentation that you can browse on Sean's site covers all of the basics and well beyond. I highly recommend that newbies work with ECJ in JAVA before you decide if this converted fork makes sense for you. The need for tight native .NET platform integration is potentially uncalled for, and you must ask yourself, "Do I really Need This?". Chances are, you don't. But I personally really DO need this, and I’m happy to spare others with similar requirements all of the heavy lifting required to get it this far. Trust me, it is a DAUNTING challenge to preserve delicate algorithms when there are so many moving parts.

I have made all of the samples bundled in the original Java version equally accessible to those of you who need orientation in C#. Each sample is set up as a bare-bones console app that you can "fiddle" with to your heart's content. But also, and this is something that is NOT provided in the original software, there are over 500 unit tests that I wrote during the conversion process. This turns out to be quite a useful side-effect of going through the whole torturous exercise in the first place! These tests, although perhaps still a little incoherent in places (because they focus on specific conversion issues), make it even easier to dig deep without stumbling around in total bewilderment (well, you may still stumble around, but they do provide a bit of a handrail to lean on when you start feeling sick to your stomach). \'-)

Side Note: There are likely to wind up being several thousands of tests associated with this software. I only covered what was causing difficulty during the conversion process, and that is but a small fraction of the full coverage this software deserves. ("sheesh", as Sean is wont to say, I must be freaking crazy!)

If you are not familiar with the purpose of this software, you can purchase Sean's excellent book entitled The Essentials of Metaheuristics (or download the electronic version for free). You can also find numerous articles and academic papers on the website listed above, covering a variety of related topics. If you plan on doing really serious work in this field, you might also consider starting out with the early works of John Koza (Genetic Programming I, II, et al) and then move on through the ever-expanding body of research that grew from there. Or if you really get serious about this stuff, you will probably want to start all the way back with John Holland, who as many of you may already know, is generally considered the "father" of research into the field of Genetic Algorithms.

ECJ targets Java, because large scale evolutionary processes often need to interoperate seamlessly between workstations, which may or may not be hosting Windows, and back-end "heavy metal" hosting one of the UNIX/LINUX variants. Such environments are typical in many large enterprise and academic research settings, as you all well know (or know all too well!). If that kind of heterogeneous environment describes where YOU develop complex systems to solve difficult problems, then you will definitely want to trot on over to Sean's lab and familiarize yourself with the Java "source" code.

On the other hand..., if you develop your software for homogenous environments with Windows7 and Server 2003/2008/2008R2, then you may want to consider downloading the converted Open Source C# code hosted here to take full advantage of tight integration with the latest features provided by .NET 4.0.

Obviously I won't be able to deliver anywhere near the same level of support that a dedicated team can provide (almost none at all in fact). But if you are willing to work hard at it, or if you just want to experiment with the basics, everything you need to go the full distance is (or will shortly be) available in the download. I didn't leave anything out. But I should repeat the warning given above: some things have NOT YET been covered in the unit tests. I haven't had the time, for example, to test whether the Master / Slave communications are working (it uses simple sockets, so I'm not too worried about that). Same goes for Island Exchange for speciation, coevolution, and maybe another thing or two. The ECJ team was actively revamping some of the code for a robotics exercise while I was still in the middle of the conversion. Those gaps in coverage will be closed in due course.

I'll also revisit the ECJ SVN repository in coming weeks to pick up any new bits that show up and integrate any bug fixes and significant changes.

The goal for this project is to try and deliver a conversion of the latest bits as they accrue in ECJ, while maintaining a robust and flexible platform on which to develop in C#, F#, IronPython, IronRuby, VB.NET and so on. I will also be keeping my eye out for other juicy plums that will integrate nicely with this software. In fact, ECJ has a sibling project for "Multi-Agent Simulation of Neighborhoods, or Networks (or something)" (aka MASON) that fits the bill perfectly ("sheesh", I must be out of my freaking mind!). And integration with Microsoft's Project Trident collaborative scientific research platform seems like a no-brainer. But there are also many other interesting possibilities. Stay tuned!

ECJ License (AFL 3.0)
BraneCloud.Evolution.EC (Apache 2.0)

(Sean informs me that he may eventually be switching to the Apache license when he gets around to it.)

Additional information on starting a new project is available here: Project Startup Guide.

Updated Wiki: Home

bstabile — Tue, 17 May 2011 13:27:30 GMT

Project Description

Industrial-Strength Evolutionary Computation for .NET 4.0

This is an independent port of Sean Luke's venerable ECJ project (GMU EC Lab) Version 20

NOTE: This conversion to C# cannot and will not in any way be supported by Sean or any other member of his team at GMU. Please do not even ask! It is incredible that software of this caliber is made available in open-source form, and that is more than enough support!

It is hard to imagine how many hours Sean and his team have put into this over the course of 13 years. But suffice it to say:
ECJ is an 800 lb Gorilla in the realm of Evolutionary Computation and Stochastic Optimization.

MILD WARNING: ECJ is used for some very serious business (and this C# version has, or will shortly have, all of the same capabilities). But you don't need to get scared off by that. A comprehensive collection of samples is provided with ECJ, and the documentation that you can browse on Sean's site covers all of the basics and well beyond. I highly recommend that newbies work with ECJ in JAVA before you decide if this converted fork makes sense for you. The need for tight native .NET platform integration is potentially uncalled for, and you must ask yourself, "Do I really Need This?". Chances are, you probably don't. But I personally really DO need this, and I’m happy to spare others with similar requirements all of the heavy lifting required to get it this far. Trust me, it is a DAUNTING challenge to preserve delicate algorithms when there are so many moving parts.

I have made all of the samples bundled in the original Java version equally accessible to those of you who need orientation in C#. Each sample is set up as a bare-bones console app that you can "fiddle" with to your heart's content. But also, and this is something that is NOT provided in the original software, there are over 500 unit tests that I wrote during the conversion process. This turns out to be quite a useful side-effect of going through the whole torturous exercise in the first place! These tests, although perhaps still a little incoherent in places (because they focus on specific conversion issues), make it even easier to dig deep without stumbling around in total bewilderment (well, you may still stumble around, but they do provide a bit of a handrail to lean on when you start feeling sick to your stomach). \'-)

Side Note: There are likely to wind up being several thousands of tests associated with this software. I only covered what was causing difficulty during the conversion process, and that is but a small fraction of the full coverage this software deserves. ("sheesh", as Sean is wont to say, I must be freaking crazy!)

If you are not familiar with the purpose of this software, you can purchase Sean's excellent book entitled The Essentials of Metaheuristics (or download the electronic version for free). You can also find numerous articles and academic papers on the website listed above, covering a variety of related topics. If you plan on doing really serious work in this field, you might also consider starting out with the early works of John Koza (Genetic Programming I, II, et al) and then move on through the ever-expanding body of research that grew from there. Or if you really get serious about this stuff, you will probably want to start all the way back with John Holland, who as many of you may already know, is generally considered the "father" of research into the field of Genetic Algorithms.

ECJ targets Java, because large scale evolutionary processes often need to interoperate seamlessly between workstations, which may or may not be hosting Windows, and back-end "heavy metal" hosting one of the UNIX/LINUX variants. Such environments are typical in many large enterprise and academic research settings, as you all well know (or know all too well!). If that kind of heterogeneous environment describes where YOU develop complex systems to solve difficult problems, then you will definitely want to trot on over to Sean's lab and familiarize yourself with the Java "source" code.

On the other hand..., if you develop your software for homogenous environments with Windows7 and Server 2003/2008/2008R2, then you may want to consider downloading the converted Open Source C# code hosted here to take full advantage of tight integration with the latest features provided by .NET 4.0.

Obviously I won't be able to deliver anywhere near the same level of support that a dedicated team can provide (almost none at all in fact). But if you are willing to work hard at it, or if you just want to experiment with the basics, everything you need to go the full distance is (or will shortly be) available in the download. I didn't leave anything out. But I should repeat the warning given above: some things have NOT YET been covered in the unit tests. I haven't had the time, for example, to test whether the Master / Slave communications are working (it uses simple sockets, so I'm not too worried about that). Same goes for Island Exchange for speciation, coevolution, and maybe another thing or two. The ECJ team was actively revamping some of the code for a robotics exercise while I was still in the middle of the conversion. Those gaps in coverage will be closed in due course.

I'll also revisit the ECJ SVN repository in coming weeks to pick up any new bits that show up and integrate any bug fixes and significant changes.

The goal for this project is to try and deliver a conversion of the latest bits as they accrue in ECJ, while maintaining a robust and flexible platform on which to develop in C#, F#, IronPython, IronRuby, VB.NET and so on. I will also be keeping my eye out for other juicy plums that will integrate nicely with this software. In fact, ECJ has a sibling project for "Multi-Agent Simulation of Neighborhoods, or Networks (or something)" (aka MASON) that fits the bill perfectly ("sheesh", I must be out of my freaking mind!). And integration with Microsoft's Project Trident collaborative scientific research platform seems like a no-brainer. But there are also many other interesting possibilities. Stay tuned!

ECJ License (AFL 3.0)
BraneCloud.Evolution.EC (Apache 2.0)

(Sean informs me that he may eventually be switching to the Apache license when he gets around to it.)

Additional information on starting a new project is available here: Project Startup Guide.

Updated Wiki: Documentation

bstabile — Tue, 17 May 2011 13:23:09 GMT

NOTES: "FUNCTIONAL EQUIVALENCE"

Almost everything in this software is configurable, making if extremely flexible. The way that BraneCloud achieves equivalent configuration behavior is interesting:

In ECJ the “*.param” files contain simple type assignments by namespace such as "ec.Population". At runtime the code

directly instantiates a Population because that type name in the assignment corresponds directly to a type that is locatable (without any need for aliasing).

But in .NET, we need to map those "canonical names" (as they exist in ECJ) to real type names before we can search for, and instantiate,

each type. Oddly enough, the solution to this issue creates added flexibility.

As follows ...

For Example:

namespace MyNamespace
{
[ECConfiguration("ec.MyType")]
public class MyClass {}
}

Now in the bootstrapping we need to add whatever assembly contains "MyClass" to the activator:

public static Main(...)
{
// ... blah, blah, blah

ECActivator.AddSourceAssembly(Assembly ecAssembly);
ECActivator.AddSourceAssembly(Assembly myAssembly);

// ... blah, blah, blah
}

You will note that I'm adding the main assembly, BraneCloud.Evolution.EC (passed in as "ecAssembly" in this case). This is where most of the important core model types live. And the n I'm adding myAssembly where our custom "auxilliary" type is defined. The first step, adding the main EC assembly, could be easily avoided. But it is actually "intentional", because it removes any dependency from the BraneCloud.Evolution.EC.Configuration assembly where the activator is defined. I'm a big believer in Separation of Concerns, and there is absolutely no reason that ECActivator needs to know the identity of ANY assembly ahead of time. You will ALSO note that I'm mapping the "MyClass" type to a canonical name of "MyType". In like manner, we could change the entire canonical path to whatever we want, although one must wonder: for what reason? ;-)

NOTES: "ARCHETYPES"

I'm really not sure why it is not a universal practice, but I usually create a separate assembly called "Archetype" for any non-trivial project (the suitability of the name seems remarkably obvious to me). In it go any types that have no outside dependencies aside from the standard "platform" provisions. This allows us to avoid many annoying circular reference problems that ultimately result in bad design as projects grow increasingly complex (when they begin to require more sophisticated factoring). The assembly should remain extremely lightweight no matter how large the project grows (because it is meant to hold mainly interfaces, enumerations, constants, and perhaps a few simple abstract base classes. I'm making note of this here, so that no one gets the wrong idea about what purpose this assembly is meant to serve. There's nothing mystical about it. It's purpose is as simple as simple gets! (To be fair, one often sees this kind of assembly popping up in a myriad of guises. I am only surprised that Martin Fowler, or someone, hasn't had more to say about it, and I'm surprised that computer science programs haven't been able to compel "better practice" in this area. A lot of "spaghetti" dependency problems can be avoided in this way, and it seems like a standardized name for it would avoid much confusion.)

NOTES: "NAMESPACES"

BraneCloud.Deduction
BraneCloud.Induction
BraneCloud.Presentation
BraneCloud.Representation
BraneCloud.Simulation
BraneCloud.Workflow
Etc.

A significant number of additional namespaces will be added in the future. Things would quickly devolve into mayhem if I tried to use an "alphabet soup" approach.

(MORE NOTES LATER…)

Updated Wiki: Documentation

bstabile — Tue, 17 May 2011 12:36:48 GMT

NOTES: "FUNCTIONAL EQUIVALENCE"

Almost everything in this software is configurable, making if extremely flexible. The way that BraneCloud achieves equivalent configuration behavior is interesting:

In ECJ the “*.param” files contain simple type assignments by namespace such as "ec.Population". At runtime the code

directly instantiates a Population because that type name in the assignment corresponds directly to a type that is locatable (without any need for aliasing).

But in .NET, we need to map those "canonical names" (as they exist in ECJ) to real type names before we can search for, and instantiate,

each type. Oddly enough, the solution to this issue creates added flexibility.

As follows ...

For Example:

namespace MyNamespace
{
[ECConfiguration("ec.MyType")]
public class MyClass {}
}

Now in the bootstrapping we need to add whatever assembly contains "MyClass" to the activator:

public static Main(...)
{
// ... blah, blah, blah

ECActivator.AddSourceAssembly(Assembly ecAssembly);
ECActivator.AddSourceAssembly(Assembly myAssembly);

// ... blah, blah, blah
}

You will note that I'm adding the main assembly, BraneCloud.Evolution.EC (passed in as "ecAssembly" in this case). This is where most of the important core model types live. And the n I'm adding myAssembly where our custom "auxilliary" type is defined. The first step, adding the main EC assembly, could be easily avoided. But it is actually "intentional", because it removes any dependency from the BraneCloud.Evolution.EC.Configuration assembly where the activator is defined. I'm a big believer in Separation of Concerns, and there is absolutely no reason that ECActivator needs to know the identity of ANY assembly ahead of time. You will ALSO note that I'm mapping the "MyClass" type to a canonical name of "MyType". In like manner, we could change the entire canonical path to whatever we want, although one must wonder: for what reason? ;-)

NOTES: "ARCHETYPES"

I'm really not sure why it is not a universal practice, but I usually create a separate assembly called "Archetype" for any non-trivial project (the suitability of the name seems remarkably obvious to me). In it go any types that have no outside dependencies aside from the standard "platform" provisions. This allows us to avoid many annoying circular reference problems that ultimately result in bad design as projects grow increasingly complex (when they begin to require more sophisticated factoring). The assembly should remain extremely lightweight no matter how large the project grows (because it is meant to hold mainly interfaces, enumerations, constants, and perhaps a few simple abstract base classes. I'm making note of this here, so that no one gets the wrong idea about what purpose this assembly is meant to serve. There's nothing mystical about it. It's purpose is as simple as simple gets! (To be fair, one often sees this kind of assembly popping up in a myriad of guises. I am only surprised that Martin Fowler, or someone, hasn't had more to say about it, and I'm surprised that computer science programs haven't been able to compel "better practice" in this area. A lot of "spaghetti" dependency problems can be avoided in this way, and it seems like a standardized name for it would avoid much confusion.)

(MORE NOTES LATER…)

Updated Wiki: Documentation

bstabile — Tue, 17 May 2011 12:03:48 GMT

NOTES: "FUNCTIONAL EQUIVALENCE"

Almost everything in this software is configurable, making if extremely flexible. The way that BraneCloud achieves equivalent configuration behavior is interesting:

In ECJ the “*.param” files contain simple type assignments by namespace such as "ec.Population". At runtime the code

directly instantiates a Population because that type name in the assignment corresponds directly to a type that is locatable (without any need for aliasing).

But in .NET, we need to map those "canonical names" (as they exist in ECJ) to real type names before we can search for, and instantiate,

each type. Oddly enough, the solution to this issue creates added flexibility.

As follows ...

For Example:

namespace MyNamespace
{
[ECConfiguration("ec.MyType")]
public class MyClass {}
}

Now in the bootstrapping we need to add whatever assembly contains "MyClass" to the activator:

public static Main(...)
{
// ... blah, blah, blah

ECActivator.AddSourceAssembly(Assembly ecAssembly);
ECActivator.AddSourceAssembly(Assembly myAssembly);

// ... blah, blah, blah
}

You will note that I'm adding the main assembly, BraneCloud.Evolution.EC (passed in as "ecAssembly" in this case). This is where most of the important core model types live. And the n I'm adding myAssembly where our custom "auxilliary" type is defined. The first step, adding the main EC assembly, could be easily avoided. But it is actually "intentional", because it removes any dependency from the BraneCloud.Evolution.EC.Configuration assembly where the activator is defined. I'm a big believer in Separation of Concerns, and there is absolutely no reason that ECActivator needs to know the identity of ANY assembly ahead of time. You will ALSO note that I'm mapping the "MyClass" type to a canonical name of "MyType". In like manner, we could change the entire canonical path to whatever we want, although one must wonder: for what reason? ;-)

NOTES: "ARCHETYPES"

I'm really not sure why it is not standard practice, but I usually create a separate assembly called "Archetype" for any non-trivial project. In it go any types that have no outside dependencies aside from the standard .NET provisions. This allows us to avoid many annoying circular reference problems that ultimately compel bad design as projects grow increasingly complex and begin to require more sophisticated factoring. The assembly should remain extremely lightweight no matter how large the project grows. And if doesn't, then one should recognize immediately that something is amiss. I'm making note of this here, so that no one gets the wrong idea about what purpose this assembly is meant to serve. It's purpose is as simple as simple gets!

(MORE NOTES LATER…)

Updated Wiki: Documentation

bstabile — Tue, 17 May 2011 11:28:26 GMT

NOTES: "FUNCTIONAL EQUIVALENCE"

The way that BraneCloud achieves equivalent configuration behavior is interesting:

In ECJ the “*.param” files contain simple type assignments by namespace such as "ec.Population". At runtime the code

directly instantiates a Population because that type name in the assignment corresponds directly to a type that is globally known.

But in .NET, we need to map those "canonical names" (as they exist in ECJ) to real type names before we can search for, and instantiate,

each type. Oddly enough, the solution to this issue creates added flexibility.

As follows ...

An attribute, ECConfiguration, is attached to all types that might need to be specified in the configuration files. A static class called ECActivator maps a canonical name, specified in the attribute, to a .NET type found in assemblies which are added at runtime.

For Example:

namespace MyNamespace
{
[ECConfiguration("ec.MyType")]
public class MyClass {}
}

Now in the bootstrapping we need to add whatever assembly contains "MyClass" to the activator:

public static Main(...)
{
// ... blah, blah, blah

ECActivator.AddSourceAssembly(Assembly ecAssembly);
ECActivator.AddSourceAssembly(Assembly myAssembly);

// ... blah, blah, blah
}

You will note that I'm adding the main assembly, BraneCloud.Evolution.EC, where most of the important model types live, along with myAssembly. That preliminary step is intentional (even though we could manage to avoid it), because it removes any dependency from the BraneCloud.Evolution.EC.Configuration assembly where the activator is defined. You will ALSO note that I'm mapping the "MyClass" type to a canonical name of "MyType". In like manner, we could change the entire canonical path to whatever we want, although one must wonder: for what reason? ;-)

(MORE NOTES LATER…)