Conversations are slowly starting to make some sense There’s still a nasty threading issue in the flow recognition code (some data neuron that needs to be duplicated but which isn’t yet). So on occasion you need to repeat the statement (like the ‘How many fingers do i have’ question).  Anyway, I think this is a nice example on overloading the functionality of a single word: ‘hello’ in this case. Cool he.

For instance, the abstract can be ‘a house’ while the concrete is ‘The house that I live in,… my house. Aici needs a way to distinguish the 2 and be able to find relationships between both. This is done through the use of different data structures.

Objects

Lets start with the objects, these are the simplest. They represent abstract knowledge. Every interpretation of every word is represented by an object. For instance, ‘house’ can mean the house that you live in, but could also refer to a musical style. So there is an object for each interpretations of the word. Furthermore some words can have synonyms, words that have the same meaning. For instance, ‘house’ and ‘home’ could be considered as synonyms, or house and ‘house music’. With ‘house music’ being a compound word: 2 words joined together to form a new meaning. Other examples of compound words are: car factory, fire hose, film studio,…

Another bit of information that can be useful to know about a word, is how it should be interpreted in the context of a sentence: can it be a noun, verb, adjective,…. Sometimes, a word can have multiple interpretations, while being used as the same sentence type (like house), sometimes multiple sentence types are allowed for a single meaning (colors for instance can be used as adjectives or nouns: ‘my eyes are blue’, ‘that blue is pretty’ ). As a speed optimization, we group all the objects together that have the same part of speech, but with different meanings in ‘Pos-groups’, though this is not required.

As a visual example, let’s take the objects ‘hello’ and ‘goodbye’ (as in a greeting). Both are nouns (it’s an hello and a goodbye). Both have multiple synonyms: hi, howdy, bye,..  So here’s how this would look like:

Relationships between objects: the Thesaurus

Objects are stored in a thesaurus like structure to indicate relationships between them. For instance, both ‘aici’ and ‘jan’ are names, so  this could be expressed in a thesaurus relationship like in the 2 images below:

Notice (to the left) that the ‘noun’ filter was selected in the thesaurus together with the ‘is a’ relationship. To the right, you can see how this is represented internally: Name points to an ‘is a’ cluster, which contains all the related objects. So the ‘Noun filter works by only displaying objects that point to ‘noun’ or are clustered by a ‘noun’ pos-group while the ‘is a’ relationship will filter out all but the clusters attached to the roots using this ‘is a’ neuron.

Sometimes a root object doesn’t have any children (as in cluster-children, not in the thesaurus). This makes the object a dummy, a placeholder that shouldn’t be used for input or output directly, but only for filtering. Some examples of these dummies can be seen when the ‘pronouns’ are selected.

The thesaurus relationships can be used in frames to filter the input in a general way and to perform lookups by the actions. For instance, the ‘be name’ frame (in the ‘names’ editor) has an ‘object flow’ element that filters on ‘name’ through the ‘is a’ relationship, as seen in the image below.

This means that the frame is only selected when the input contains the result of an object flow that is the child of an ‘is a’ cluster, attached to ‘name’ or one of it’s thesaurus children (so multiple levels are allowed).

To create this type of filter by the way, you simply drag ‘name’ from the thesaurus to the filter area.

Actions also make use of these thesaurus relationships in a very similar way. For instance, an action could check if an object  is allowed to/can be the name of something (‘my name is Jan’). Or, in sentences like: ‘this is blue’, the thesaurus is used to find out what ‘blue’ actually is: a color (I’m jumping here, keep with me, It will become clear very soon).

An object can also be the child of multiple items in a thesaurus. For instance, ‘blue’ is both the child of ‘colorful’ and ‘sad’ (child of ‘emotional’). Note that these are all adjectives, hence we say ‘colorful’ instead of ‘color’. To find out which relationship to take, we can make use of a log of previously made statements or a list of focused objects. The most important usage of either color(ful) or emotion(al) in this log, triggers it for the new input. Most important can be interpreted very broadly: it could be ‘newest log item’, or ‘most talked about’,… If it is impossible to solve this, a question needs to be asked.

Anyway, once you have figured out which path to take in the thesaurus: colorful, we still have an adjective. If the same logical concept/idea can be expressed in multiple parts of speech, using different words (like color-colorful) and you want to be able to jump between the 2, you need to have a relationship between them. As I already stated, we interpret ‘blue’ as a ‘color’, not ‘colorful’. Why, will become more clear when we talk about the assets, for now lets just take it that we need to change from adjective or verb to noun. As you can see in the image, the thesaurus has a special section to define this type of relationship: the left part of the table contains the link meaning, the right section is the ‘from’ part of the link.

The same can be done for verb conjugations. In English, a verb usually has 3 different conjugational forms, other languages have others, so the thesaurus allows you to define this type of relationship free form, much like the part of speech relationships. When you create a new verb though, the designer will try to fill in all the conjugations (if it finds neurons titled ‘present particle’, ‘past particle’ and ‘third person present’. It’s always best to check them before storing the default though, since it doesn’t know about irregular verbs and sometimes it/I may simply goof up.

The verb conjugations, compared to the part-of-speech relationships, are used a bit differently. These serve their purpose while parsing the input and generating output. Some flow elements try to search for conjugation relationships while filtering (in the ‘FilterCode’ tab) in order to get the correct parse. For instance, in the ‘model verbs flow’, this is used to make certain that a verb is the present particle. The same goes for generating output: when a verb is used in certain situations (ex: ‘what’ contains a verb instead of a noun), we need to generate it’s present particle form (or another, depending on the exact situation).

Assets

Up until now, all relationships were between objects, so between abstract knowledge only. To record a network’s experiences (the data that it records), we use assets and asset relationships.

At it’s core, an asset is a cluster with meaning ‘asset’ (we’re very original here), which contains a number of child neurons that represent property-value pairs for that asset. This is done through links to objects and/or other assets, using the meanings: attribute, value, amount,… From this basic structure, we can start to play and create meaningful relationships.

As usual, a picture says a thousand words, so to the left, I’ve displayed a debug view of the ‘text channel’ neuron (the text input channel of AICI). Why this neuron? If you look closely, it has a link that points to an ‘asset’ cluster, using the meaning ‘Pr:You’. So with this image, I’ve got 2 birds with 1 stone: the asset and how to find the asset that AICI is using for the person on the other side of the channel .

A text channel stores a reference to the asset that represents the entity it is communicating with using a link with meaning ‘Pr:you.

As a side note, linking ‘you’ to the text channel, allows the system to talk to multiple users at the same time: each on their own channel.

So what’s stored in this asset anyway? As you can see, there are 2 child neurons in the asset, so 2 data items: the first has an attribute (property) of ‘entity’ and a (property) value of ‘animate entity’. The second asset-child  points to ‘eye’ for the attribute, the value is another asset and it has a general amount of ‘plural’.

Note that the attribute should always be a noun. Having a fixed transformation point facilitates the search.  Why a noun: well, all adjectives and action-verbs can be converted to a noun, but not the other way round. This conversion can be done using the part of speech relationships that were previously described.

The ‘entity’ property is how AICI tries to classify assets: is it an object, animate, animal, human,… If you look at the thesaurus (in the designer), ‘entity’ is a noun-root and the asset-child’s value is one of it’s children. This is a rule: when the value is an object, it must have a thesaurus relationship with the attribute. This type of child asset represents the ‘x is an y’ type of relationship. Here, it is ‘I am an animate entity’, an other example could be:  ‘I am a human’, which would/should map to the same asset-child.

- An asset-child with an object as value represents an ‘x is an y’ sentence structure.
- In this case, the value must have a thesaurus relationship with the attribute. This relationship can span multiple levels.

AICI at the moment,  presumes that an ‘entity’ that is able to communicate through a text channel, must be animate (mammal, AI,…). So, even if this information is not yet provided, it is presumed to be the case. This is done cause the property and value play a role in other parts of the network.

The second asset-child has another asset as value. This type of relationships represents the ‘x has an y’ sentence structure. More specifically, in this example we said: ‘I have blue eyes’. This also explains the undefined ‘plural’ amount: eyes is plural and was converted into a single value, but since we don’t know exactly how many, we keep a ref to the multiple. The sub asset also has it’s own child-asset, which defines the ‘color-blue’ part of the example sentence. Through this nesting, it is possible to describe complex entities that consist out of multiple parts of knowledge.

An asset-child that references another asset as value, represents an ‘x has an y’ sentence structure.

Objects referencing assets

Assets aren’t exactly islands, independent of everything else. No, they too are referenced in many different ways. We already saw 2: assets attached to child-assets, and to the text-channels.  There’s one more reference worth mentioning at this moment: objects that reference assets. Yes, assets don’t just reference objects, it can also go the other way round. This is used to represent general knowledge about general things, like: ‘a human has hands’, as depicted in the image to the right. The same thing is also valid for statements like ‘an x is a y’: they are represented as assets, linked from objects.

Note: I did a bit of recycling with regards to the meaning of the link from the object: it also uses ‘asset’, which is the same as the meaning for the cluster.

An object that references an asset cluster, using ‘asset’ as meaning for the link, is used to represent statements of the form: ‘an x is/has a y’

The important difference between stand alone assets and assets that are linked to objects, are the information that they represent about the agent of a sentence: stand alone assets represent concrete agents: I, you, the book,… while object referenced assets represent abstract agents: a book, a human,…

These 2 data structures: objects and assets, are simple, but, I believe, flexible enough to represent a whole world of information. It is not as much the the querying and reshaping of the data as it will, in the end, be the automatic creation of these structures which I believe will ultimately be the truly interesting thing. With a query, we can retrieve data, reshaping it allows us to find truths, fallacies and falsities in the data, but a correct automatic creation of a new, complex asset, is in fact, a new entity.

In the end, all is just structure.

So it’s now possible to call static functions that take value types as argument and/or as return type.  In this example, I am calling the standard System.IO.File.Copy function to copy a file on my disk. Exceptions are also supported, as you can see from the first line, when I am trying to copy a non existing file. The output comes from the exception generated by the copy. Note that you can specify the arguments in different ways. In this example, I am using the ‘to’ word. ‘From’ would also be recognized. Both determine the extraction order of the arguments.

At the moment, I have hardcoded this extraction of the function arguments for the ‘copy-verb’ manually. The idea is to change it to something more general that can work for any .net function using some meta data of the function (like which neuron to send to which output, how to recognize the arguments, how many arguments,…). I’m not there yet though. First some finishing touches to the designer, so I can trace some neuron/memory leaks. After that I’ll probably do a new release, so you can play a bit.

Oh, and it’s still way to hot outside

I feel you and you feel me

The difficulty here is 2 folded: the you and the and. Is you a personal object or subject pronoun and what does the and combine. Basically, do we mean ‘I feel you’ and ‘you feel me’ or ‘I feel’ and ‘you and you feel me’.

Here’s what aici currently makes of it:

Oh, and it’s melting hot at the moment

• 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.

There’s a lot more going on here besides the context sensitive interpretation of ‘blue’ (near the end). But I think that’s the most impressive.

My handle is Bragi, from to be the Nordic god of the bards and poets. 

As Snorri Sturluson writes in the Gylfaginning after describing Odin, Thor, and Baldr: One is called Bragi: he is renowned for wisdom, and most of all for fluency of speech and skill with words.

(source wikipedia)

I thought the skill with words somehow seemed appropriate

Notice how, in this example, I never declared a direct relationship between me and fingers, it’s all indirect. The renderer still has a little problem handling plurals, but that will be fixed soon.

Here’s a more compact version, which is stored differently (internally), but renders the same result. Hands and fingers are just less understood.

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.

Mmm… Close, but no cigar, and definitely not what I expected.  It’s 10,  you dummy.

Ps: that was the first run of the count algorithm, by the way.

As previously mentioned, there are a number of stages that we need to get through to go from input to output. The first is the scan phase, which translates the letters into words, numbers and signs. When this is done, we try to find sentence constructs, like the subject, verb,…. This is matched to a frame, which determines the action that needs to be triggered. Finally, the action might also activate an attribute, but this is out of this post’s scope. So let’s make our network respond to ‘what’.

Recap: 
First check if the flows can parse the statement: both scanner and grammar. Next comes the frame and finally the action and attribute.

Scanner

  This stage will transform the letters into a single word ‘what’, when it reaches the ‘Sentence’ flow. The result of this stage is a cluster, with the meaning ‘Sentence’ (the same as the name of the flow that produced the result). The child will be a textneuron, representing ‘what’

‘What’ is a simple word, which is already handled by the scanner, so no worries there. If you are wondering how words are parsed, take a look at the preceding image, which is the flow for a word. Underlined words are references to other flows,  words that aren’t underlined represent static values. Curley brackets mean a repetition, strait ones define an option. If a conditional has a vertical line after it’s first bracket, a selection is required, this is valid for both repetitions and loops. This basic syntax was inspired by parser generator languages like Coco/R, Lex and Yacc.

So in the above example, a word can start with number (a sub flow), letters or capital letters. A word must always have at least 1 letter or capital, may have middle numbers and can end with a number or an alpha numeric.

Note: at the time of writing, there is still a little optimization required to get words with many mixed digits and letters working properly.

Grammar

Moving on to the grammar section. This is also defined in a flow editor, called ‘English grammar’. So open this (in the ‘Flows’ folder) and immediately select the ‘Interrogative pronouns’ (if you are, like me, not that very fluent in English grammar, and could use a mental aid now and then, there are plenty of resources on the net, check out Google dictionary, the English club, Wikipedia,…). As you can see, our ‘what’ is already in the ‘Interrogative pronouns’ flow.  So perhaps no extra work for the grammar stage as well? As it turns out, this will be the case. For those who want some more details though, here goes:

If we  look more closely to the flow name itself (on the first picture), we can see there is an overlay ‘FL’, which is short for flow-code. If you hover over the ‘FL’, you get a tooltip with more info. This says ‘References code that is executed when the item is recognized in a data flow’. This means that the flow does something when it is recognized in an input stream. Usually, it formats the recognized data in such a way that the next stage knows what type of sentence part it was. If there is no ‘FL’ overlay, it means that the data will be recognized in the input stream, but no extra actions are taken, when found. So the input is simply copied over to the result which leaves it unrecognizable. The ‘Reflective pronouns’ are a good example of a flow without overlays.

But what to do in such a case? Before you start to code, first see who uses the flow anyway, maybe they do something with it.

Tip:
Use F8 to browse all relationships of a neuron.

If you select the ‘Reflective pronouns’ Flow (click 2 times, the first time we automatically focus on the editor) and press F8, you can see which clusters it belongs to (and some other stuff too, not important for now). In this case it’s only 1 cluster: a conditional part (we need flows), so if we drill down a bit further, until we eventually get to the ‘Object flow’. This is used to find the object of a sentence. These flows do have an overlay (in the editor), and tag the recognized data. Usually, this is enough. Only when you need to tag this sub result as well, do you need to add some code, which is generally not the case.

Anyway, to get back to our ‘Interrogative pronouns’, lets see what the attached code does, and open the code editor (right-mouse button on the flow, and select ‘View code’). Most often, as with this flow, it simply duplicates the content of the ‘Result’ variable (which always references a cluster at this stage), and removes all outgoing links on this duplicate (sometimes, result clusters can link to some extra data which we don’t want,  but is used by the algorithm) and stores this duplicate back into the result cluster.

To better explain what this actually means, lets take the following input stream: ‘you are here’. After the scan stage, we have a result that looks like image 5: a cluster with meaning ‘sentence’ and 3 text neurons as children. Once the grammar stage is done transforming this dataset, it looks more like image 6: a cluster with meaning ‘statement’  and 3 children again, but with some more info. The first 2 represent the agent (sentence subject) and the verb, both flows use the previously described transformation code. The last child is the object representation of the textneuron ‘here’. It is the result of an adverb that was recognized somewhere in a flow, which didn’t transform the data, so content simply got copied to the final result.

AICI: 
When a flow has been recognized, the ‘flow-code’ callback of the flow is executed. The ‘Result’ variable will contain a cluster with the flow as it’s meaning and the recognized data as it’s children.

AICI:
Use the ‘TransformFlowResultCallback’ cluster as a default callback for flows so the result can be recognized by the frames.

Frames

Up until now, not much had to be done, with the frames though, this will change, here we actually need to do something to get it working. Frames can be seen as the conduit between the front (scanner/grammar) and back (actions/attributes). A frame defines which sentence parts it can contain and their order. Multiple orders can be defined, so that you can have the same sentence parts to form a statement or a question. You can also have optional parts, to make frames even more flexible. Each order is defined in a frame sequence. This is also able to render itself back as output, completing the circle.

Just like for the scanner and grammar, the network is already capable to extract the correct frame sequence, based on the set of already defined frames and their sequences (so if it’s not yet defined, the network can’t recognize it). Once, the sequence is found, the framework performs some calls to attached code that you have to provide so that the network also knows what to do with the input statement. The following code blocks can/should be attached to a frame sequence:

• ExtractAction: this code block is called to determine which action(s) the frame should trigger. Multiple actions are allowed, in which case each will be triggered in the order as they were returned. This is done through the variable ‘ExtractedActions’.  The attachment is required. 
• ConvToKnowledge: this code block should transform the result data of the grammar parse, into the input data for the actions and return this cluster through the variable ‘KnowledgeConv’. (edit 11/July/2010) The attachment is required. This attachment is optional. If you define a value for the new column ‘ResultType’ in the frame editor and the ‘role’ neuron has a ‘ConvToKnowledge’ code cluster, the network can automatically generate the result cluster for an entire frame sequence, and so this code is no longer required. You can override the auto rendering by defining this code cluster.
• RenderCode: This code block is called by an action to render output according to the structure of the frame. The output to render is found in the ‘CurrentFrom’ system variable. The format of the data is the same as that of ‘ConvToKnowledge’. The attachment should only be defined if there is an action able to call it is output. This is not always the case, for instance, frames that deal with ‘unknown’ word types, don’t need to be generated.

Recap:
A frame determines the action to execute, provides the data for the action and is able to render data provided by an action.

As previously mentioned, a frame needs to prepare the data for the action. This should be a cluster without meaning (it will automatically be assigned, once the correct frame sequence is found, and will eventually indicate that the cluster is an input statement). The content of this cluster needs to be well defined, so that the action can handle it correctly. In theory, you can use any type of structure that you want, as long as the action uses the same. In practice, it’s best to use a predetermined structure, shared by all the actions and frames, for easy sharing of default actions. So here’s a small overview of the possible content:

• The first child neuron should indicate the time value: current, passed or future. Though most actions don’t specifically expect it on the first pos, all current frames use this.
• The child list can also contain a ‘not’ neuron, to indicate that the statement should be interpreted as a negation.
• The sentence agent should be stored in a cluster with meaning ‘who’
• You can store the sentence object in a cluster with meaning ‘what’ or ‘value’, depending on the situation. Sometimes, ‘what’ can be extracted, from ‘who’, a previous statement or the ‘value’.
• a cluster with meaning ‘verb’ can be used for sentences that a verb. Originally, this wasn’t done for the basic verbs like ‘to be, ‘to have’, since it can be inferred from the action that is triggered. However, it can always be useful to take the actual verb that was used to the action, in case it needs to do some analysis on the ‘subject’ indicator of the word. For instance, ‘am’ is usually for ‘I’.

Frames can play a little bit with these structures: fill in missing data, switch who, what and value,… Though most of the code in the current frame sequences is shared: if there is an agent in the sentence, 9 out of 10 times it is transformed in the same way, so lots of copy paste (or drag drop) possibilities here. Also perhaps for future automatic learning.
(Update 11/July/2010) In the new version, it is no longer required to provide this code for each frame. It is moved to the level of the ‘role’ (as defined in the frame element), usually these are the flows like ‘agent’ or ‘be verb’,…

The translation results for the input ‘i am jan’. In the final stage, ‘what’ is filled in by the frame.

For our example, we will have to create a new frame to handle the input ‘what’. Since this is a sentence that only contains an interrogative pronoun, we should probably best put it in the ‘Pronouns’ frame editor together with all the other pronouns (for easy lookup later on). So open up this editor (double click on the editor’s name in the project view), or create a new one if it doesn’t yet exist (the button that looks like a rectangle, you know ‘frame’).

To create a new frame, click on the button with the square, on the editor (tooltip: Create a new frame) or press Ctrl+Shift+F and provide a name for the new frame. Lets call it ‘what frame’. To quickly build the frame, you can drag neurons from the toolbox, thesaurus, flow,… and drop them on the frame editor. To start with, find an ‘Interrogative pronoun (to get it in the explorer, press ‘F4’),  and drop it somewhere in the top part to create a new frame element. This indicates that the sentence should contain an ‘interrogative pronoun’ sentence part.

Tip:
To quickly sync the explorer with the currently selected item, press F4 from anywhere in the application.

Make this element an evoker. Only evoker elements are used to find all possible frame candidates. This is a small optimization for the search algorithm. Each frame should have 1 evoker element. Usually, this is the verb, but in this case there isn’t one so we use what’s available.

At this point, we have a frame that will be activated for all sentences that contain an interrogative pronoun, like: what, who, where, when,… We need to further specify that we only want to respond to ‘what’. This is done by adding a filter to the frame element. So make certain that the element is selected, and from the thesaurus, drag ‘what’ to the bottom part of the frame editor and drop it there. this will automatically create a thesaurus filter for the currently selected relationship. So if ‘what’ had one or more children in the thesaurus, these would also be valid for the filter. In this case we don’t have that, so the relationship field could have been left empty.

Also notice the ‘RestrictionMofidierInclude’ in front of the filter. This is to indicate that input values that contain the filter value are allowed. If this was set to ‘RestrictionModifierExclude’, only sentences that wouldn’t contain ‘what’ would be allowed (so, where, who, when,..).

Finally, there is also the small button. When this is checked, the content of the sentence part should only contain what is defined in the filter, and no other words. If not checked, other words may still be present. This is an important little property which I almost got wrong starting out this post. Do we want to handle sentences like ‘what color’, ‘what time’, what the hell’,  ‘what in the name of sweet Jesus’, or only ‘what’. If you go back to the very first image, you can see that it’s allowed to put some words after the pronoun. This is to allow correct recognition of sentences like ‘what size are you’ where ‘you’  is the subject. This means that the grammar will also recognize ‘what color’ as an interrogative pronoun. It turns out this is actually ok for us (see frame sequence code). So we leave this not checked to allow other words in the flow result.

The Frame sequence

Now that the frame has been defined, lets move on to the sequence. To create this, press the ‘Add frame sequence button’, or ‘Shift+Ctrl+S’ and provide a name for the sequence (make certain that the frame editor is active when pressing the button, otherwise it won’t be active). Lets call it ‘What statement’. You create the sequence by moving the frame elements from the left part to the right part of the editor. You can use the arrow buttons for this. Multiple elements can be moved at the same time. The up and down can be used to change the order.

All pretty strait forward. The cool part comes in the code editor. To open this, select the frame sequence in the editor (or somewhere else, like in the explorer), open the context menu and select ‘view code’. First, lets make certain that this new code editor is also available from the project. All you have to do is open the context menu on the bottom tab items of the code editor, and press the ‘Show in project’ menu item. This will add the neuron to the currently selected project folder (or root if there is non selected). So, when you do this, it’s best that the correct folder is selected first. If you forgot to select the one you wanted, you can always still move it later on.

Tip:
To add a code editor to the project view, right click on the bottom tab items and select ‘Show in project’. The item will be added to the currently selected project folder.

By default, there are only a limited number of pages available in the code editor. The rules and actions pages are always available (though the code clusters are only created when you actually drop something on them). But not the ones that we need. Those will have to be added manually. So open the context menu, again on the bottom tab items, and select the required pages listed under ‘add new code page’. We need ‘ExractAction’, ‘ConvToKnowledge’ and ‘RenderCode’.

Tip:
You can add any type of code page to a code editor, make certain that the required neuron is tagged as ‘a default meaning neuron’ in the explorer. Open the context menu on the bottom tab items of the code editor and select the new page from the ‘Add new page’ menu item.

Frame sequence code

RenderCode: The render code for the ‘what’ statement as displayed in the above picture is very simple, but not completely correct (see below), we basically write “what?”. I added the question mark, just to show a little trick of the text sins: When you send them multiple neurons, by default, each one will be rendered on it’s own line. To group neurons together, use the ‘BeginTextBlock’ and ‘EndTextBlock’ neurons.  These are recognized by the text sin as special formatting tokens.

We use the ‘output’ statement to send data to a sensory interface. The fastest way to declare this expression, is by dragging it from the toolbox. This has 2 pages: one for common expressions like clusters, assignments and commonly used neurons, and a second page, exclusively for all the instructions.

Tip:
You can quickly expand or collapse all toolbox items from their context menu. All instructions display a tooltip with a short description, the expected parameters and output.

The first argument to all the output statements is always the same: ‘OutputSin’. This is a global that is filled in by the framework and points to the sensory interface to which the output should be sent. You can also hardcode which sensory interface it needs to be sent to, but that is less flexible. This way, you can actually have multiple text-sins in 1 network and have multiple users chat at the same time. As a small side note: because the output statement can take any number of arguments, we could have written it shorter: in 1 statement. This wasn’t done because I forgot, before taking the screenshot

Also, if you look closely, some of the statements appear to have a double border, while others don’t. This is to indicate that it is used multiple times. This is important to keep in mind, if you modify these statements, you are also changing them in some other part of the code. When dragging code around, it is not like text that you duplicate. When you drag and drop, there is no deep copy, only a new reference made. This can keep the code size pretty compact, allows for some deep future analysis and most importantly should allow for easy auto generation later on. But it is something to keep in mind while changing code.

Caution:
Statements with a double border are used multiple times, be careful while modifying these.

The complete render code looks something more like the following image. This is able to handle not only ‘what’, but also ‘what color’, ‘what on earth’,… Looks scary? Don’t worry, it’s actually very simple, and most of the code is copied over from other parts anyway.

The second statement, the big yellow monster, is actually a query, who’s result is stored in the ‘what’ variable. ‘Get children filtered’ returns all the child neurons of a cluster that meet a specified filter. In this case, we only want neuron clusters that have a cluster-meaning equal to ‘sg:What’, in other words, we want to retrieve the ‘what’ part from the input. (no surprise there).
The next statement is an ‘if’ construct: if we found something (count(what) > 0), render the contents of the ‘what’ variable, using the ‘Render object’ code block. If there is no cluster found, simply render ‘what?’. The ‘what’ variable isn’t passed over to the ‘Render object’. This is not possible and not required: a code block doesn’t have it’s own variable space, so all the variables maintain their value, hence, the ‘what’ variable is passed along implicitly.

And thus, you have mastered your third little peace of code already

 ConvToKnowledge: (update 11/July/2010: this code cluster is no longer required, but is still allowed) The transformation for ‘what’ is also fairly strait forward. This  type of attached code tends to have a fairly similar structure across frame sequences. In this one, we check if the interrogative pronoun contained anything other than ‘what’. We do this by checking if it has more than 1 child. When this is the case, we create a new cluster, assign it the meaning ‘sg:what’ (this is a tag operation) and we copy all the children, except the first, from the cluster that we found to the newly created one. Finally, we add this new cluster to our result. We don’t copy the first child, since that is the the ‘what’. We presume this, if you know any situation in which it is not the case, the code needs to be updated to something more secure (remove the actual ‘what’ neuron).

ExtractAction: Lastly, we also need to provide some code that returns the action we want to execute. Before we can do this, we actually need to know which are the possible actions that can be performed.

So lets try and come up with a few possible dialogs, so we can analyze the different possibilities. Here’s what I came up with on short notice:

PC: I have hair
You: what
PC: I have hair –> this is a simple repetition of what was last said.

PC: I am in the black room
You: what color
PC: black-> return the first value that was found through an ‘is a’ relationship (black is a color), from any of the words of the prev statement.
You what room
PC: the room of your house –> return more relationship info on the actual result of ‘the black room’, if there is any. In this case, we know the owner of the house.

You: what the fuck
PC: No swearing please –> catch a special case.

So Basically, I have 3 different groups of the conversations (if you can think of more, le me know). In the first case, when the user simply asks ‘what’, we return the last output statement. The 3th conversation, when the user wants to express surprise/disagreement through an insult, we return a standard message to keep it clean. Finally, in the middle example, some analysis is done on the previous statements, to find a proper match. We can check the actual words, see if there is an ‘is a’ relationship to be found. In this  case, the user might have forgotten the actual value, but still remembered the attribute. The user could also be requesting more info about something, in which case we need to return some more links if there are any.

Exactly how you pour this information into actions, is a bit up to you. Me, I would go for 3 different actions. In fact, I would handle the last conversation type (aka: ‘what the xxx’) as a special case in a different frame, so we can filter on these specific word groups. I guess that would be a good exercise for you. The first and second should be handled by this frame, so these are 2 new actions that should be returned by our frame sequence. To determine the exact action that needs to be returned, we can use a similar ‘if’ construct as in the ‘ConvToKnowledge’ code cluster: when there is more than a ‘what’ in the input data, use ‘Find Prev out statement’, which does the heavy searching. If there is only ‘what’ in the input data, use the light weight ‘Return last out statement’. To return the action we want to execute, simply assign it to the ‘ExtractActions’ variable, like in the statements to the right.

Recap:
Return your actions in the ‘ExtractedActions’ variable.

Actions

Rejoice, the end of this post is almost in sight: Actions, the final step. As already mentioned, we are going to need 2 actions, though to keep the post a bit within the limits of sanity, I am going to restrict the explanations to the simplest action. The more complex search algorithm needs another one of these posts to explain it all. In fact, I still have to finish it myself. Perhaps, I’ll leave it like it is, as an exercise for you

Before we start to create our action though, perhaps a small word about actions in general. These are actually nothing more then regular neurons with 2 different types of code clusters attached. The first type contains code that is called when the action is executed. You can specify a different code cluster for all the different states that the action needs specific responses for. The default state is ‘Normal state’, which is currently the only one defined, but you can create and set as many of your own states as you want. The current state of the network is defined as a link between the text sin using the meaning ‘state’ to the current value (see image). This means that you can have as many concurrent network states as communication channels. Also, when an action doesn’t have an implementation for the current state, or when the text-sin doesn’t define a state, the fallback ‘Normal state’ is used.

The second type of code clusters that are attached to actions, are used during the conversation, to check for and handle possible responses to questions. That is, some actions require some sort of response. These types of actions need to check if a response is valid, determine if an action is a valid response action and can also specify extra ‘response’ code. This though is again far outside the scope of this post, so lets leave  it at that.

Back to our example, we still need to create the action. Since this is just a neuron, there are many different ways of doing this. If you are already in the correct project folder, a quick way is to use the toolbar button above the project overview, called ‘Create a new neuron with attached code’. This will create a neuron, open it’s code editor and add it to the project. If you press F2, you can change the name (make certain the project node has keyboard focus). To add the ‘Normal state’ code page, just do the same as with the frame sequences: open the context menu on the bottom tab items, select ‘add new code page’ and click on ‘Normal state’.

And that’s how the action should eventually look like. It’s a nice bit of code to end with, with just a little bit more meat to look at. Though in the end, it’s still very strait forward. Before we delve into the specifics of the code, perhaps first a small word about the conversation log, since that’s our primary data source in this action.

The conversation log is a cluster, attached to the text sin for which it is keeping track of the previous statements made by the network and the user of the text sin. This means that the network has a log cluster for each active user. It keeps track of a 1 to 1 conversation. A Part of the content of the log consists out of the clusters that we created in the frame sequence, in the ‘ConvToKnowledge’ code. These have a cluster-meaning of ‘in’. The other part consists out of the clusters that were generated in the actions, as output.  These are labeled ‘out’. Both ‘in’ and ‘out’ children still have a link to the action(s) that was/were executed so we know what they triggered.

When we translate this information to our action, we get something like the previous picture. Basically, we try to retrieve the log from the ‘OutputSin’ global. We have already encountered this global.  It is the one that is always pointing to the Text-sin for whom we are currently processing, remember. If this doesn’t have a log, something is wrong, so we show a message to the user, log it as an error (this is useful for the debugger) and exit the link. We exit the link and not the neuron or the entire processor, since there might still be other actions that need to be executed.
If there is a log file, we walk through each log entry, from back to front, using a counter and the ‘GetChildAt’ instructions. You can do this in different ways (using the reverse instruction combined with 1 or more selects, for instance). I choose this way, since I think it’s the fastest solution for this situation.
If we find an item, with a cluster meaning of ‘out’, we simply push it back on the stack and exit the loop. By putting the cluster back on the stack, we actually let the network execute the action again, since it is still linked to the data. Note that we decrease the counter each time that we don’t have an item with meaning ‘out’. The ‘-‘ instruction might be written a bit strange at first. You can probably best think of it as a polish notation. This is actually a result of the fact that ‘-‘ is just an instruction and at present, all instructions have the same UI input format. And that’s it.

Ok, slowly breed in, and out. You’ve just reached the top of the Himalayas (or something comparable). It’s done, you’ve absorbed all the info, and your still alive. Time now to let it all breed a little, let it digest, and sleep on it a bit. Don’t worry about it, it will come to you too.

Get the latest installation from the download section.

It’s basically a general purpose network host that only supports the text sensory interfaces for input/output. You specify the network that needs to be run at the command prompt. The installation program will do a default setup to work with the AICI demo, but you can change the shortcut to use your own if you want.

What’s new

Designer and core

• The storage system has been updated to a binary, flat file structure, which improves the operation speed considerably in all areas. This essentially makes the core a true database system, which should be fairly easily scaled (see thesaurus demo project), even over multiple hardware systems (eventually).
• I  have finally implemented the namespaces. These are currently maintained in the background, so you don’t need to worry about them. The only change you’ll notice, is an improved browser popup in the frame and flow editors (see image). Basically, the thesaurus, timers and all the project editors (with their entry points) are included and automatically updated.
• The frame editor has been updated a bit cause the previous datagrid didn’t handle the custom namespace selection object. So back to listview for the frame elements (will be updated when the datagrid is fixed).
• I have also added a new restriction type for frame elements: a custom filter, which allows you to do determine the filter result through code.
• Support for modules has also been included, though not yet properly tested, so the imports will definitely not yet work.
• The speed increase brought some more threading issues to light, I hope they are now solved, but one or two things can still pop up here or there.
• Somehow, I managed to show the thesaurus in reversed order (so the view for the hypernyms was showing that of the hyponyms). While fixing that, I also tried to get it to work with an arbitrary number of elements (so you can also browse a huge thesaurus, the search hasn’t yet been updated though).
• The thesaurus can now also be built automatically, based on the content of the database.
• I have added a dialog to remove clusters that have no children, based on the ‘remove orphans’ dialog. This will probably grow out to a general purpose query window, but that’s for the next version.
• New instructions (some were long overdue):
  • Substract: remove 1 or more neurons from a set, contained by a variable or global
  • Select: perform a filter on the content of a variable or global.
  • Remove Links In: removes all the incoming links of a neuron that have a specified meaning.
  • Remove links out: same as ‘Remove Links In’, but for the outgoing links. These 2 instructions allow you to do without an extra loop, which makes it all more thread save and faster.
  • GetAt: retrieves the neuron at a specified index in the content of a variable/global.
• I have changed the parameters of the split instruction a little bit: I have removed the ‘result cluster’ which was originally used to retrieve the results of a split. This worked ok, but could cause problems when multiple users would be performing the exact same algorithm. The solution was to simply use the already existing ‘GetSplitResults’ function, which now also works after the split (and not just when the split is still running). This means that you manually need to clear the split result cache once you are done with it, otherwise the next split will give some bogus results.
• I have also removed the possibility to assign a weight value to a single neuron. Instead you now assign it to the entire processor. This will assign it’s weight to all of it’s result values when it is done. This way, you can change the weight before you know the actual result.
• Attached neurons are working.
• some cosmetical touch-ups here and there.
• Lots of other bug fixes.

AICI

The aici network demo is slowly starting to function. That is, it is beginning to record data into understandable structures. Though it’s still very early, so lots of stuff still goes wrong or hasn’t yet been implemented. Some fun responses guaranteed. Here are the major changes:

• I’ve managed to simplify the flow recognition algorithm (while fixing some tough bugs), so no more synchronization points for the loops. The designer still allows to change this prop at the moment, but this will be removed soon.  Don’t worry about existing values, they are simply skipped, no longer used.
• Some bugs in the frame recognition section have also been solved.
• I have implemented a first version of the noun path resolver algorithm. This is used to understand statements like ‘my brother’s sister’, ‘I’, ‘my favorite car’, ‘sister in law’. This algorithm is also responsible for generating new ‘compound words’, like ‘brother in law’.
• Compound words are recognized again, at different stages. Some compounds can’t be recognized yet (if they have verbs).
• New frames:
  • Be-unknown noun: sentences with an agent, be verb and a possible noun. Example sentences: I am Jan. It is a cat. My name is Jan. I was Jan. It will be a cat. (preconditions: Jan and cat are not yet  in the network). The frame is triggered when it receives a sentence that might contain a noun, and there is an open question that can consume this value.
  • some more, to much to write all down.
• If AICI knows several different synonyms for the same word, it will now mimic your preferred one. So if you just said ‘bye’, it will also say ‘bye’ next time. If you say ‘goodbye’ next, it will switch to this.
• I have introduced the concept of ‘attributes’. These provide an extra step in the semantics stage. For instance, ‘color’ is an attribute. It’s possible values are: blue, red, black, white, green,… Color is a special attribute, since it changes meaning when applied to different types of subjects. For instance, the sentence: ‘I am blue’ usually means: ‘I am a bit down’. So that’s the semantic part: an attribute can inspect to who it is applied and, when needed, can change the attribute, the owner or the value. 

The latest release can be downloaded from here, or from the main menu.

Coming up

Next in line will be the editor views (finally). These are currently built using standard WPF controls (listboxes, treeviews,…), which are, well, not performing as desired: they generally can’t handle more than 2-300 items (if you can’t use virtualization) and, more importantly, have a hardcoded recursion limit that causes serious problems, primarily in the code editor. So I need some custom controls to get the speed and reliability up.

Before this though, I will be spending a little more time with AICI. The algorithms are beginning to work the way I want them to, so it’s time to complete the flows, in order to get a larger part of the English language parsed. And off course, I will be adding a bunch of new frames, actions and attributes.

The latest conversation:

You: i am jan
You: what is my name
PC: your name is jan.
You: i have hair
You: it is brown
PC: what do brown mean?
You: that is a color
You: what color is my hair
PC: the 3542 ofyour hair is brown.
You: your name is aici
You: what is your name
PC: my name is aici.
You: what is my name
PC: your name is jan.

There is something deeply gratifying about seeing your work come to life.

New update coming shortly.

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.

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

AICI is a chatbot framework, running on a (new kind of) neural network.

Wow, that sounded a lot heavier than it really is. Truthfully, it’s all still in it’s infancy: quite a bit of functionality is missing and I haven’t yet provided it with enough ‘experience’ (aka flows, frames and actions), to be very useful. This results in some limitations and challenges still to overcome. So here are some restrictions for using AICI:

Limitations

• Use simple sentences: subject-verb-object kind of structures, no nested or grouped sentences: I haven’t yet defined enough flows to handle complex sentences (These will come in the ‘English grammar’ flow group).
• Capitals and signs aren’t handled yet (very well or at all). This is a matter of expanding the code a bit, for the capitals, and defining the correct scanner and grammar flows for the signs.
• The network is also not yet able to pick up spelling errors. I have an idea for an algorithm to do this, which would consist out of grouping the letters together in front, middle and back, but that’s just an idea at the moment.
• Compound words (like ‘English grammar’) aren’t recognized (again). These are important cause the thesaurus is full of them, and they provide good shortcuts, I think. So I did implement that, and then overrode the code, so I’ll have to do that again. Bummer.
• It’s not yet able to automatically generate frames, flows and actions. Again, I have a couple of ideas for this, but it’s still a bit to soon for that. So you currently have to ‘train’ networks by manually creating frames, flows and some code.
  The lack of this algorithm unfortunately,results in improper error handling. That is to say, some situations currently simply generate a ‘Confusion’ or ‘Don’t know’ kind of output. This usually means that the network found unknown input and should try to generate new frames/flows and or actions.

Small recap:
Both frames and flows are used to define ‘known’ or ‘recognized’ sequences in the input. Frames use restrictions to filter out data and can only handle a fixed nr of simple sequences. They were inspired by VerbNet and FrameNet. Flows are more flexible, they can define optional and repetitive parts. Their origins go back to Coco/R and Gene.

How does it work

There are basically 4 stages at work, to get from letters to a response. The first 2 have already been covered in the scanner demo. These are used to transform letters into words (the scanner view, which contains flows) and words into grammatically understood sentence parts, like: subject, verb,… (that’s the English grammar view, which are also flows). The transformation between those stages is done by code, that’s part of the framework (so it’s all neurons). Basically, this is the syntax recognition stage.

The new stuff starts from here: From the grammar, we do a translation process to the frames and these in turn trigger actions, which finally ‘do’ something, like render some output, store information and/or trigger an external process.

Reminder:
A logical neural network, is a free form network (all link combinations are allowed), which functions on the basis of resonance: a link traversal can activate other parts of the network. It’s roots can be traced back to interpreters and databases.

Actions are able to handle different moods and time frames. This means that the same action can result in a different result, depending on the condition/state of the system. Furthermore, frames provide ‘time’ info (passed, present, future), which can also be handled differently by the actions. There’s a very simple reason for this: actions are all code. So unlike flows and frames, which you can declare, the actions need to be programmed.

The important thing to note here is that it’s all done by neurons, so code, frames, flows,… are all neurons, and everything that can be done with neurons from the designer, can be done through code (in fact, the latter can do quite a bit more). This means that it should be possible to create actions that are able to generate frames/flows/actions. Unfortunately, I am not that far yet.

About the code

I’ve been doing a lot of thinking on how best to explain this. First of all, it’s very dry stuff. Most people probably aren’t interested in the guts of the thing and just want to get working with it.  Possibly, quickly add some of their own functionality and be done with it. Furthermore, I’ve been debugging this thing for so long now, it sort of started to grow on me. I now how it works by now. So I’m ok. Off course, you do need to know some details to get the most out of it. So I decided to, instead of explaining every single neuron in the code, I would simply give you the algorithm that I used for coming up with it in the first place. From than on, I could simply show some step by step techniques to add new functionality. So here goes:

To build an algorithm, I first tried to find the path from start to end neuron/status/situation/.., that should be traversed. Then, each step is focused upon individually, to find out ‘what’ needs to be done to get from A to B. For instance, image you have a text neuron, that contains the value ‘Jan’. If I need to find the flow that fits this input, I need to first find out which part of speech it is (POS=verb, noun, adverb, adjective,…). This can be found through an outgoing link on the text neuron, with the meaning ‘POS’ (this is an agreed upon convention, it could be declared differently, which is the case, the point is that it should always be done in the same way in a single network). Once I have that, I can query for all the ‘flows’ or ‘flow parts’ in which this pos value is used. Perhaps the ‘Noun’ pos is declared in the ‘subject’ and ‘object’ flows. In this case, we do a split and evaluate further. Eventually, one path of the split should die out (if it doesn’t, we currently have a ‘confusion’, but it should end with the addition of a new filter somewhere, or similar), and we can render some output.

Reflection:
As a neuron, I can see links coming in from the left, going out to the right, and when I look up, I can see all the clusters I belong too. If I am a value neuron, I can store something in my belly, and if I am a cluster, and look down, I can also see all my children.

I still need to to a little fixing to AICI (the new storage system has uncovered some more bugs in the network code) and than I’ll continue with some hands on examples on extending the functionality,.. stay tuned.

Storage system

First thing on the agenda is the storage system. I am currently saving everything in xml files (1 neuron = 1 xml file), grate for debugging, crap for real networks: reading/copying and moving 30.000 something files around is just to slow to work with (and that’s just a bare bones chatbot). I initially planned on using an sql db or something similar, but for practical reasons, this is not an option. Hence, it’s going to be binary, blocked flat files.

AICI demo

I would also like to extend the aici demo so that it shows how it can interact with the .net system by perhaps program it to copy files or something similar. Before I do anything to this demo though, the new storage system will have to work, cause debugging it is otherwise far to slow.  When this is done, there will probably be a new release.

Modules

next on the agenda will probably be the modules. These are partial networks, that can be imported into or exported  from an existing neural network. This way, you can share peaces of your work with others (like a set of frames or some actions, a thesaurus, …).

Designer improvements

From then on, I’m hoping to only do improvements/bug-fixes, mostly on the designer, so it can be moved to beta. These are the major areas that I will focus on first:

• There’s still a memory leak in the designer somewhere. This needs some serious attention. I thought I knew where it was, bit it isn’t there, so I have no idea at the moment what it could be.  Mmm…
• The code editor needs a custom control. I’m currently using wpf’s default listboxes for the editor (yes, it’s all listboxes). This was grate to get started, but you’ve probably already experienced some of it’s problems: it gets slow, real fast, only to blow up with a layout recursion exception (bugger). For me, it’s also a pain to get exactly how I want it (you constantly have to fight with it’s default behavior). Solution: custom control.
• The same is true for the mind maps and the flow editor (also all listboxes), which need custom controls.
• I will have to move the search functionality into it’s own thread, cause any small search at the moment freezes the UI. This can’t be off course.
• Finally there are lots of small things still doing strange things at times, but I guess that’s for the beta stage.

• There’s a complete new lockmanager running in the background. This is much more secure (thread-wise, that is) and a lot faster. It’s still a bit of a diesel though, it takes some time for it to get going, but once running, it should be pretty fast. The slow start is due to the storage mechanism (all xml files currently). This is the major drag on the entire system at the moment, and will be fixed next.
• Wordnet import has been seriously updated, a lot more info is retrieved, and it’s now also possible to import the entire db in one go (although not yet advisable, due to a memory bug in the designer, it still takes a major byte out of the hard disk and it simply takes ridiculously long).
• The thesaurus has been given a make over to allow for editing and filtering. He can now also display / edit non recursive relationships. Drag drop is also supported.
• The frame editor has been updated considerably: drag drop support has been added and frame element filters/restrictions have also been introduced (will probably be extended in the future).
• I changed the function of the ‘contains’ operator a bit. It now only checks the contents of a variable. For clusters/children, there are the new instructions (IsClustesteredBy, LinkExists, ContainsChildren, GetInFiltered,…).
• I have added the ‘not contains’ operator.
• New instructions:
• Arithmetic group (+-/*%): I finally caved on those. My original plan was to see how far I got without using any arithmetic in the neural code. I guess, this is as far as I got with that.
• Get-at group: get child at, get cluster at, get out at, get in at, get info at.
• Distinct
• get Incoming, get outgoing, get info, Get in filtered, get out filtered, Get info filtered
• Is clustered by, Link exists, Contains children
• Remove-at group: Remove child at, remove info at, remove link in at, remove link out at
• many, many bug fixes, updates and little improvements.

Aici 1

This demo is a small chat interface. Though, in it’s current state, it’s not much more than a framework. It can initiate a conversation, close it, ask for the name of the user and store the data. It’s not yet able to fully recognize a recurring user since I haven’t defined the neural code for this yet.

I will be explaining how it works and how you can expand on this functionality, shortly. For those who can’t wait and want to get a peek under the hood, here are some pointers to get started:

• There are 3 main stages:
• Flow recognition, which is basically the syntactical stage: check the word types and order. Project pages are:
• the flows (aici/flows),
• the code that is attached to these flows (aici/code/flow code)
• the code that recognizes the flows in the input (aici/code/flow recognition)
• Frame recognition, or the semantics stage. This is where we try to find meaning in the words. Project pages are:
• the frames (aici/frames)
• the code that is attached to the frame sequences (aici/code/frame seq code). The frames don’t have code (yet).
• the code that recognizes the frames in the flow results (aici/code/frame recognition).
• action execution, or the response of the network to the input. Project pages are:
• Actions: all the different actions that the system knows (not yet a lot, should be extended).
• Output: some common code blocks for rendering output. This is also used by the frame sequences, since they are also used to render data in a predefined format.
• Action helpers: code that the action neurons can use to perform common tasks, like stopping a conversation or controlling the timers. Timer callbacks are also stored here.
• The transition between the different stages can be located in aici/code/transition.
• More specifically, the ‘Transition’ neuron is used to go from the flows to the frames and finally to the actions. 
• An action is started using the ‘Execute action’ neuron as meaning for a link from a data cluster to the action that needs to be started.
• The project also contains some mindmaps that describe the inner data structures and functionality.

New release coming shortly.

Time for the second demo overview: the Scanner.  It builds on most of the ideas found in the first demo but it goes way further, and actually does something very useful (although you wouldn’t say it at first).  It’s probably going to be a lengthy piece so I’m thinking of cutting it in 2 or maybe even 3 parts. Anyway, lets first start it up, either through the start menu shortcut (in the Demo’s sub folder, conveniently called Scanner demo), or by opening it in NND (File/Open, select the ‘My documents/NND/Demos/Scanner’ folder). Once the project is loaded, you should see a single text communication channel open (called Text sin), if this is not the case, go to View/Communication channels/Text sin and make certain that it is is selected.

Overview

Lets get a taste of what it does, so enter some text (or leave the one that’s already there) and press the ‘send’ button (or enter).

You’ll notice that it basically does the same thing as the echo demo: the input text is echoed back, except that it’s a bit slower. If you had the debugger tab open, you probably also noticed a lot more activity, so something more must be going on.

And indeed, if you take a closer look to the text sin channel, in the upper section, you can see the neurons that were send to the network (on the left) and those that were returned (on the right), which are different. This was not the case with the echo demo, it simply sent all the incoming neurons back out, as they were. In this demo though, we get back something completely different: TextNeurons, that represent the same thing as the int neurons that were sent as input (if you regard them as ASCII characters). Hence the name of the demo, it’s a scanner.

Converting a stream of ASCII chars into words, integers, doubles and signs is a pretty useful feature and that’s all this demo is capable of doing, but that’s only because I stopped there. You see, in the background, is a general purpose algorithm that converts an input stream of neurons into a single result cluster, using any and all of the flows that are defined in the network. This means that you can use the same algorithm with many different flow definitions. I have simply defined some to recognize words, integers and doubles. You could go further and add flows to find verbs, sentence subjects,.. (in fact, that’s what the AICI 1 demo does). You could even go further still and create flows for visual objects or audio fragments, the same algorithm can be used. Unfortunately though, the editor doesn’t yet support such types of displays for flows (will probably be added somewhere in the future though).

Details

So how is the translation actually performed? To explain this, let me first recap some of the basic concepts of neurons and flows:

• The different types of  data available to a neuron are: incoming and outgoing links, possibly one or more parent clusters, for clusters possibly 1 or more children and a meaning. And finally value neurons also have their value off course. This is important, cause when the translation process starts, this is all the available information.
• Flows are nothing more than clusters that contain flow items, which can be statics or conditionals (loops and options). These in turn can only contain conditional parts. They represent a single branch of the decision tree. Parts can again have the same data as flows: statics or conditionals. So if you are a neuron (a static, part, conditional or flow), you can always look up into your list of parents to see in which flows and parts it is used.

Now, if you recall from the first demo, an input starts by creating an IntNeuron for each ASCII value, which is linked to another neuron using the ‘Letter’ neuron (ID 109). These are all put on the execution stack and the processor starts (the Rules code on the Letter neuron is executed).

So both neurons are new and only have each other as links. This means that we can’t use links or parent/child relationships to resolve the first step, but instead must use something different. The only other thing that remains is the value of the int neurons, so this is compared against some constants to see if they are digits (0..9) alpha numeric (a..z+A..Z), spaces | returns, or something else.  This comparison results in the creation of 1 new neuron per input neuron: the result cluster, in which we store the integer. One of these clusters (or it’s duplicate, due to a split) will eventually store the end result.  This cluster is linked to one of 3 static neurons: Digit, Alpha or Space (signs like . or , are handled a bit differently, this will be explained later). Naturally, if the integers would represent color values, we would use other starting points than digit or alpha. In other words, this first part is variable according to the type of input and the required accuracy of the algorithm. As meaning, we use  the start of the ‘flow recognition’ algorithm, called ‘Stage 1.1’ and put the result cluster back on the stack.  It’s important to put this one back on the stack, and not the item we are looking for. That’s because the algorithm can perform numerous splits and we want the result to be duplicated not the searchable, cause the contents of the list are continuously modified and we don’t want the result of one processor to be modified by  another one (I had to learn this the hard way).

After this initial step, the actual recognition algorithm kicks in. This consists out of 4 stages, grouped by 2. Meaning that  stage 1.2 is executed immediately after stage 1.1 for each neuron (this is the same for stage 2,1 and 2.2), but at the end of stage 1.2 and 2.2 all the result neurons are collected into a single cluster. Only after the last link of the last item on the stack has  been processed, are all the result clusters put back on the stack, with links for the next stage.  This is done for allowing to group items together.

The different stages are:

• Stage 1.1 (search parts/flows): Find conditional parts or flows in the list of parents of the searchable. If there are multiple results, perform a split for each, after the result list has been filtered (these are the shortcuts). If there are no results and this is the only and last item still on the stack, the end result has been found.
• Stage 1.2 (sequence-combine and filter): Check if items are sequential (2 flow items declared after each other in the same parent list, which is a part or flow) and handle floating flows, which are allowed to appear anywhere in the input stream, but which break up the sequence of other items.  Different actions can be performed if the order of the items is not ok: try to solve further or exit without result. Results of sequential items are grouped together.
• Stage 2.1 (search conditionals): Find conditionals in the list of parents of the searchable if this is a conditional part, otherwise the stage is simply skipped. If there are multiple results, perform a split for each after the result list has been filtered (not yet completely implemented at this stage). If there are no results, there is an error in the flow definition.
• Stage 2.2 (process loops and sync-points): If there was a conditional found in the previous stage, check if this is a loop. If so, and the previous item is of the same loop, combine the results. Also start a sync-point (will be explained later) if this was defined on the conditional.

These 4 stages are repeated until there is only 1 result cluster on the stack that represents the end result of a flow which is no longer used in any other flows. This cluster is made the result of the  split for the processor it ran on.  Off course, because there were possibly many splits, there could be many results. These will all be presented in the split-callback cluster (you need to provide a code cluster to the Split instruction, which will be called when all sub processors are done). In this demo, the result is sent back to the sin that caused the input, in a normal situation thought, this will simply start another process, as is done in the AICI 1 demo.

During this whole process, the algorithm is capable of executing callback code (attached to the statics, conditionals, parts and flows) at certain specific moments in the code. This is where the magic happens. The following types of callbacks are possible (together with  their execution time):

• Flow code: this code cluster is executed when a flow has been recognized in the stream. The ‘Result’ variable (ID 1822) contains all the neurons that match the flow. It’s here for instance that the int neurons are converted to a single word using the CiToS (Cluster with ints to string) instruction.
• Filter flow code: this code cluster is called from stage 1.1  (or 2.1, but this is not yet completely implemented) just after all the next items were retrieved from the list of parents of the searchable (stored in the CurrentTo variable). It allows the flow item to determine if it is a valid result, given the current state of the network. This is done by checking the contents of a number of globals, like ‘Prev stage item’ (ID 1956), which contains the previously processed neuron.

In the next post, I’ll go deeper into the specifics of the algorithm itself, for as you’ve guessed by know, it’s a bit funky, and I don’t want to forget all the subtleties, since it’s definitely still a work in progress (there are many improvements still possible).

Thread sync system

There still is a major hiccup in the execution core: some instructions aren’t guaranteed to be uninterruptable, that is to say, some, like the instructions that change links, can be interrupted by other processors before finishing. This could result in data corruption. 

The current protection mechanism against data corruption also appears to slow down the core way to much (most time is actually spend waiting on a sync object here or there).  While trying to fix this, I pushed a bit to far, which resulted in the occasional loss of recycled id’s, in other words, deleted neurons are dropped incorrectly (you can usually see this in version 0.2 after a large input stream has been processed, the explorer might show some red slots).

The fix is a new thread syncing system on top of that provided by the OS, instead of trying to rely on the slower, clumsier locks  provided by the system, I need to create something new.  The design is mostly done, it just needs implementing, which requires some work.

AICI 1

I really like to get this demo working as soon as possible, so I will probably do a lot of work here.  There are some updates required to the system though, before this is possible:

• The wordnet importer needs some work. It currently doesn’t do a good job with respect to verbs, that is to say, their conjugations aren’t imported and linked properly.  This needs to be corrected so that it’s easier to determine the part of speech of a word in a sentence.
• Verbnet needs some serious work.  Not all the data gets imported or can be edited. I also need to write the neural network code to compare the data that was found against the known(imported) verbnet frames. And finally, I need to attach some action code to the frames, so that they actually do something.
• I also decided to rebuild the English grammar used by the AICI example, so this needs finishing.  I did this to force me to take a closer look at each and every flow item as to better understand later on where the filter code needs to be attached and where to attach the code that will build the result.

I guess by the time I have gotten this far, a lot more, currently unforeseen stuff will have been added, so for now, lets make this all for version 0.3. After that, I plan to do some more work on the visual side of things (not how the UI looks, but the image sensory interfaces and their UIs).

I also realized that the flow recognition algorithm simply was not yet mature enough to be used in even the most basic situations. Not just because it was not yet able to process the more complex flow structures, but also because I made a basic design error that I did not yet know off: always put the result cluster on the stack (‘from’ part of link) and the item-to-search in the ‘to’ part. Getting this algorithm ready definitely took the most effort, but it was a grate catalyst to improve the debugger and the execution core. Here’s a (non exhaustive) list of new/changed things:

• New instructions: GetClustersFiltered, GetChildrenFiltered, Freeze
• Added ‘Stop all processors’  and ‘kill single processor’  commands
• Added import of VerbNet data
• Updated Frame editor so that it is able to edit VerbNet data, this is a work in progress, not all data items found in verbnet can already be edited.
• major update to the scanner demo
• Added the start of the AICI 1 demo, which will/should soon become able to parse the English grammar (it’s already able to parse the verb ‘to be’ ex: you are, I am, is he, he is, they were,.. (silly I know, but a start is a start!)
• Updated flow editor with overlay items, which display the presence of certain (useful) links, like code that is attached to the flow item.
• Added a new dialog: ‘Overlay editor’ in the Tools menu for editing the overlays that are defined in a project. This means that overlays can eventually be used everywhere.
• new debug feature: split paths, which allow you to track previously recorded paths of processors.
• new debug feature: attached neurons, which allow you to track down data changes in threads that should not be allowed to change the data.
• Extra info about the static neurons (like the display title and the description) is now stored globally, outside of the project so that I only have to update 1 thing, and not all the projects whenever some documentation needs to be updated. This does mean that you can no longer store any description info for these statically defined neurons.
• Updated the WordNet sensory interface so that it generates POSGroup objects, which ‘group’ all objects together, that have the same text and part of speech. This saves a grate number of unneeded splits while processing the English grammar.
• Made project saving/opening multi threaded so that the UI doesn’t appear frozen.
• Many, many small bug fixes all over the place.

Perhaps a final note, best to uninstall any previous versions.  I haven’t yet tested how the installer works when it overwrites a previous installation, so it might screw things up.  And off course, you can get the new installer from here.

To find some of the more tedious bugs, I had to create 2 new debugging techniques: attached neurons and split paths, which I will explain shortly. The whole algorithm eventually became seriously elaborate to deal with some of the more complicated situations. I need to document this very soon before I forget myself (I guess the radio silence is out of the window, dev time simply took to long for 1 algorithm, I need to do at least 3 more of these which would take far to long). I’m pretty convinced there are still some caveats to work out, but, as far as I have been able to test, all the situations using a scanner flow definition seem to work. The core still shows some hick-ups at times, which can still result in bogus results, but this has also been improving considerably. Expect a new update very shortly (like in a week or so).

I am trying to get the flow recognition algorithm working so it can handle mixed content (words, numbers and signs mixed), which has been one of the more difficult algorithms I have worked on, to date. Clearly, I still haven’t got the order quite right.  This has been the main issue holding back a new release by the way.

So, I’m not doing much today.

The engine appears to be stabling out, although it is still acting fishy on single core machines, where there are errors I don’t have on my multi core dev system, so I need to move to a different machine to test this out. The designer is also still very much lingering behind the engine when this is processing at full speed, but the UI should remain responsive now.

I have also included an extra demo project called ‘Scanner’. It is able to transform an input stream containing integers, representing characters, into words and numbers (ints and doubles).  This doesn’t seem much, and it isn’t, except that it is doing this using a couple of flows and a general purpose algorithm (processing is still slow, mostly because the UI is trying to catch up).  This was the guts of the older ‘English language definition’ demo, which I have split into 2: the scanner and the language definition, which is no longer able to do any processing (all code removed). It’s an example of a more complex flow.

The scanner demo also has the number scanning problem fixed (numbers longer than 2 came out with multiple results). This appeared to be caused by deleting a couple of neurons to many (in the scanning algorithm).  I had already experienced the dangers of deleting neurons I thought were no longer used, but which were because of the splits. I will probably have to implement some sort of a garbage collection system to clean up unused neurons (but that’s for later).

Anyway, here’s the latest download (best to remove previous installation before installing this one).

Set up

Before we send some input to the network, we need to set up the designer so that it is ready to debug:

1. We need to  put a breakpoint  on a statement. You can do this in a code editor. The very first code block that gets called in this network is the rules code on the ‘Contains Word’ neuron, so simply double click on the ‘Code: Contains Word’ node in the Projects tab.
   To set the breakpoint on the first statement, expand the ‘CheckStartTextBlock – space insertion’ code block and click in the little circle on the ‘if’ statement. This should make it turn red.
2. The designer also needs to be set in design mode.  You can do this by the drop down box on the main toolbar or on the debugger tab’s toolbar. There are 3 possible modes:
   • Off: no debugging is possible.  This mode runs faster.
   • Normal: The debugger stops whenever a breakpoint is encountered. When a breakpoint is encountered or a processor was paused, it is possible to inspect values.  This is how most other debuggers provide debug capabilities.
   • Slow motion: In this mode, the debugger automatically pauses and continues on every statement, creating a movie of the execution process. You can use the throttle bar on the left of the combo box to select the speed, which is updated real time. It’s possible to pause and continue this movie using the pause and play buttons on the debugger tab’s menu.  I have included this type of debugging mode because I believe it is sometimes useful to see the path that is taken to a specific point of interest. With this feature, you don’t have to keep pressing F6 to advance.
3. It’s also possible, but not required, to let a processor stop when an error was encountered. This is done by activating the ‘Break on error’ button. This only works when the error happened on a processor in debug mode.

Note that it is not possible to switch between different modes while a processor is running. You can only specify the debug mode for newly created processors.

An overview of all the breakpoints in the project can be found on the right side of the debugger tab. Currently it simply lists all the breakpoints, but new features should be added to this list shortly.

Start a processor

To get started, we need to send  some data to the network through it’s text-sin (sensory interface), so make certain that the ‘Echo channel’ is opened (a communication  channel is the visual interface for a sin). Go to View/Communication Channels/Echo channel, and make certain it is checked (and that the tab is selected).

Once the channel is open, type some text in the input section and send it to the network by pressing enter (or the send button). You should see a neuron appear in the left upper screen, which represents the input event (the neuron that will be solved by the processor). Your text will also appear as a string in the centre dialog screen. There will also appear an object in the centre screen of the debugger tab. This represents the processor that was started and which is handling the input event.

The processor overview contains 2 numbers. The first number represents the name of the processor. This value can be changed and is used to identify it between multiple processors. The second number represents the number of neurons that are left on the stack + the current neuron that  is being solved.

The buttons represent, from left to right:

• a toggle button that can be used to open and close the detailed view for the processor. 
• An indicator that is selected when the processor is paused. This is used to inform you on the run state, it’s not an interactive button.
• An indicator that lets you know that the processor is still running or not. When this is no longer selected, an irrecoverable error occurred in the processor and it is actually dead (in other words, you’ve got a problem when this is no longer selected).

Once a processor is started, the middle square in the right side group on the status bar will be blue.  This will remain so for as long as the network has still a processor running.

Detailed view

If you press the first toggle button, a detailed view of the processor should open in a new tab (using the same name as that of the processor).

This tab is divided into 3 sections (from left to right):

• The content of the execution stack.  This stack contains the neurons that have to be solved by the processor.  You can add and remove neurons from/to this stack using the Pop and Push instructions (The first neuron is automatically added). In our demo, there is only 1 item currently on the stack, that’s the one being solved. This item displays  a square in the stack UI element.
• All the neurons that were assigned as meaning to the links starting from the solvable neuron. The top one will be executed first.  A special case is the ‘Actions’ neuron, which will only be solved when all the others have been, no matter where it is found in the list.
• A stack containing all the processor frames.  A frame represents a single cluster’s code that is being executed by the processor. Since some statements call other clusters, like conditional statements, code blocks,… a processor will usually have a number of frames active. This provides an exact view of the processor’s current execution location.
  The following info is provided for each frame, from top to bottom
  • The code, in textual form. Each code unit can easily be selected separately for debugging purposes (check out the context menu on each item to see what you can do with it).  It’s not possible to edit in this window though (you have to open the editor for this).
  • The name (or id when no name is defined) of the neuron that defines all the code.
  • The relationship between the neuron that defines the code and the actual cluster containing the code.  This can be:
    • Children: in this case, the neuron that defines the code, is the cluster that contains the code.
    • Rules: the neuron that defines the code has a link with meaning ‘Actions’ to a code cluster.
    • Actions: the neuron that defines the code has a link with meaning ‘Actions’ to a code cluster.

The detailed view is great to have an overview of where we are in the processing stage, but it isn’t very useful to  debug a program flow. It’s better to use the code editor for this because it provides a better overview of the connection between the statements.  To do this, open the editor containing the code and make certain the the processor in the debugger tab’s center screen is selected.  This last action is very important for the following reason: a detailed view is opened for a specific processor, so a single tab always links to a single processor.  Code however is not specific to a processor, it can be called by many processors. So it needs to know the processor context for displaying debug information.  It uses the processor that is selected in the  debugger overview for this purpose.  This has a nice  side effect: when you have multiple processors running, you can quickly switch between active processor and view where each one is in the code. Note that the code editor will put a red square around the statement that will be executed next, to indicate execution location.

Do the debug

Code flow

We are ready now to start debugging the network. The first thing you can do is walk through the code using the following commands:

• Run (F5): continue execution until the next breakpoint or until the processor is finished (only active when paused).
• Next step (F6): execute the next step only and  pause again (only active when paused). Note, when  you do a step next on a split instruction that creates multiple sub processors, all sub processors will also wait on the next statement, they wont run wild, but wait until you tell them what to do, which is very useful for inspecting stuff.
• Pause: stop execution and wait until the Run or Next step command have been given (only active when running).
• Stop: Ok, this sounds silly, I know, but I haven’t yet implemented the stop.  I’ve always been able to stop in other ways (I’m running the debugger inside another debugger which is great for creating a schizoid coding mind). If you feel an urgent need for this command, let me know, otherwise, it’ll get in there,  I just have absolutely no time frame for this.

Inspecting values

When a processor is paused, it is possible to inspect the value of any item that returns a result, this includes: variables, globals, result statements, bool expressions and ByRefs. You can do this by selecting the item you want to inspect with the mouse, and pressing F7 or through it’s context menu (Inspect value). This opens a dialog with the debug info of the result.  This can be empty, 1 or multiple neurons.

Debug info for a neuron contains the following info:

• All the incoming links, where they point to and the meaning of the link (note that the meaning UI element still has to be changed into a debug neuron).
• All the outgoing links, where they point to and the meaning of  the link.
• All the clusters that contain the parent node.
• When the parent node is a cluster, all it’s children.
• When the parent is a cluster, the meaning of the cluster is depicted, in brackets, after it’s name.  This is also a debug UI element.

The debug info is depicted recursively for all neurons. This type of debug visualization is used in multiple places throughout the designer.  You might have noticed that the echo channel uses this UI element to depict the incoming and outgoing neurons. The detailed view of a processor also uses it to depict most of the neurons.

Watches

A final feature of the debugger is watches.  These allow you to observe the content of variables and globals in a list for a single processor or across all processors for those that are paused. 

This feature is best experienced using the ‘English language definition’ demo since this performs some splits while processing text input. I have put a breakpoint in the ‘Code: Stage 1.1’ page on the second if statement  (first child if in the left-side path of the only root if) and ran it until ‘Found == Sentence(flow)’ to get the screenshot on the left.

To add watches, drag a variable or global and drop it in the left part of the debugger tab.  This will add it at the bottom of the list. If you are dragging it from a code editor, it is best to hold the ctrl key pressed, so that the item stays at it’s original position.  Note that it’s currently not yet possible to drag from the toolbox.  This is a small bug that still needs fixing. Also note that it’s not yet  possible to remove variables (except by editing the designer file).  This command will be added very soon (just goes to show how fresh the debugger still is).

By default, a list of watches with their values for the selected processor is depicted.  The left side is the name of the variable (or it’s id if no name has yet been assigned). To the right of the name, the content of the variable is displayed. This can be empty, 1 or more neurons, all of which are depicted using the debug UI element for neurons.

If you switch to variable view, the left section of the debugger tab will only display a radio button for each watch. The middle section, which contains processor info, will now display the contents of the selected watch for each processor. 

Also note that, when a processor gets split up into multiple sub procs, the view will switch to a tree.  The root node shows the number of processors contained by the node. If a new input event is sent to the network before the previous has been processed, it is added as a list item, at end of the list. If sub processors split up, more sub nodes are created as children of the nodes that triggered the split (tree structure). This allows you to see how processors are related to each other.  At the moment you can only see the current state, through the tree/list structure.  In the future, an extra view might be added that shows a line view over time to show when and how may processors did a split and when they died out, although that’s just an idea at the moment, so don’t put your hopes up to see it any time soon, there are still far more important things to do.

Errors and warnings

If there are any errors generated by the code, either through the Error or Warning instruction or because of an error in the code, you can view exactly where it occurred. All messages are stored in the log tab. When they are blue, you can double click on them. This will open a code editor with the statement selected  that caused the log item (note: if it is somewhere in a sub section, this is not expanded automatically) Because you can use the same statement in multiple locations, only the first few will be selected, this is to take care of some problems with WPF’s standard controls (will be fixed in the future).

As you can see, it’s all still fresh,  but functional. The debugger has already become a central point of usage for me and I suspect this will only increase, so this will get some extensive testing early on. There are plenty of things that still need adding like conditional breakpoints, counts on breakpoints, enabling-disabling of breakpoints, more commands on the breakpoints-list (like clear, enable/disable all,…),… These things will probably be added as needed.

I am certain there is plenty more to say about NND’s debugger, I just can’t think of anything  anymore, so I guess I’ll leave it by this for today. It’s already turned out a long enough post.

N2D is still in proto type stage, so there are plenty of idiosyncrasies to work around. Here are some tips and tricks that might make things a bit easier.

• When there is lots of code visible, things can slow down fast.  To avoid this, use the drill down/up arrows on some statements like conditional statements to close as much as possible.  If you are drilling down and need to see more code, you can always open sub items into a new code editor.  This will speed up things dramatically. You can do this on conditionals, their parts and code blocks
• Be careful with copying items around (or using shift drag). The editor displays items that are used in multiple places, but you can still be surprised when you change something to an argument only to see it changed it multiple places. The same goes for breakpoints: if an item is used in multiple places and it has a breakpoint defined, it will break everywhere the statement is used.  Keep this in mind while using copy or shift-drag.
• I use the sync with explorer command (F4) a lot. This was mainly because the copy paste system wasn’t working yet.  But it’s still useful I think: it’s a quick route into the explorer.
• The Toolbox is really useful to build code.  If you select the ‘Instructions’ section, you get a good overview of all the available instructions, grouped by functionality.  To quickly collapse and expand the groups, you can use the context menu of the toolbar.
• It’s possible to add items to the toolbox, although this currently has to be done by hacking the “XXXdesigner.xml” file.

Final note

Ok, this turned out to be a longer post than originally planned.  As you can see, it’s already a pretty extended little toolset, although there are still a number of shortcomings in the editor that still need to be worked out, more specifically:

• CPU and memory usage are a problem resulting in a very slow view when there is lot’s of visible data. This needs be solved by a custom control.
• Keyboard entry functionality, similar to the flow editor must still be implemented, this should speed up code editing significantly, compared to the all drag-drop or copy-paste solution.
• Clean up the views some so that they are clearer, compacter,…

Next up will be the debugger, I guess. 

All the different statement types, the general neuron types, some common static neurons, all the operators and the instructions can be accessed from the toolbox. You can easily drag and drop them on the editor.

Assignment

An assignment is used to assign one or more neurons to a variable. After the operation, the variable will reference the result of the right part of the assignment. The left part must always be a variable: regular or global, but no system variables are allowed.  What exactly is assigned to the left part, depends on the type of the right part.

• If it is another variable, the contents of the right part are assigned to the left part.
• It can also be a result statement, in which case the statement is executed and it’s result is assigned to the variable.
• ByRef statements are also resolved: the content of the ByRef statement will be assigned to the variable. This is useful if you want to assign a variable or a result statement to a variable and not it’s contents or results.
• In all other cases, the right part is assigned to the left part, so if you put a code block in the right section, it will not executed, instead, the variable will point to the code block.

(Result) Statement

A statement is used to call an instruction and provide all the parameter values for this instruction. You can call any type of instruction with a statement, even those that return values, although that’s not very useful cause any result values are lost when used in a statement.

You select the instruction using the drop down box.  The instruction itself is also just another neuron, that the statement links to.  This has some consequences.  For instance, if you want to find all the statements that use a specific instruction, just check the incoming links on the instruction.

Most instructions require 1 or more arguments. The values for these arguments are displayed in a list that comes after the instruction. This is a regular drop list, like a code list. Each  instruction should have a little description (you can see/edit this in the description tool-frame if you select the instruction in the toolbox).  This description should say all the required arguments and any possible result values.

A result statement works similar to a normal statement, except that it return a value and tend to be used as part of another statement, like an assignment, a Boolean expression or as an argument value.  Result statements are depicted using the same template, but with a slightly different color to make a distinction.

Code block

A code block is used to group other statements together. This allows you to reuse common functionality.  It is a bit similar to a function in traditional programming languages (like C, Pascal,..), except that there are no arguments allowed and it doesn’t allow for local variable values (scope locality), see Variables for more info on this one. Internally, a code block stores all the statements in a cluster that is linked to the statement.

It is possible to see the statements of a code block inline, by using the expand button in front of the name.  Note that this can slow the editor down dramatically.  Better is to open the code block in a new editor frame (make certain that ‘Statements‘ tab is selected).  You can do this through the context menu’s ‘View code’ command (can also be triggered from the main toolbar). If you want to reuse a code block, you can simply drag it from the explorer frame to the editor.

Even though you define parameters on code blocks, it’s still possible to pass along argument values.  Because the content of a variable isn’t reset when a code block is called, you can create some Variables that function as parameters, fill them before you call the block and access them inside the subroutine.  The same can be done for result values, you can return as many as you want, simply  define some variables and assign a value to them in your code block.

Conditional statement and it’s parts

A conditional statement is used by the processor to perform execution jumps (if, case, while, foreach,…).  Each conditional should contain at least 1 conditional part, but can have more. This depends on how it is set up. You add parts by dropping them in the ‘Children’ section of the UI element (which moves to the right).  You can also move them around, just make certain that the entire part is selected, and not just the ‘conditional’ section. When correctly selected, the part will have a selection border.

Visually, a conditional statement is always represented as a horizontal split in the vertical code branch.  When there is a repetition in the statement (for-each, looped, until, case-looped), 2 vertical lines are also visible, making the conditional statement boxed in. This is an easy visual queue to identify repetitions (so you can have a bit of a birds eye on the code to see the structure, without the details).

There are currently 5 different types of conditional statements (which can be selected from the drop down box): these are:

If statement

An ‘If’ statement can be compared with a structural language’s if statement. It can contain multiple parts, with only the last one allowed to have no condition. The first part who’s condition evaluates to true will have it’s code executed, all other parts are skipped from then on (so there is no fall through possible like in C’s case statement). After all the code in the part has been executed, the next statement after the if is performed, so there is no repetition in this type of conditional.

Adding statements to a part is done by dropping them in the ‘children’ section of the UI element. Because a condition must evaluate to either true or false, a Bool expression tends to be used, but a result statement can also be used. Simply drop an item in the ‘condition’ section.

Case statement

The case statement is, like the ‘if’ statement, very similar to it’s structural equivalent: the content of a value is compared against a number of different possibilities.  Each possibility is provided through the ‘condition’ of the part, which can be a static or another statement that returns a result. Only the last part can be empty, which will be executed if none of the previous values matched the variable.  An empty part is not required though. There is no fall through possible (unlike the switch in C).

When you select this type of conditional statement, the UI element will display an extra drop target for you to specify the variable  who’s content needs to be checked.  This has to be a variable (or global).

Looped statement

A looped conditional is comparable with  the ‘while’ statement, but with a twist: it is possible to define multiple parts.  It’s actually a bit like C’s while and if combined. The loop will run for as long as the condition in one of the parts evaluates to true.  Like the if statement, this part’s sub-statements will be executed.  The last part doesn’t require a condition, in that case, the loop will run for ever and will only stop when a break or one of the exit instructions is called. These instructions will always terminate a loop. If there  is no ‘empty part, the loop will stop when none of the conditions evaluates to true.

Until statement

The until conditional is similar to the looped variant in that it is repetitive, but it only allows 1 part that must always have a condition which is evaluated after all the sub statements have been executed.  When the condition evaluates to true, the repetition is stopped. This type of conditional is very similar with C’s do until loops.

Case looped statement

This conditional is a looped statement, but instead of using an ‘if’ kind of testing style, a case is used. This means that you need to provide an extra case item variable, like the case statement. The statement will loop for as long as a condition in one of the parts equals to the content of the case variable. The conditions in the parts should be static values, result statements, ByRefs, bool expression, variables or globals (so anything that can return a result). You can also specify an empty condition in the last part which will be activated if all of the other parts were different than the case variable.  This results in a never ending loop, which will only stop when the break or one of the exit instructions is called.

The case looped statement is a bit of a strange beast.  It’s origins can be traced back to Gene, where it made a lot of sense for parsing or generating stream.  Id don’t know if it’s useful in this context, so I simply left it in, you never know where this might end up: could be the dumpster, could be some cool trick.

For each statement

This type of conditional statement can probably best be compared to C#’s ForEach loop: it executes a peace of code for each neuron  in a list. Only 1 part is allowed. It’s condition should be a statement that returns some neurons.  This can be a variable or global that contains multiple items, or a result-statement that returns a number of items, like the one that returns all the children of a cluster.

When this type of conditional is selected, an extra drop target is visualized, which should reference a variable (or global) that will receive the current item from the list, as it’s content. This allows you to reference the loop item from within  the subroutine.  After the loop is done, this will still reference the last item in the list.

Bool expression

A Boolean expression is evaluated to the ‘True’ or ‘False’ neurons. It can be used as a conditional part’s condition. The left part is compared with the right part, using the specified operator. This statement type is probably recognizable from more classical programming languages.  There are a couple of important twists to this type of statement though:

First of all, because the operator is also a neuron, it can just as well be another result statement, or variable.   As long as you have something that can be evaluated to 1 or more operators, it’s ok. And this brings us to the second wrinkle:

Because variables, globals and result statements can return a list of neurons, so that the left, operator and/or right sides can have multiple items, the expression evaluates the lists using the following algorithm:

• If the left part has no result (no neurons) and all the operators are all ‘!=’ and the right side is not empty, true is returned, otherwise false.
• Otherwise: for all items in the left part, compare each item in the right using every operator.

Note, when there are multiple operators, it is like having an ‘and’ operator for conditions that work with the same left and right side, but different operators.  This will probably not be used a lot (I haven’t yet).  It’s just a result of the structure, so I let it be available.

All the operators are represented by statically declared neurons (so you can’t add your own). Most are recognizable from classical programming languages like C(++). You have:

The ‘Contains’ operator is a bit different. First of, there is no equivalent in traditional programming languages and it  requires a little more information to work properly: it needs to know which list to search: in the child list (in which case the left part should be a cluster),  or in the clustered-by list, which contains all the clusters that contain the neuron (this list is available in every neuron type, so the left part can be any type).

There is no operator precedence defined as in most traditional languages, since it is the structure of the neurons that defines the order.  This is visually verifiable by the statement’s container: first the left part is evaluated, next the operator and finally the right part.  If left or right has a sub bool expression, this is recursively repeated.

Search expression

This type of statement has already become deprecated. It’s been surpassed by the instructions, which provide more functionality and flexibility.  Nothing more to say about this, I guess.

Variable

A variable is a neuron that is able to store a reference to other neurons in the context of a processor. That is to  say, the content of a variable is only valid for as long as the processor running the code is still alive.  The contents of a variable can also be different for each processor. It will also be reset after the processor has completed evaluating all the links on a neuron and when a split callback function is called (scope locality).

A variable doesn’t have an initial value by default. It is possible to provide one though.  You need to unfold the drop location to make it accessible. This value can be another result statement, variable, global byref, or bool expression, in which case it is first resolved. In all other cases, the value is treated as a static.

Global

A global is similar to a variable, except that it has a different scope.  Globals are able to retain the same value for as long as the processor is alive while normal variables are reset at different times during the execution process of a processor. This is useful to pass along data generated during the execution of one link to another one.

Globals are also able to define what should happen during a split operation.  Possible values are:

• Empty: clear all values from the global in the new processors
• Duplicate: create duplicates from the content of the globals. A duplicate is a neuron with the same incoming and outgoing links, same value (in case of Int-, double- and Text-Neurons) and same children, but a different ID and not clustered by any item (so the clustered-by list is not duplicated, cause the clusters don’t get new neurons added because of a split).
• Copy: simply copy the content of the global to the new processors.

ByRef

The ByRef statement can best be compared with C’s ‘&’ operator, but instead of getting the address of the memory location, in a neural network, it prevents a statement that return a result (like a variable, result statement, bool expression) from calculating that result, but instead returns the statement itself.

Although this statement probably wont be used that much, it is very important for the split instruction to work properly, since this requires a variable neuron as one of it’s arguments.  Often, this statement is the only way to provide this value.  There are other situations where this statement can be used, but less often.

Lock

(Added 11/July/2010) The lock is used to combine a number of statements into a single  unit of execution, relative to 1 or more neurons and/or links. This statement can best be compared with C#’s lock keyword. When you lock a link, you need to specify from and to, but not the meaning, so each link lock actually requires 2 neurons to lock.

When you lock a neuron, the entire object is locked: incoming and outgoing links, value, parent cluster list and children. When you lock a link, only the incoming or outgoing section of the neuron is locked. This is important to keep in mind, if the locked items are operated on from other processors.

Don’t use the ‘duplicate’ instruction or perform any splits (with the split instruction) inside the lock. Although technically possible and allowed, it is not advised since this can and probably will cause deadlocks. Any object that needs to be duplicated during a split and which references the locked object, will cause the network the hang in a deadlock (although you can still terminate all the processors from the designer).

This concludes the overview of all the different statements.  Up next, some tips and tricks.

Before you get started with this post, might I suggest you to check the Echo words demo explanation for a more general introduction on how to use the code editor. This provides a good introduction for most of the general concepts. This post will deal with some more technical details.  Because of the length, I decided to split it into 3 posts:

• editing techniques: that’s this post
• all the different code statements
• and: tips and tricks.

Editing techniques

Code editing is currently based on a drag drop paradigm in which you drag statements to the editor and drop them at the appropriate location.

• Drop locations are indicated using a gray, rounded border, containing the name of the drop target, like ‘Args’, ‘Children’,…
• To add statements at the bottom, simply drop them somewhere in the white space below or at the side.
• To insert items, drop them on the little black line above the statement.  The previous statement will be moved down.
• When you drag an item and drop it somewhere else, it will be moved, except if the ’shift’ key is pressed, in which case the item will remain at it’s original position and will be copied to the drop target (no duplicate, but the same neuron is referenced. This is important!)
• You can also copy and paste items. During the copy process, the id’s of all the selected items are placed on the clipboard.  A paste will get the id’s from the clipboard, transform them into neurons which are put in the selected place.  You paste in drop targets, simply click in the drop target (there is no visual queue yet to indicate that the drop target is selected, this still needs some work) and paste. Note that copy-paste doesn’t yet work across multiple applications.
• If you press delete while an item is selected, it’s reference will be removed from the editor.  If the underlying neuron is no longer referenced anywhere else, it is removed.  All neurons that it references which are also no longer referenced are also removed (cascading delete).  This is the most used deletion method in code editing.  This means that when you delete a statement, all the parameter values that are no longer used, are also deleted. Or, if you delete a code block, all the statements that are no longer used anywhere else, are also deleted from the network.
• If you want more deletions options, use the ‘Delete special’ (ctrl+del)  command.  This shows a dialog which allows you to specify the deletion method you want:
  • simply remove the reference, but always leave the neuron in the network
  • Remove the reference and when  no longer used, delete it (as with the normal delete)
  • Always delete the neuron.Referenced neurons can be
  • left alone: they are not deleted
  • deleted when no longer referenced
  • always deleted
• All neurons can have a ‘display title‘. When the designer finds one for a neuron, this is displayed when possible.  You can easily change this name by pressing ‘F2′ or through the context menu of the selected item.  This is very useful for variables and globals.
• Most statements have a little circle in the front of the image.  This is a toggle button to enable/disable a breakpoint on the item. This is part of the debugger integration into the editor (more on that later).
• It’s also possible to change a statement from one type to another one through the context menu.  A warning though about this command, you might loose data with this command, that can’t yet be undone (no proper undo support yet for this command).
• If you simply need to move a statement up or down, you can also use the context menu, which has a submenu for moving items around.

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 undo system is starting to be functional.  There’s still something going wrong with undoing some link operations, but that’ll be sorted out soon probably.
• There’s a new expression type: the global, which is a variable that is able to retain it’s value for as long as a processor is alive.  It’s also possible to determine what should happen with a global during a processor split: copy or duplicate the value, or do nothing. This is done with an outgoing link on the expression, so you can change it dynamically.
• You can now easily attach and edit an unlimited number of code clusters to any neuron from the code editor.  This is useful to attach code to a neuron that shouldn’t be executed directly by the processor (the actions and rules link) but is stored as data, to be retrieved and called from code. Flows for instance use this to attach code that needs to be called by the parser during different stages of the parsing process.
• The debugger is starting to become fully operational with a useful interface.  There are still plenty of quirks that need ironing out, but it’s starting to become useful. Here’s a screenshot of the debugger in action (I’ll explain what everything means and how to use it later on):

  

• Many, many bug-fixes.

The scanner and parser are almost working.  You can already push text to the network, which  is almost parsed into words (some quirks still left).  It doesn’t yet know what to do with the words though (so the link between the scanner and parser is still broken), this is why I needed the extra functionality in the code editor. I’ll explain the scanner and parser’s details in a later post. For now, check out the new release.

• shortcuts ‘N’ & ‘ctrl+N’: add/insert a new neuron.
• shortcut ‘R’: toggle ’selection Required’ for current option/loop.  This is an important feature that I missed (in gene this was no problem since you could use an empty condition which is not possible here).  The problem is this: sometimes,
  an option or loop has to require at least 1 selection between a part (so you can’t skip the condition or flow), sometimes this is not required.  To allow a distinction between the 2, an extra ‘attribute’ is attached to the conditional (the loop or option), much the same as how a selection between loop and option is done.
• I changed the layout from wrap-panel to horizontal stack-panel, which is more logical to work with.

Note: I have updated the table on the first post about the flow editor so it contains the new shortcuts.

I will probably also have to implement a new statement type, to allow for grouping ery soon.  It’s not really needed for defining the flows, but I think it can be useful later on, during the parsing. For instance, the expression: (verb "ing") means that you are expecting a verb, with ing behind (standing, listening,…).  You don’t need the brackets to define it, but it makes more sense while parsing, if the grouping statement has an attribute attached to it that indicates how it needs to be interpreted.

I have also noticed a ‘logical’ error in the way that I implemented keyboard navigation: some keys have been reversed. So when you are on an item inside a part and need to get to that part, use the left arrow instead of the right.  Being able to select
a part is important to continue adding items at the end again when you have added a conditional like in the next image. It’s annoying, but fuck it, this is one for later on.

I’m also not yet very happy with the deletion functionality.  As it is at the moment, you can remove or delete.  Removing simply takes away the reference to a neuron in a list, deleting, will remove the neuron from the brain.  This is annoying, cause you usually want to remove statics and delete conditionals and parts.  If you want to remove an entire condition, you need to first delete all the parts separately.  A better scheme would be as that of the code editor, which will check for this type of situation.  Again, this is a minor thing, so I will add it to the feature list. At the moment, there are more important things to do though.

A bit more interesting, I have also began work on an English grammar definition.  Here’s a screenshot of a part:

It’s off course not a definition that covers the complete language, but I think it should be enough to build a natural language interface, which should be interesting. I’m certain I missed a bunch, I still need to define adverb handling (which will be treated in a pre parser, a bit like how comments are handled in more traditional parsers) and the scanner also needs commencing.  And expect some shuffling around and updates as I implement the parser for this definition.  At this stage, extra attributes will probably be added, to handle more semantically oriented parsing. I have no idea how long this is going to take me, but I expect some issues with the debugger, so I might be out for a week or 2 for the next update.

The editor is still a bit rough, but it should be useful. I’ve tried to make it more text oriented, so you can easily navigate/add/remove items from the keyboard.  In the background though it’s still listboxes so coding the view and data was easy and fast, just that creepy WPF navigation system, off course more importantly, it makes certain no illegal input can be provided.

Anyway, here’s a screenshot:

Basically, this Flow editor describes how a noun can be found in a stream: a noun should start either with an article (which is either ‘a’ or ‘the’) or a number, followed by 0 or more adjectives finalized with a single noun.  Ok, there are gaps here (it’s still a sketch to show the editor): what’s a number, adjective or noun and how to find them.  These things will be explained in the demo, but basically, you use converters (functions that can transform a neuron into another one, like the object ‘house’ into the neuron ‘noun’) or some other info that can be used in a search function which can be attached to the flow items.

To create one yourself, go to ‘Insert/Flow editor‘, use the toolbar button ‘Create new flow editor‘, use the toolbar button on the ‘Project‘ overview tool frame or use it’s context menu. Press ‘F’ to create a new flow followed by a ‘.’ to select a static or ‘['/'{' for an option/loop (press '|' to add new parts in a loop or option). Here's a complete list of available short cuts:

A final note perhaps on how to use these flows in a neural network.  The thing is, this is really up to you, the application doesn’t make any hard-coded use of them. Though, there will probably be a couple of default algorithms that can be reused. 
The basic idea is relatively simple: when the first neuron comes in, search all the clusters to which it belongs with the meaning ‘Flow’, ‘FlowItemConditional’ or ‘FlowItemConditionalPart’ and store the result list in a cluster.  When the second comes in, try to find all the clusters of the previous result set that allow the new neuron to follow the previous one, all clusters that don’t allow this are removed from the result set.  Various clean ups / lookups can be performed during 2 incoming points. When a ‘flow’ cluster is found with code attached to it, execute this. This off course, can be made as simple or as complex as you want. More on this in a later post. Fuel is depleted for today.

The solution was very simple and pretty elegant: use a different list to store the result of a split. So now a processor has 2 internal lists: the execution stack used to build the code that should be executed next and a list with the split results (unique neurons) and their weights. A couple of new instructions had to be created to control this list.  No biggie: an Add, Remove, Get and Clear.

Anyway, I’m updating all the documentation now.  If I mist something, don’t forget: 2 separate lists. The next post will probably be a Demos explained on the split.

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:

To start the demo, go to {Windows start}/N²D/Demos/Echo words if N²D isn’t already running, otherwise, do File/Open and browse to the folder {My documents}/NND/Demos/Echo. Note that a project is opened by selecting a folder, not through a file (this might still change in the future, if required).  If the project has already been opened, you can reopen it using File/Recent projects. Once opened, you should see something like this:

Note that the echo channel (a text channel) is shown by default. This is because I saved the project with the channel opened: visibility of a channel is stored, not for other items at the moment.  You can close this window by right clicking on the tab and selecting the close command. You can also control which channels are visible through the menu: View/Communication Channels. The designer will
create a communication channel for each sensory interface in the network.

The Text channel contains the following items:

• In the bottom: a Text box to enter text you want to send to the network
• with a toolbar on top of it containing
  • buttons to control the visibility of the top row items,
  • a toggle button for turning the speakers on/off,
  • a combo box to select the way the sin splits up the input strings into neurons
  • a button to send the text to the sin.
• in the middle is a list box containing the current conversation: all the text you sent interleaved with the answers of the network.
• and finally the top row contains 2 listboxes which contain visualizations for the neurons that were processed as input by the sin (left one) and received for output (right part).  Note: selecting a line in any of these 2 lists will also select the corresponding line in the conversation section and visa versa.

If you make certain that ‘Speaker‘ is pressed and your loud speakers are turned on, you should here ‘Type here’ once you press the ‘send‘ button (and haven’t changed the input text). Some items should also appear on the screen, something like:

What just happened? Well, a whole lot really:

• The text channel displays the string ‘Type here’ in the central dialog overview.  This is done by the designer.
• next, it sends the string to the Echo channel’s backing sensory interface which splits it up into 2 words: ‘type’ and ‘here’.  This is because it is in ‘Use Words’ mode.  There is another echo demo, called ‘echo letters’ which is programmed to ‘Use letters’ by the way.  If you want, you can open this and try it to see the difference. In the ‘echo words’ demo, the 2 words are converted into text neurons (by searching a dictionary of already created text neurons or by creating a new one, which is stored in the dictionary. These 2 text neurons are linked to a newly created neuron which represents the input event.  This conversion is done by the sin itself.
• The sin also raises an event to let the channel know about the neuron it just created as input value which is displayed in the top left list.  A processor is created and the neuron representing the input event is pushed on it’s stack, which starts of the network. Up until now, we haven’t really used the neural network yet, everything was done using traditional code. This changes once the processor is started.
• The processor ‘executes‘ the code attached to the links between the ‘input event’ neuron and the text neurons (how this code gets there and how it looks like will be dealt with later).  This is the neural network doing it’s thing which will eventually execute several ‘Output‘ instructions, sending neurons back to the sin.
• When the sensory interface receives these neurons, it converts them back into a string and raises an event. And so we get back into the world of regular code.
• The communication channel, which receives this event, displays the text in the conversation dialog and the neuron(s) that represent the string in the top right list box.

Ok, but what exactly happened in the neural network itself? Truth is, not much as you will see. It’s time to show some code. If you select the ‘Project‘ tool-frame, you will notice 3 items: a mind map (more on that later) and 2 code items, each one is simply a reference to a neuron in the network. To open them, double click on the item.  Let’s start with ‘Code: ContainsWord(in)‘.

Mmm, interesting. All GUI-like is probably the first thing you’ll notice. Indeed, there is currently no textual method for entering code, as more traditional development environments tend to use.  I choose this way for 2 reasons: first, it’s faster to develop (at least, in WPF that is) and it lowers the entry barrier since you can visually put items together instead of having to conceptually create a peace of text in your mind, requiring a grater level of knowledge. In the long run though, this technique tends to be slower than writing code and it also somewhat limits the amount of code displayed, but be patient, there is a solution for this.

Lets first go over the 2 lower tabs.  These represent the 2 different code lists that can be assigned to the neuron: the ‘Rules‘ and ‘Actions‘ list. Note that these lists are only created if there is code, for as long as you don’t drop any objects on the design surface, there isn’t actually a code list assigned to the neuron. The bottom tab-strip also has a context-menu which allows you to toggle wether this neuron is shown in the project tree (under the currently active folder, or the root if there is no folder). You can also create new code clusters from the sub toolbar, but remember these are code clusters (which can also point to code clusters), not neurons with code clusters assigned to them.

Both lists are called at different times, and serve a different purpose. Code in the Rules section, is called when this neuron is used as the meaning for a link that is currently being processed by the processor. The Actions code list is called by the processor when this neuron was processed by the processor and all other links have already been handled. Usually, you don’t program on the last tab (actions), it is provided to ‘view’ the code that was attached to it by the sin that generated it (see further). Note that there are other tab possibilities, but these have no importance for now and will be explained later on.

So what does this actually mean for our example: well, the ‘ContainsWord(in)‘ neuron is used by the sin as the meaning for the link between the generated neuron and each word in the input string (this is pre defined), so for each word in the input text, it will call this little peace of code.

As you can see there are only 2 statements in this code list. The second statement calls an ‘Output’ instruction which will send the content of the ‘CurrentTo‘ variable to the content of the ‘CurrentSin‘ variable, in other words, this is the actual echo. Both variables are system defined and are filled in by the processor, they can not be modified, unlike normal variables. You’ll notice that they appear to be multiple variables stacked on top of each other.  This is to indicate that the same neuron is used in multiple places.  It’s a visual cue to indicate if a code item is used somewhere else or not (ahh yes, unlike regular code, these are neurons, all linked to each other, there is nothing preventing you from literally using the same statement in different places). That’s it for doing the echo really.  The rest of the code is simply to make certain that the sin will put all the words in 1 line with spaces in between them. This is spread out over 2 locations: the first statement and the ‘Input actions‘ code list of the sin.

The first one, is a ‘Block‘ statement, which can best be compared to a ‘Function call’ except that there are no parameters or return value allowed. To view it’s content, use the drop down arrow for an inline visualization, or ‘View code‘  in the context menu to display the code in a new window. You should see something like this:

Note that the code is located in the ‘Statements‘ tab this time if you opened a new view. That’s because a code block has an extra known code cluster attached to it: the code for the block.  It can also have a rules and actions list, but these are not used in this example (and probably will rarely be used this way on code itself).

Ok, and what exactly does this code do? To explain that, perhaps a note first on how a text sin converts output data. Whenever it receives a neuron, it is converted to a string which is than sent as an event to the outside world.  Off course, in our example, we don’t show each word on a separate row, instead, we show the entire input statement on a single line with spaces between the words.  This can only be done if the sin knows where a sentence starts and where it ends, otherwise it simply sees a stream of output data. So to accomplish this, there are 2 special neurons that it recognizes: ‘BeginTextBlock‘ and ‘EndTextBlock‘. When these are sent to a text-sin, they are not converted, but instead, BeginTextBlock will make it accumulate all the strings until the EndTextBlock neuron is received. So that’s what this little bit of code does: it checks if this is the first word being processed, if so, the ‘BeginTextBlock’ neuron is sent and we store a switch so we know of this event.  If it wasn’t the first one, we sent a space to the sin, so we don’t concatenate the words. The ‘EndTextBlock’ is handled in a different way, we’ll get back to that later on.

First a bit about the different statements that were used in this little code block.  The top most one is a conditional statement, set to ‘if’.  N²D takes conditional statements even further than Gene and
completely unites all different conditionals into 1 and the same statement type, with an option to switch between them.  So a Do-while, While-Until, For-Each, For, if, case, and case-loop (not possible in other languages) are all combined into 1 statement, with a single neuron that switches between the 2. This approach is taken because of it’s ease in coding: it becomes a lot easier to change an if statement to a loop with multiple if’s: simply make it a loop (yes, you can have multiple conditions in a while loop). To design this bit of code, you can simply drag a ‘Conditional statement’ to the designer and drop ‘Conditional parts’ in the ‘Children’ area to the right. A conditional part forms a single trunk of the evaluation tree. It contains a list of code items (which can also be dropped on it’s respective ‘Children‘ drop area) and possibly a condition that determines if the part’s code is executed or not. This condition should evaluate to the ‘True’ or ‘False’ neurons.  Usually this is done by a Boolean expression (as has been done in this example), but this is not required, it could just as well have been a result statement that returns ‘True’ or ‘False’.

A word perhaps on the little arrows found on the variables to the right of the name.  These allow you to assign a default value to the variables.  In our example, we can’t use this cause all of them are system variables who’s values are controlled by the processor.  Regular values however don’t have a value the first time they are accessed in the context of a processor.  You can use this little drop target to assign a default value.  This can be a constant, or another statement that can be resolved to one or more neurons.

Another important fact about these variables is that they can point to 1 or more neurons.  They actually function as buckets.  This is very useful in that there is only 1 known type: a list of neurons.  This list can contain 1 item or more.  Often times, you will use a split to resolve multiple values to 1.

The last part of this demo can be found in the ‘Code: Echo channel‘ Project item, which is actually a reference to the text sin.  If you open the ‘Input actions’ tab, you’ll see the final 2 statements for this demo. This tab represents a code cluster that the text-sin attaches to each input neuron that it generates so it can be executed after all other links have been.  In our example, we do 2 things: let the sin know the sentence is closed so the string can be displayed and delete the input neuron, so we don’t let the network grow indefinitely. By default, all data is always stored, if you don’t want this, like in this example, you will need to manually delete the neuron.  All of it’s links and stuff will be cleaned
up automatically.

The notion that the code is spread out over different locations and called at different times is an important point: a neuron network can not be programmed in a monolithic fashion as a single code block. Code is always divided into small chunks, which run at different times, in an undetermined order.  This is where a lot of it’s power comes from.  Once you grasp this, you are a long way into designing something truly beautiful.

Gosh, dear all mighty, this was a climb indeed. I’m glad you were able to get till here, all the way to the end. Even though this is a small demo, it packs a punch when it comes to new ideas. There are plenty more areas to cover, but I am certain that once you become more familiar with the basic concepts explained in this demo, the rest of the ride will be downhill. More demo explanations to come soon…

Viewing and importing thesaurus data

N²D has access to the English version of the WordNet database through a sensory interface (input/output port). Apparently there are WordNet database for other languages, but these are not yet available. To open the view for the WordNet data activate the menu item: View/Communication Channels/WordNet (note: opening for the first time can take a little time as the database needs to be opened, should get fixed somehow in the future).  This should show something similar to (although with less text):

You can search for words in the database.  All known meanings will be displayed. You can also select to show a specific relationship type with the drop down list.  If ‘As Part’ is pressed, all entries that contain the specified text will be shown.  You can either import a single meaning separately or the whole lot, including all the relationships (advised) and see the network grow.  The system should be able to do multiple imports at the same time (you’ll notice that a single import can take a long time, depending on how many relationships there are for the word). While the network is learning, the green box in the right bottom corner is filled.

You can browse through all the imported items from the thesaurus view.  You can select the type of relationship you want to see.  All root tree items represent root neurons for the specified relationship. With the text box, you can search for words in the tree. All neurons can be dragged to other locations (like mind maps for instance, see further).  It is also possible to add items to the tree by dropping them on the level they should reside.

Creating Mind maps

Mind maps allow you to draw neurons in a free form manner, similar like vector graphics. There are multiple ways to create new mind maps, you can:

• use the menu: Insert/Mind map
• use the toolbar button (4th from left)
• or when on the ‘Project’ tool window, use the local toolbar button.  From here, you can also create sub directories, change the name of the project items (F2),…
  Note: Mind maps (and all other project items) are added to the currently selected folder or the folder that contains the currently selected item.

Most of the mind map commands are currently only accessible through it’s context menu. For creating new items, you can also use the toolbox. You can add different types of neurons or change them to another one.  Watch out with changing the type though, cause this might loose data sometimes (for instance, when you change a cluster into a regular neuron).

If you select a neuron, you can use different ways for showing ‘related‘ items, like children, incoming or outgoing links and clusters to which the selected item belongs. You can also manage to which clusters it belongs.  If you have multiple items selected, you can quickly create a cluster for them through the ‘Make cluster‘ command.

The easiest way to create a link between 2 items is by selecting them both (the first will be ‘From‘, the second ‘To‘) and activating the ‘Link‘ command. This will show a dialog with From and To already filled in, so you only have to select the meaning of the link.

As a side note, ‘Sync with explorer‘: a very useful command, accessible from the main toolbar, allows you to quickly find the selected item in the explorer.  This can be used from most places in the designer (all items that have a neuron as backing).

Drawing

Yes, N²D is also a drawing application, although some further evolution is clearly needed in this area.  Drawing capability is provided so you can work with the visual sensory interfaces. To create a new image channel, activate the menu command Insert/New Image channel.

Perhaps a word about the difference between a sensory interface and a communication channel: the underlying network has sins, which are also just neurons and have no ‘functionality‘. N²D, the designer, creates a ‘communication channel‘ for sins so you can work with them. If you use the network in a different application, the communication channel might look completely different, but the sin is still the same.

An image channel currently has 2 sections: the left part to manage/import multiple images (which is not yet fully functional) and a right part that will eventually contain 2 sections: an input and output section.  The output is currently not yet visible, but is supposed to function as the output part of the sin, so you can see images/videos that the network generates.

The input section works as an ink canvas, so you can use a pen table, and apply pen pressure (this can be toggled). The shape, size and color of the pen point can be selected. It is also possible to switch to a gum or selector.

Commenting

All neurons and some other types (like mind maps and frame editors) can have a description.  This is a FlowDocument (rich text format), so you format the text. Spell check is also provided. The description of the currently focused item is shown, you will have to make certain that the ‘Description’ Tool window is visible.

Standard text editing functionality is present:

• Select the font type
• and font size
• Bold/Italic/underline and Outline
• Bullets and numbering
• Spell check

As a side note: The selected item is a NeuronCluster, so it can have child neurons.  The explorer in this screenshot, is set to display it’s side panel which contains all the children of the selected cluster. Just like from the explorer, you are able to drag items from the left panel.  It’s also possible to drop neurons on the panel, which will add them as children to the selected cluster.

Creating frames

Frames are a form of compound objects (a group of neurons that form a single unit) which can be used to translate input from one form to another and to connect code to these compound objects. They are created in a similar way like mind maps, and can also be managed from within the project tool window.

To create a new frame, you basically push the toolbar buttons in sequence:

• The first one will create a new frame (a frame editor can contain multiple frames,usually they are related to each other somehow).
• Next, you create a frame element for the selected frame (make certain there is one selected, there are still some bugs in this area). You can also drop items to be used as frame elements.
• The third button creates a new frame evoker (all neurons in this list are put in a cluster ‘Evokers’, so you can easily do searches on them, more on that later). Like frame elements, you can also drop already existing items in there.
• On the last tab, you can edit all the sequences for the frame.  Use the 4th toolbar button to add a new sequence, make certain it is selected and use the buttons to add/remove or move up and down the frame elements from the first tab to build a sequence.
• The last toolbar button is used to display the ‘Import from FrameNet‘ dialog, with this frame editor already selected.

Importing frames

If you don’t feel like creating your own frames, you can always see if they have already been included in FrameNet, which you can import, either from the menu Tools/Import from FrameNet or from the
toolbar of a frame editor.

You can search FrameNet using the textbox in the upper right corner. The first time you select a row in the upper list might take a little time, this is because he is loading the WordNet database (which takes a little time). This is required to provide a mapping between FrameNet and WordNet data (not provided by default). Some mappings have already been created but most still need to be defined.  Each time you display this dialog and change some mappings, these will be saved.

There are many more things to discover in the designer, but I’m all out of words for today, so I’ll continue this on another occasion.  In the mean time, lot’s of fun playing with your new toy.

The whole thing is written in C#, the designer in WPF.  So for the time being it is strictly windows stuff (XP or vista). The core neural network and sensory interface libraries should be portable to Mono but
the designer will be a tat difficult. I don’t know yet how to tackle this one.

With regards to processors I can be simple: the more the better.  This is a massively multi threaded application, so the more cores the faster it should run.  I only have a dual core here, so I haven’t had the change yet to see it running on lots of threads simultaneously, but I would love to find out.  As I am writing this, I am sure there will still be a lot of bugs to filter out.

So to recap:

OS: Win XPSP2/Vista
Platform: .net/WPF
Hard Disk: + 450 MB
CPU Cores: as many as you can find