HyperNEAT substrate size and classification tasks

[LuukvanKeeken]

Thanks for developing this nice repository! I have two questions/issues (probably due to my inexperience with JAX), and I was wondering if you might have some suggestions/answers.

I've been doing some experiments trying out HyperNEAT on some simple tasks. One issue I'm running into is that my GPU doesn't seem to be able to handle large networks due to storage limits. A population of 1000 with a substrate of two hidden layers with 100 nodes is already near the maximum. Decreasing the population size helps somewhat, but I can't get near at least tens of thousands of neurons I was hoping for, and of course for the evolutionary process the population should also be kept sufficiently large.

Aside from using a larger GPU, or the multi-GPU setup, do you have some suggestions for getting around these substrate size limits?

A second question I have is related to trying to implement classification with a kind of population encoding. That is, each class would be represented by some number of output nodes. The class for which the sum of activations in its corresponding group of nodes is largest is selected as the network's class prediction. I've started simple with a binary classification task and just one neuron per class, i.e. just two neurons in the second-to-last layer. For the singular output node I've implemented two aggregation functions. One to filter out the NaNs in the input, leaving just the two activations coming from the previous two nodes. Another to perform argmax, returning then as network output either 0 or 1.

def filter_nans_(z):
    mask = ~jnp.isnan(z)
    idxs = jnp.nonzero(mask, size=2, fill_value=0)[0]
    return z[idxs]

def argmax_(z):
    return jnp.asarray(jnp.argmax(z), dtype=jnp.float32)

This actually seems to be working, but sometimes I run into some peculiar issues where the genome that is saved as self.best_genome in the pipeline suddenly changes. It even looks like an entire additional generation step is performed (not sure about if that is correct), changing multiple fitnesses in the population, even though at this point the set fitness target has been reached. This results in the prints from within pipeline's analysis() function showing good maximum fitness values, and the evolution stopping because the fitness target has been reached, but then if I run pipeline.show() on the supposedly best genome returned by pipeline.auto_run(), the performance is much worse. The weird thing is that this change doesn't happen every time a new best genome is found, and it seems to only ever happen if I use my custom argmax and filter_nans functions. If I use the same random seed in this setup, it does consistently happen in exactly the same generation, with the same fitness values etc. each time.

Is this behaviour something that you've seen before?

[WLS2002]

Hello, thank you for using TensorNEAT.

Regarding your first point about population size and network scale limitations, unfortunately, TensorNEAT currently does not provide an effective solution for this. The only practical options are to either increase GPU memory or reduce the scale of the algorithm.
(Multi-GPU parallelism does not help here, because TensorNEAT’s multi-GPU support only accelerates problem evaluation, but does not allow for larger populations or network sizes.)
This is essentially a design limitation of TensorNEAT. Addressing it would likely require a significant rework of the current architecture.

As for your second question, you mentioned that the issue only occurs when using your custom aggregation functions. I believe there may be a potential issue in your implementation (or perhaps I didn’t fully understand your intention).

Specifically, in your filter_nans_ function, missing outputs (NaNs) are replaced using:

idxs = jnp.nonzero(mask, size=2, fill_value=0)[0]

This effectively duplicates z[0] whenever NaNs appear, which can lead to unintended bias in the final argmax—especially in binary classification, where the first class may be incorrectly favored.

A more robust approach would be to avoid reusing actual data values to fill missing outputs. Instead, you can replace NaNs with -jnp.inf so they are naturally ignored during the argmax step:

def new_aggregation_func(z):
    z = jnp.where(jnp.isnan(z), -jnp.inf, z)
    return jnp.argmax(z)

This ensures that invalid outputs never influence the decision logic and should make your results more stable.

Once again, thank you for using TensorNEAT. I hope this explanation helps!
If you have any further questions, feel free to reach out — I’d be happy to help.

[LuukvanKeeken]

Thanks for your reply!

Regarding my second question, I realized that for my purposes I shouldn't have been using argmax anyway, but softmax instead. Additionally I found out that it's easier to add a softmax operation on the output values at the end of the forward() function in the HyperNEAT/substrate genome, instead of as a custom node aggregation function. I haven't found out why that caused the strange behaviours that I observed, but if it otherwise doesn't occur that's not really important.