Note: Deprecated!

An annoying side effect of this type of resonating network, is, when you have a bug in the code, you generally don’t get 0 answers, but a whole lot. This can sometimes be very confusing to debug. Why does a certain path give a positive result, when it shouldn’t? And more importantly (from NND’s point of view at least), how can you follow the construction of that specific result, without the clutter of all the other processors? Enter ‘split paths’.

A split path represent the route that a result took, from start to now, expressed in the neurons that the path chose during all the splits.

As example, if only 1 split was executed to get to a result, and there were 2 neurons in that split, the path of the result only has 1 node and can have 2 possible values, those that were used in the split. In the real world though, a path usually has many, many nodes.

To record a split path, you first need to put a break point at a position where you know you will get many invalid results. That’s because a split path can only be recorded when the processors are still running, not when the result has already been calculated.

In the aici demo, it’s best to put a breakpoint in the ‘Stage 1.1’ code, in the if, second part (GetClusterMeaning(CurrentTo) == flow), if you drill down a bit further, you get the ‘Add split result’ instruction, which is basically the end point of the flow recognition  algorithm. (see picture below).

Put breakpoints on ‘Add split result’ instructions to find invalid split paths.

Once you have a processor that is producing an invalid result at your breakpoint, you can store the split path. Select the processor, open the context menu (right mouse button on a processor in the debugger overview) and select ‘Store split path’.  This will produce a new entry in the tree on the ‘Debugger’ page (see 3th image). The root item will be ‘path for x’ where x is the name of the processor. The children are all the neurons that were selected for the path during a split instruction.

I usually kill everything after I have the path, the other processors will produce invalid results anyway, and you need to start a new run before it’s  possible to actually use the path anyway.

So, finally we can start using the data to debug our network. The basic idea is to  use the path for finding the processors that are following the specified path, so we can take a closer look at the code. In short, a split path provide a shortcut: instead of manually stepping through all the code and individually deciding which processors to follow, we can jump to the ones we are interested in. These will be highlighted in green and will pause when they have reached a split that is selected in the path. Off course, we first need to select the path in the debugger, and at least 1 child node, otherwise there wont be anything to see.

Processors that follow a selected split path will show up in green and pause whenever they reach a split that produces a neuron which is selected in the path.

 One last note perhaps, once you have the processor you want, you can use the ‘Kill all but this’ command to stop all the other processors. This way there is less distraction in the debugger.