neat-pythonuses for XOR are actually add_neuron_pr = del_neuron_pr = 0.2, add_conn_pr = del_conn_pr = 0.5. I imagine this could facilitate faster evolution because it mutates more, while not necessarily drifting toward higher complexity. I mean compare with only having the probability of adding neurons and connections: I noticed that we have to set a very low probability like
0.002because else it will very quickly grow in complexity.
error[E0428]: the name `_IMPL_SERIALIZE_FOR_ConnectionGene` is defined multiple times --> /Users/adelprokurov/.cargo/git/checkouts/rustneat-edbea00d81431b08/a80e622/src/nn/gene.rs:55:42 | 54 | #[derive(Debug, Copy, Clone, Serialize, Deserialize)] | --------- previous definition of the value `_IMPL_SERIALIZE_FOR_ConnectionGene` here 55 | #[cfg_attr(feature = "telemetry", derive(Serialize))] | ^^^^^^^^^ `_IMPL_SERIALIZE_FOR_ConnectionGene` redefined here | = note: `_IMPL_SERIALIZE_FOR_ConnectionGene` must be defined only once in the value namespace of this module error[E0119]: conflicting implementations of trait `nn::_IMPL_DESERIALIZE_FOR_NeuralNetwork::_serde::Serialize` for type `nn::gene::ConnectionGene`: --> /Users/adelprokurov/.cargo/git/checkouts/rustneat-edbea00d81431b08/a80e622/src/nn/gene.rs:54:30 | 54 | #[derive(Debug, Copy, Clone, Serialize, Deserialize)] | ^^^^^^^^^ conflicting implementation for `nn::gene::ConnectionGene` 55 | #[cfg_attr(feature = "telemetry", derive(Serialize))] | --------- first implementation here error: aborting due to 2 previous errors
cargo buildyields no errors. Maybe I, or you, have to
rustup update. What's your rustc version?
evaluate_inwithout parallel iteration?
@TLmaK0 Are you available?
As you can see I finally got around to break it down into smaller PRs.
However I have a suggestion to an alternative approach; equivalent to multiple PRs if I understand correctly your goal.
I understood that the reason you want more smaller PRs is that then you can more easily go through the changes one by one.
I just made two PRs that follow each other, but I realize that github won't let you see the difference between these PRs. Actually right now I'm working on making only one single commit for each PR. So you can see the changes in each PR by looking at its commit.
But that leads me to the question: since all these PRs will follow on each other, why not just make one big PR, but with one commit for each functionality?