The Gbrain - Data storage

There's many ways to store information in Wiremod, chief among them being tables & arrays in expression 2. The Gbrain neurons however have a serious memory issue.

The rule of thumb is that the fewers variables a given neuron looks at, the less combinations there can be, and therefore the less information it needs to store. However, even then, with any significant complexity, the neurons start running into tables the size of Big Ben (That's the big London clocktower, by the by, not Ben the morbidly obese guy on the subway).

Therefore, we need to consider ways to store and manage the data.

One possibility is to store each sequence of relevant variables and then have a glon-encoded table for each encountered action. An action that has not been encountered begins with a modifier of zero, of course, so it is irrelevant at that point as it should be, and then amended following consequence evaluation. This does little to reduce the memory footprint, but it does mean we don't need a whole new entry each time a different action is undertaken with previously-encountered circumstance.

Another is to have a super-array, containing an ordered sequence of glon-encoded tables which are unpacked and checked for the relevant entry. This means the memory footprint is a fraction of the overall data, and the neuron can be easily coded to loop through the different tables until it finds the right entry (if any) and to make a new table once the most recent one reaches a critical entry mass, storing it in the next entry of the super-array. The downside however is that, as the number of stored tables increases, so does the time it takes the neuron to search for the entry, whether or not the neuron has actually encountered the circumstance.

This latter option is probably what I'll be using for Gbrain, probably hybridised with the former to reduce the footprint further. The amount of time it spends looking in a table that lacks the circumstance is so minimal it could almost be said to never have happened.

Management of the data predominantly refers to how you search through it to find what you need, but since I've covered that above I'll more right to cutting down repeats and such. Good coding means you'll never have the same entry twice, so cutting down instead refers here to removing entries that are no-longer relevant or needed. Management of the database is necessary because of some easy math we can do right now.

Let's say we start off wholesale with 10,000 entries, determining the different actions and circumstances associated. Next, let's assume for each circumstance we've considered each action at least once, and that there are 5 actions (Left, right, forward, back, turn etc.). Then, in our stage 2 circumstance tables, let's assume we have about 50 entries each. Therefore overall we have (10000/5)/50 entries in the super-array. That's 40 entries, not much until you consider that for all the irrelevant or otherwise meaningless entries we still have to sort through all 40 of them when looking for previous data, that means each entry is more time it takes for an action to be considered or added. Culling the herd makes the gBrain faster and less memory heavy.

This is a tricky thing, because you're essentially programming "forgetfulness" into your system, which is an odd idea at the best of times. The best way I can think of is to include a reference array of the entries and when they were last modified. Then, every so often, run through the reference array checking the oldest entries. Obviously if we flat-out erased the oldest data, we could "forget" not to stick our hands in an open flame or to take a blind leap off a cliff.

Instead, before outright deleting something, instead first consider it's modifier. A strong modifier either way (Yes/No) should mean that this is something the brain has encountered often enough to decide firmly what to do in that situation, meaning something it definitively needs to do or avoid doing. This is an entry we don't want to lose, because we would then risk future operation safety.

Therefore instead delete entries with modifiers closer to zero on both counts, these are ones we've either encountered little or that are reasonably neutral on going either way anyway. Remember: Creating a new entry is resource-free, as is not finding an entry in the database. And the smaller the database is kept, the faster the neuron can decide what to do.