Looks pretty cool he? So, what happened? Well in short, I took the neural network designer, removed everything complicated from view that remotely had anything to do with ‘neurons’ but kept all the memory functionality, added a character engine and a simple but powerful pattern matcher (implemented in neural code, pretty cool I think,… and simple stuff).

The character in this demo (actually called Tara – and still in development) is designed and named by Ady Di Pierro from Laticis Imagery.  The drawings were made with DAZ3 and assembled in something very similar to verbot’s CCS file.  In fact, all verbot characters should work in this character engine as well, cause I only added features to the file format but didn’t change any existing.    The images were manually assembled for this character cause there is no char-editor yet.  That is scheduled.

Also check out what Roger Davie (aka Freddy, Admin of the AI  dreams forum) did with the forum’s bot:

The images are also rendered with DAZ. He definitely has the visemes already worked out better than in the first demo.

So, how did all of this come to be, you might wonder. Well, I think you can thank Wendell Cowart from the chatterbox challenge for this. He originally contacted me with a request for a new ‘pattern based’ chatbot project. I took this as a nice challenge to demonstrate exactly just how flexible resonating neural networks are. Soon, Patti Roberts of Bildgesmythe also joined in. Together, they basically told me how they would like to have things, which features they were looking for and such. Thus, this little project was able to come into existence at record speed.
Patti and Wendell also helped out a lot with the initial ‘mid development’ testing, which I’m sure you understand is a pretty frustrating job to do, as things are usually not yet behaving the way they are expected to. So many thanks for cracking out those basic ‘issues’.

Anyway, for those who would like to play with it for themselves, a first public beta release will most likely be coming shortly. Just keep in mind that any first release will be a ‘technology preview’ sort of say.

• I had never made something like that, while I had plenty of experience designing languages,
• I didn’t really know what the end product would look like or how it would behave,
• and apart from some ‘UML designers’ that render classes, I had never used such a thing for editing code myself.

So then, what made me decide to use this approach instead of the more conventional and traditional way of using text?  First of, a major part of the answer lies in the previous statement . Other reasons were:

• Guided editors (can) lower the entrance level, when done properly (something I needed,… seriously).
• I new I would be needing some good debuggers (lessons learned!!). I could try and incorporate these into some existing editors, or turn out one of my own. At the time, it seemed a better idea to have full control from top to bottom, if I wanted to do this properly.
• I had a bit of experience working in WPF, which gave me some confidence that it was possible.
• Also, I came across this, rather serious attempt at structured editors (originally for C#), which raised my hopes as well.
• Did I already mention you that I was hoping this would make things a bit simpler for other people to understand?

In the end, it turns out I am glad I decided to use this approach, though not exactly for the reasons as previously stated. Except perhaps for the debugging, which really was fairly easy to implement this way. No, the thing that convinced me was the way that it changes how you program. This didn’t happen over night, I only began noticing this the last couple of months, after some 1,5 years of (trying to) program this way.
So what changed: well, over time, when I needed a ‘variable’, instead of thinking ‘variable’ I began to think ‘purple’. This is a shift from thinking in words to thinking in color. The best evidence for this, came in the form of me, continually trying to put a conditional in an assignment as if it were a global (cause I thought I had picked up a global). If you look at the picture to the right, you can probably understand why I erred: the blue colors are just to close to each other.
What’s more, over time I also began to think more and more in visual structures instead of ‘if-else’ or ‘while-do’. When I think about an ‘if’, I think:

In short, when programming, I am thinking more and more in terms of: blue square, red hexagon, white circle with line below (the conditional part),… Or in other words, it feels as if I am programming like building with Lego blocks!!!
I can’t explain exactly how or why this is, but it appears to free the mind for thinking about other stuff. At times, I find myself, just mindlessly putting blocks together to build up the picture that I had previously constructed in my head.  Very pleasing.

So, as a first try, I am very happy with the result, well enough for me to continue this path, and with some minor corrections here and there, keep the design. That is not to say there isn’t room for improvement, I have bucket-loads already of those, just not the time, so most of these will not be for the near future.  Others might be implemented sooner, depending on needs.

Basically, most of the concerns are centered round work speed (the number of movements and clicks required for an operation), maintainability and overview:

Speed

• To start with, the toolbox needs some redesign. I currently have 2 pages: one for general items, and a separate tab for all the instructions. I find myself continually switching between the 2, which is time consuming and unnecessary. The solution is simple: split them up in separate toolboxes.
• The toolbox currently only supports drag-drop operations. So to get 5 objects of the same type, you need to perform 5 drags. Better would be to have a ‘paint’ tool, like graphical apps, and many (UML) designers have.
• The code designer really could use some more keyboard support, so it can be used like a regular text editor (sort of). This seems a logical next step to do, just haven’t gotten there yet.
• I have been thinking a lot about using WPF’s new multi-touch libraries to add support for using 2 mice while coding. I don’t really make use of the left hand during the GUI coding, apart from the occasional copy/paste or editing a label. At times, I could definitely work with 2 hands at the same time. It’s a bit like using both hands for searching and placing blocks.
  I had also thought about using this new kinect toy, which appears to have been hacked already for PC usage. This would even resemble more like building with Lego (or like Tom cruise is doing in Minority report) . But then I figured: ok how would you feel after 2 weeks of keeping  your arms up in the air? Ok, I don’t know how I’d feel after 2 weeks like that, but my shoulders and neck definitely do!!!
  So that plan was canceled.

Overview

• As I’ve previously mentioned, I often simply recreate the picture that’s already in my head. The annoying thing is that the designer only shows a small part of the object (algorithm) that I’m working on, while at times I have more a need for a birds view approach. That’s why I added the zoom support, but more can be done such as:
  • make the code templates (the drawings) a bit smaller. I’m no good at designing, which shows.
  • provide a bread-crumb like ability (for drilling down and going back up again), much like the windows file explorer provides using it’s breadcrumb approach for directories.  I could use this for sub blocks.
  • See what I can do about providing support for multiple screens.
  • Buy a new big sized monitor, but given the massive resources at my disposal, that’s not an option
• Also previously stated: some of the colors can use a little tuning, the same perhaps for some shapes, to make them more distinguishable from each other.
• Currently, the drop area for the arguments is displayed as a simple, single square. The thing is: the argument requirements are known for each instruction, so it’s perfectly possible to display a custom set of boxes, with correct labels, for each instruction. This, by the way, would also free some space, since no drop area needs to be shown when all arguments are provided.
• I could also try to implement some sort of 3D-view on the network model, but I think I’ll need to extend my skill-set for that one.

Maintainability

The single major issue I have with code maintainability is concerning documentation. I added support for this by allowing to add some ‘rich-text’ string to each neuron. The idea being that you’d put all the comments concerning what’s going on, in there. Unfortunately, it doesn’t really work very well for code documentation because:

• neurons can be reused. This is different compared to regular text code: when this is compiled, each line of code will get it’s own output (or better, each compiled instruction corresponds with exactly 1 location within the text). With this neural network however, things are a bit different: it’s perfectly possible to use the same assignment in 2 (or more) different places. This is something I do extensively, by the way, to speed up coding and to keep the nr of links down.  What I noticed is this: though the code is shareable, the reason usually isn’t. I am currently solving this by stacking the different comments in the same text-blob, when needed. But better solutions are possible.
• I also find it annoying having to select an object in order to see it’s comments within the code view. It appears to be easier/better when you can quickly scan a document for all comments and read the one you need, without thinking about selection.

To solve this, I have been thinking about adding support for comments within the ‘project’ documents. These would maintain and display (as call-out balloons) all the comments for the neurons that they contain. The location of the comments would be determined by the comments themselves, so they can be floating, closest to the neuron that they are attached to. This would also allow me to display the comments, even if the actual neurons aren’t visible, but collapsed.

Final note

As a final note, for those who would like to build their own structured editor in WPF, perhaps a word of advice: stay away from ItemsControl or any of it’s descendants. The paradigm sounds grate: manage a list of items and display them any way you want through styling and templates. What’s not mentioned is that this only works for 10 objects or so. Any more, and your app slows down to a crawl or worse: crashes just as bad as the good old win32 apps would, perhaps even worse at times. Instead, go lower level: inherit from panel and roll out your own Measure/Arrange or go even further down and overwrite the rendering routines.

Don’t ask me how I figured it out, but yesterday, I decided  nothing could be wrong with those lines of code and instead, something in the neural code has to be wrong, more specifically, with the variables. So I built myself a better view on the memory content of the processors, and lo and behold, there they are: 3 innocent globals that get carried over from one algorithm to the next, causing all sorts of mayhem. In total, the fix took about 20 seconds. Which leaves me with mixed feelings: I’m soooo glad I finally found it. If only I had looked in the right place 3 months ago.

Note: Deprecated!

Perhaps a mid-dev cycle release would be appropriate this time round, since some changes were done to the core and some people might be interested in taking a peek under the hood. Here’s roughly what’s changed:

• There’s a new expression: the LockExpression, which does what you would expect: lock 1 or more neurons and/or 1 or more links for a short period of time so that other threads can’t get to them during the lock. Watch out with this one, try avoiding to use this with split or duplicate instructions since that combination can easily create deadlock situations.
• A new instruction: SplitWeighted, which is the same as the normal split, but gives each processor a weight, based on the position of the split variable that the processor received and the accumulator value. Example, if you were to split over 3 vars, which an accumulator of 1, the first processor would get a weight of 0, the next 1, an the last would get 2. This is an easy shortcut for search routines.
• I have began work on the new flow editor, but this is still a work in progress.
• Lots of bugfixes.
• Cleaned up the interface a bit.

As usual, you can get the download from here.

Put into sequence:

1. Thread 1 locks x and continues execution (no waiting)
2. Thread 2 locks y and continues execution (no waiting)
3. Thread 1 requests y and waits
4. Thread 2 requests x and waits,… oeps

The most often way to locate this situation is by examining the execution stack of the CPU. But what if you do out of sync locking: the request in function 1 and the release in function 2, without any relationship between the 2 functions. As an example, take the network-core’s lock expression, which is new. This locks the items when the statement is called, but releases them only after all the child statements were called. The interpreter obviously can’t do this in the same function call.

So how do you trace this type of bug? Well, slowly, painfully and with lots of debug code to generate application dumps. here’s the smallest dump that I generated for the core (usually it was several 100 lines longer):

Links in
ID: 7461 ReadCount: 2  WriteCount: 0, Waiting: 0
Links out
ID: 7461 ReadCount: 2  WriteCount: 0, Waiting: 0
Values
ID: 7461 ReadCount: 2  WriteCount: 0, Waiting: 0
Processors
Parents
ID: 7461 ReadCount: 0  WriteCount: 0, Waiting: 2
Children
ID: 7432 ReadCount: 0  WriteCount: 1, Waiting: 0
ID: 7461 ReadCount: 2  WriteCount: 0, Waiting: 0
ID: 7288 ReadCount: 0  WriteCount: 1, Waiting: 0
LockExpressionCounter: 2
Single lock count: 0

Basically, it allows me to check all the locks that are still active (in order of age) when the deadlock occurred. From then it’s simply a matter of figuring out who has the oldest lock and why it wasn’t released. To do this, it’s best to keep track somehow of the threads that do the locking and make certain that they are named, so you can find them again in the execution stack of the debugger.

In case you are looking for a mental image to visualize this whole concept, try this: Resonance. When a link gets activated (for instance, the one to the very first neuron), it creates a resonance that triggers one or more other neurons. This excitation in turn can cause another link between 2 neurons to be activated, causing more resonance and so and and on until the whole thing settles down.

I have absolutely no prove or idea that this is how it works in the real world, that’s just how my model can be interpreted. Truth be told, this is not how I conceived the thing (aka lets try to create a model that uses resonance), it was rather more like: I have 2 neurons, they are linked, how can I make something happen? Well, I can attach some code to the link and execute that. Cool. But, wait a moment, that looks like resonance…

and we just passed ‘culminate’, pfff

New release coming shortly.

Anyway, here are some of the most significant changes:

• Cut/copy paste system: this was still missing.  The backbone is done, the code and flow editors already have a working implementation, the rest should follow.
• Deletion system: I updated the deletion system so as to better reflect common editing practices.  This is again done for the code and flow editors, the rest will be done later.
• undo system: There were still some issues with undoing network operations.  This should be fixed.  The mind-map editor still requires some redoing in this area (and many more by the way).
• Debugger: This is starting to become really useful.  I would not have been able to get the scanner demo working without this. I’ll explain more about this one in a later post cause it definitely needs some explanation.
• Demos updated:
  • I have split the echo demo in 2: a word echo demo and letter echo demo. Both give a very basic implementation of 2 different coding techniques to use in neural networks: a singular operation, and a collector.
  • The English language  def demo is currently able to scan incoming letters and turn them into words and numbers (although there’s still a problem with the numbers).  This scanner algorithm (which really is a general purpose flow interpreter) will be explained later, cause it’s a bit funky (to say the least). You’ll also probably notice that the UI needs some serious speed tuning in order to keep up with the engine.
• Execution engine: this is where the major hacking had to be done, the axe is still glowing red hot, but it’s running, oh yea, it’s running.
• Some new instructions: More will probably follow, but I’m beginning to get a better picture of instruction requirements.  This is starting to stable out.
• lots and lots of small fixes.

The new release can be downloaded from here, or through the usual links in the menu. I’ll probably be spending some more time on posting new entries to explain the debugger and some algorithms. I might also need to start explaining how you actually do you’re own coding in NND. I’d say: stay tuned.

The problem, you see, is the fact that N2D is a Designer, running on top of a neural network, accessing it’s services.  So when you are designing the network, it is also running.  This means that all the stuff you type into the text-channels, will also be stored in the project. Something you don’t want while performing tests.

To overcome this issue, N2D can use a special directory as a sandbox in which it can copy projects that need testing. The sandbox project will be started in it’s own designer so you can play with it, with all of it’s features (including neuron streaming) without messing up the actual data.

To run the current project in a sandbox, use the ‘Sandbox‘ toolbar button or menu item Debug/Sandbox. This will save the project, copy it over to a temp directory (selectable in the ‘Tools/Options‘ window) and start a new session.

When N2D is started in Sandbox mode, it will show this in the lower right corner, like so: