Two bugs(?) in AbstractSuperGene

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Two bugs(?) in AbstractSuperGene

Christoph Langguth-3
Hi all,

I have discovered two "inconveniences" in the AbstractSuperGene implementation. I'm not sure whether
they can outright be called bugs, but they're certainly exposing rather unexpected behaviour.

The constructor AbstractSupergene(Configuration, Gene[]), in conjunction with the default
newGeneInternal() implementation.

This is implemented in a slightly odd way, because new Objects get instantiated with the *old*,
uncloned subgenes - which are replaced by the newGeneInternal() method *after* the constructor of
the copy had been invoked. IMO this goes against intuition (and usability).

To give an example where it becomes obvious: I need to reference the "parent" supergene from within
my subgenes at times. So the intuitive approach would be (simplified pseudo-code):

class MySuperGene extends AbstractSuperGene {
   public MySuperGene(Configuration c, Gene[] subGenes) {
     for (Gene g: subGenes) {

With the current implementation, one needs to create workarounds for this (the easiest being to
"adjust" the newGeneInternal() method. (Which I did anyway for performance reasons, because the
constructor invocation through reflection seems to quickly become a bottleneck). In any case, I
would suggest to minimally change the newGeneInternal() method, so that it uses the copied gene
array for the constructor (pseudo-diff):
-AbstractSupergene age = (AbstractSupergene) constr.newInstance(new Object[] {getConfiguration(),
+AbstractSupergene age = (AbstractSupergene) constr.newInstance(new Object[] {getConfiguration(), g});
if (m_validator != this) {
- age.m_genes = g;

I don't think this would break any existing functionality, but IMO makes life easier and exposes the
intuitively expected behaviour.

I'm heavily using SuperGenes in my project, including SuperGenes composed of SuperGenes composed of
SuperGenes.... And I realized that not everything mutates ;-)
While trying to figure out the reason, I took a closer look at the AbstractSuperGene.applyMutation()
method. Indeed, it's even described in the Javadoc: The method is delegated to the first element of
the gene indexed by 'index'.

Which left me wondering whether that really makes sense... Shouldn't it be mutating the other
elements as well, at times? Or, putting it the other way around, and a bit bluntly: if the other
subgenes are never mutated, why would one implement them as genes in the first place? They could
just as well go (for example) into the applicationData as constants.

I thus changed my "private" implementation so that it randomly picks one of the subgenes to be
mutated. (I'm not sure as to how this should be affected by the mutation rate and such, but that's a
different story...) There's one more catch to this however, in that one can't simply use the
RandomGenerator from the Configuration, because this one doesn't necessarily give a uniform

Ok, I hope that what I wrote is half-way understandable and makes sense as changes to the
AbstractSuperGene. Any feedback or comments on these issues is highly appreciated. :-)

Thanks a lot & cheers

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.
jgap-users mailing list
[hidden email]

smime.p7s (9K) Download Attachment