Blob Brains Outputting Enormous Numbers

[jcbrockschmidt]

This issue has gone under two titles. Both are listed below, from newest to oldest.
Blob Brains Outputting Enormous Numbers:

Blob brains occasionally output huge numbers. For the most part, these neural networks seem to behave themselves. However, every once and awhile every blob's brain's neural network begin unanimously output huge numbers to all output nodes. There exponents are typically close to 220 (scientific notation) for some reason.
Majority of Blobs Move to the Right:

As of updating the fitness function for blobs, virtually all blobs in a world seem to uniformly move the right. Testing consistently showed that the removal of fitness = pow(peakSize,4.0)+timeAlive; caused this disturbance. Replacing such with the mathematically identical code *fitness = (peakSizepeakSizepeakSizepeakSize)+timeAlive; did not seem to remove this behavior, despite output confirming that the two has virtually identical output. Furthermore, replacing it with fitness = pow(peakSize,2.0)+timeAlive; produced the same undesirable uniform behavior. But, oddly enough, replacing the code with lines like fitness = pow(peakSize,2.00001)+timeAlive;** did not disrupt the simulation.

Understand that changing the fitness function is expected to bring behavioral changes. However, this effect should be over time. The start of any two simulations with different fitness functions should produce an equally random set of blobs.

[jcbrockschmidt]

I'm going to ignore the whole fitness function interference for now.

On examining the outputs of the blobs' brains, they seem to be consistently outputting doubles with exponents around 220 (e.g. 3.14159265e220). From such outputs, blobs are determining their direction of travel in radians. They do this with using double fmod (double numer, double denom); from the include . This function performs the mathematical operation *fmod = numer - tquot denom, in which tquot is numer/denom** rounded to the nearest zero. Due the decimal place of the least significant figure being sufficiently greater than the decimal place of the denominator used (2), this mathematical frequently operation returns 0.

In conclusion, the values passing through each blobs' brain/neural-net need to somehow be lowered. Normalization may be the most fool-proof option.

[jcbrockschmidt]

This predicament can be circumvented by reseting the simulation a few times until the behavior is not evidently prevalent. This is by no means a fix. But, its a decent work-around for the time being.

[jcbrockschmidt]

It seems it is always every single blob that doesn't stay in place moves to the right when such strange behavior occurs. It is possible that each blob's brain (or part of their brain) is sharing the same place in memory.

[jcbrockschmidt]

This undesirable behavior seems to appear both when creating a fresh simulation and when loading an old one. But of course, note that this behavior does not always arise (as implied in my second comment). This gives evidence to the suspicion that the error could be occurring during initialization.

EDIT: Sometimes, the move-right behavior rears its head mid-simulation. Thus is not an initialization problem (at least, not intrinsically).

[jcbrockschmidt]

This glitch arose after implementing short-term memory for blob brains. And, as stated, the strange move-right behavior appears to consistently happen unanimously. Thus, it is possible that each blob's short-term memory is occupying the same place in memory.

EDIT: Testing has shown that blobs' brains are not sharing memory. Two tests were conducted. First, each iteration, the stored short-term memory queue of 10 blobs' brains were outputted to the screen. The numbers displayed for each blob never matched up, based on empirical observation. And even if they had matched up 100% at one point in time, it would have been an isolated occurrence. The same was done with the first 4 of these blobs' brains outputs. Similar results occurred. The second test involved outputting several of the weights of a blob on creation, and immediately printing them alongside a randomly selected blob that was already present within the population before the creation of the new blob. As with test one, never did any of the numbers displayed for each blob appear to match up 100% (or even closely) with those of the other.

Thus, in conclusion, the blobs' brains do not appear to be sharing memory. This of course makes there unanimous misbehavior even more peculiar.

[jcbrockschmidt]

When blobs exhibit the move-right behavior, their outputs become extremely large numbers. It seems their brains effectively become "unbalanced", for lack of a better word. Ideally, the blob's brains should be designed in such a way that such imbalances never occur. Originally, if such imbalances occurred, they were probably only present for a tick. However, with the introduction of short-term memory, the outputs of one bad brain iteration/feed-forward are fed into subsequent iterations, thus locking a brain in an infinite loop of imbalance. This is all my best guess at the moment.

[jcbrockschmidt]

The move-right behavior should be fixed as of commit 02f93aa8df4f6ab14fb2c09206f5cb941ef5d622, which makes the calculation for a blob's desired direction of travel more large-number friendly.

However, blob brains are still becoming "unbalanced". They are still occasionally outputting enormous numbers. This needs to be fixed.

[jcbrockschmidt]

Normalizing inputs--as introduced in commit a2e8d93f410e9d4a7935b9d0645471141795ebc2--seems to have lessened the frequency of times this ANN overload/unbalancing occurs. However, it still occurs nonetheless.