NewPopulationRandom does not assign random configured activatiors

[steampoweredtaco]

Hi! Thanks for the awesome library. I'm not sure if this is incorrect behavior, but it was unexpected to me. I'm using v3.

When creating a population with NewRandomPopulation it initializes all activators in the initial genome (inputs, hidden, output) with SigmoidSteepenedActivation. I was expecting it to select from the random activations and weights used in the configuration passed in with the opts parameter.

In my use case this activation type doesn't work well on the output node when the network still lacks many hidden nodes. I'd like it to choose from a random as configured or minimally be able to select the default activation node to use for the first random genome.

Maybe a workaround is to tweak them myself after the initial population is created.

Not sure if this is an issue or a feature request. Thanks for your time!

[steampoweredtaco]

Working through my use cases for having a different activation function on the output I realize having a random one doesn't make sense on output nodes since the mutations can never change it on the output nodes. Also with input nodes, it doesn't use an activation function AFAICT.

I think it would still make sense if this used a random option for the hidden nodes generated though.

It would be good to also have a way to change what activation is used to generate the intial output nodes so it isn't always the SigmoidSteepenedActivation type.

[yaricom]

Hello!

Thank you for your comments related to further improvements of the library. It is very useful to get feedback from real users. I'll put it on the list of features to be implemented in next releases.

Meanwhile, maybe it can help you to create population not from random genomes, but rather using simple seed genome defined in YAML file. In this way you will be able to define activation function for the output nodes as well as some other options.

Also, it worth to mention that if you define list of activation functions in the settings it will be used to randomly pick the activation function type when new node added to genome. This can help to have heterogeneous activations among hidden nodes.

I hope my comments was of any help and thank you for ideas of how to improve things further.

Cheers,
Iaroslav

[steampoweredtaco]

Thanks for your time. The idea of seed genome configuration is interesting. I'd need to still randomly generate them and it could be quite large. My workaround thus far is to start off with just a single hidden node (code asserts if 0 hidden nodes are specified) or to iterate over the newely created networks if they need to be more complex and reset the activation to a random one. This second option as a workaround works OK for now.

Since this is working by design and you added the ability to have random generators at creation as a feature to a future release, I'm OK if you want to close this or promote it to a discussion. Thank you.

---

As a side note, I've created a fork and working on improvements and if I make this an option to pick random activations on creations, I'll send it your way. The most recent change was for the nodeID lookup during duplication which was making duplicate function O(n^2) where n is the number of nodes in the network. I think it should now be amortized to O(N) with the memory cost of keeping a hash map of nodes temporarily.

I'll try to give you PR's that make sense, but a lot of my changes are probably out of scope for the original experminent-based approach. I've been needing more control over when and how populations are replicated as my use case isn't as straightforward as running many experiments and breading and running again. Instead, it is a continuous real-time simulation where fitness is based on survival in the simulation and you could consider I have many populations of 1 that asexually reproduced over time. Eventually, I'd like this reproduction over a bread linage of the current species but the population concept has been difficult to wedge into that model as is. It has been a challenge because of the specific model where much of the utility functions are hidden (such as duplicate, reproduce, mutate, etc) and the epoch based system. So I've been reworking items to more easily create my own epoch like generators (RT epoch?) and such and exposing and refactoring much of the internals to be public interface points.

So, that probably is my largest long-term desire (v4?) where much more of the design model patterns are fleshed out with interfaces and existing functionality is reusable outside of the library.