RtNEAT AI engine resource

#41 I vote for 3, it may well be possible that a few preprocessor definitions would take care of the problem. That way, any advantages of the TMM block memory allocations would pass to the rtNeat code and given the nature of the training cycles, that's got to be a good thing.

Edit: A brief try at doing this was fruitless. First, the preprocessor won't allow colons in #defines so the options there became limited. A second try at converting std::vector references into Vector class references also got boloxed up in a hurry. More time and rigor would be needed to do this. I'm sticking with eliminating TMM for the time being as it works well enough for me.

#42 Tim:
To bad it didn't work :-(
The question is if rtNEAT is going to evolve (I guess it does), if it doesn't we could make the changes hard.

#43 I been reading up in the Feature Selection version of NEAT (FS-NEAT) and it seems to
be a really neat (no pun ;-) think to add to rtNEAT.

FS-NEAT starts up unconnected, well it evolves one connection at start-up, but it is truly minimal.
This means that one can add as many inputs (and outputs as it look like) one wants to try out
and the network will be evolve only using the ones that are necessary, making the network
minimal and very efficient for real-time use.

In regular NEAT (and rtNEAT) a truly minimal startup network only consists of a fully connected
network without hidden nodes. That is n*m connections (where n is number of input and m number
of output nodes).
For large sets of input and output nodes this can be a really big network, it is possible to
minimize it by hand by adding a set of hidden nodes (resulting in n*h+m*h connections, which
would be smaller for large n and m's).

But this is a manual procedure, FS-NEAT would remove this problem by evolving the connections instead.

Another idea I've had is to use multiple fitness functions and in that evolve different
behaviours at the same time. I haven't laid done exactly how to implement this, but I'm
thinking in lines with having different winning fitness functions for different species.

Another idea I have (I have a lot of them) is to make the neuroevolution parameters a part
of the learning algorithm (e.g. connect the parameters as output (and possibly input) nodes).
In this way the neuroevolution
would optimise the neuroevolution process at the same time as the network evolves.
(In fact I'm thinking about evolving other stuff in parallel as well, such as model design
and other non AI features like physics) and doing this at the same time as the "brain" evolves.

I haven't looked at the roving eye features search but it might be interesting as well
(for instance for a ray casting sensor or ears that I like to try out sometime (for
instance a pair of "stereo" ears that can be directed individually on a scale
from back to front, it would be use for a creature that could track its pray buy
scaning with it's ears :-)

Ok, I also been peeking at Tyler E. Streeter's (Verve creator) master thesis.
He seems to have given up on using NEAR to evolve a biped walker because NEAR
wasn't real-time evolving (which rtNEAR is) and not
being good at handle temporal sequences. Well, I intend to try this out (biped walking)
by modifying rtNEAT to also evolve delays for the signal passing the neuron
(simulating different lengths of synapses, as in spiking neural networks).
I think this might give interesting results.

(Well I got to find time to do all this too :-)

#44 Hey Mike,
Did you get an answer from TU about the license?

#45 No I have not actually, I will email again tomorrow