Find a solution to having a probabilistic crossover method

[sofian]

In my GA library we are using function / function pointers. The problem is that eg. for crossover we are limited to the signature:

typedef void  (*SexualCrossover) (const Chromosome&, const Chromosome&,
                                  Chromosome*, Chromosome*);

Now there are probabilistic crossovers out there that would require an extra probability parameter. The options are:

1. Create yet an extra function type
2. Add a void* to every function type
3. Implementing them as classes

Number (3) would be my preferred way in an OOP approach, and the one that we have used so far. However, I would like to do some tests before just to check what is the memory cost of such an approach ie. test the difference in memory usage.

First consider the function version:

class Patapouf;

typedef int  (*function) (Patapouf& p, int i);

class Patapouf {
public:
  function fn;
  int val;
  Patapouf(function fn_, int val_) : fn(fn_), val(val_) {}
  int call() {
    return (*fn)(*this, val);
  }
};

int test(Patapouf& p, int i) {
  return p.val + i*i*(i-5);
}

int main() {
  Patapouf p(test, 3);
  return p.call();
}

Output size by avr-size

  text     data     bss     dec     hex filename
      0     264       0     264     108 build/avr/small.hex
   text    data     bss     dec     hex filename
    102       0       0     102      66 build/avr/small.o

Now the class version:

class Patapouf;

#include <qualia/core/avrdefs.h>

class Function {
public:
  virtual int call(Patapouf& p, int i)=0;
  virtual ~Function(){}
};

class Patapouf {
public:
  Function* fn;
  int val;
  Patapouf(Function* fn_, int val_) : fn(fn_), val(val_) {}
  int call() {
    return fn->call(*this, val);
  }
};

class FunctionImpl : public Function {
public:
  virtual int call(Patapouf& p, int i) {
    return p.val + i*i*(i-5);
  }
};

int main() {
  FunctionImpl impl;
  Patapouf p(&impl, 3);
  return p.call();
}

The size trace is a lot larger:

   text    data     bss     dec     hex filename
      0     892       0     892     37c build/avr/small.hex
   text    data     bss     dec     hex filename
    202       0       0     202      ca build/avr/small.o

However this seems to be largely due to the inclusion of the delete operator (which gets added anyway in our library). In effect if I remove the virtual destructor here's the trace we get ie. almost the same as for the function:

   text    data     bss     dec     hex filename
      0     292       0     292     124 build/avr/small.hex
  text     data     bss     dec     hex filename
    134       0       0     134      86 build/avr/small.o

Now actually if I remove any virtual code let's see what happens:

class Patapouf;

#include <qualia/core/avrdefs.h>

class Patapouf;

class Function {
public:
  int call(Patapouf& p, int i);
};

class Patapouf {
public:
  Function* fn;
  int val;
  Patapouf(Function* fn_, int val_) : fn(fn_), val(val_) {}
  int call() {
    return fn->call(*this, val);
  }
};

int Function::call(Patapouf& p, int i)
{
   return p.val + i*i*(i-5);
}

int main() {
  Function impl;
  Patapouf p(&impl, 3);
  return p.call();
}

The trace becomes very very small:

   text    data     bss     dec     hex filename
      0     170       0     170      aa build/avr/small.hex
   text    data     bss     dec     hex filename
     52       0       0      52      34 build/avr/small.o

So I think all and all it might not be that bad switching to class-based genetic operators...