Because

Let me first give an example of a ‘because’ statement that a user might say:

I have a dog because I like animals.

This statement is a bit of an oversimplification, perhaps just right for an example.   It doesn’t only specify why I have a dog, but also that I have a dog and that I like animals. All this data should be stored and retrievable so that the system can answer questions like:

Why do I have a dog?

Do I have a dog?

Do I like animals?

So, before we can store the data, we need to find an input pattern that’s able to handle ‘I have a dog because I like animals’. To start with, we could do something like:

I have a $value because $reason [.]

This can work for many possible input values, except that the ‘I’ vs ‘you’ change is difficult to do since there is no knowledge of the context (‘you’ can change into ‘I’, ‘me’,… depending on the context), so this is the least usable pattern, but there are other possibilities.  For example, lets take:

I have a $value because I like $object [.]

or better:

I have a ^value:noun because I like ^object:noun [.]

With this input pattern, we are able to extract all the valid data so that it can be stored in memory and we also have static text for ‘I’, which can easily be transferred manually. A small improvement might be to replace ‘$value’ with ‘^value:noun’ so that only a proper noun can be captured instead of things like ‘I have a pretty big keyboard on my lap sitting there because I like typing’. The same goes for ‘$object’. As in the previous example, ‘typing’ could probably better be transformed to ‘type’ before you store it, so in the pattern you could replace ‘$object’ with ‘^object:verb’ or ‘^object:noun’,… Anyway, lets take a look at how the do-patterns would look like for storing this info:

#user += $value

#user.like.($object) = yes

#user.($value):why = “because you like $object”

In the first line, we create a ‘has’ data item for ‘$value’. The second line adds the ‘object’ to the ‘like’ list, with the value ‘yes’ so that it’s clear the user likes it. And the third line stores the reason why the user has a ‘value’. ‘:why’ is a function that provides access to the ‘reason’ data-tree. What you store in ‘:why’ is completely up to you. In this example, we store a text, between brackets, cause I wanted to preserve the spacing, but you could also treat it as a sub asset (or anything else, like a link to another rule), allowing you to write paths like #user.($value):why.object.

Why

Once you have stored  the information, you can retrieve it again if the user asks a why question. Here’s a possible input pattern that you could use for capturing this question:

Why do I have a $value [?]

or better:

Why do I have a ^value:noun [?]

And the output pattern could look something like:

You have a $value #user.($value):why

or better:

Bot says when:  #user.($value):why

You have a $value #user.($value):why

else:

I don’t know why you have a $value

That was easy enough. The first line is the most basic approach, the only problem with it: if the bot doesn’t know, it returns ‘You have a’. Which is no good. Better to put it in a conditional and check if there is a ‘why’ value, if there is non, let the bot say it doesn’t know. To check if there is a ‘why’ value, simply put the path in the ‘when’ close. This will check if the result of the path has a value. To check if it doesn’t have a value, use the not (!) operator in front of the pattern, like so:

Bot says when: !#user.($value):why

I don’t know why you have a $value

else:

You have a $value #user.($value):why

Improvements

Right now, we have a working system to handle because/why type of things, but it’s not very flexible, I mean, there are tons of reasons why you can have something, and not just because you like something else. Also, there are more people then just ‘I’, so lets improve the input patterns a bit and make things more flexible.

Using the Thesaurus

Lets start with ‘I’. As you had probably already guessed, the thesaurus variables are ideally suited for this. So, here’s an improved input pattern:

^s:pronoun.subject (have|has) a ^value:noun because ^w:pronoun.subject like ^object:noun [.]

Ok, that’s already a bit more complicated. The ^s variable can capture any child of the pronoun ‘subject’.  If you check in the thesaurus, under the pronoun POS, there are a bunch of greyed-out items, one of which is ‘subject’. These are ‘placeholders’, that is: these thesaurus items don’t actually contain a word, only a label. So our ^s variable can’t actually catch the word ‘subject’, but only it’s children: I, you, he, she, they, we, it.

The do-patterns also become a bit more complicated, since we will now have to calculate the inverse of the pronoun and we also have to extract the asset out of it. Luckily, there are some helper functions for this:

#($s:ResolvePerson) += $value

#($w:ResolvePerson).like.($object) = yes

#($s:ResolvePerson).($value):why = “because &w:InvertPerson ^verb.like:conjugate($w:ResolvePerson) $object”

:ResolvePerson is able to extract the asset (or concrete representation) out of a word.  At the time of writing: I and you  are supported. Names, ‘He’, ‘she’, ‘it’,… need some further testing.
:InvertPerson uses thesaurus links to jump from one person to it’s inverse, if there is one. So ‘you’ becomes ‘I if ‘you’ was used as a subject.
:Conjugate will try to find the correct conjugation of a verb, based on the argument that is supplied. This has to be an asset, usually the asset representation of the sentence-subject. So if you want to conjugate for ‘I’, you pass in ‘#bot’. ‘You’ becomes ‘#user’, and so on.

Split the patterns

The second improvement that we can make to the pattern is a bit more radical and relies on a special feature of the pattern matcher. You see, the pattern matching process is not restricted to finding just 1 pattern in the input. It will try to find the longest possible sequence of patterns that it can. That is, if the same words can be caught with a single pattern, this pattern will get precedence over a sequence of patterns. But if the pattern matcher can do a longer match by using 2 patterns instead of 1, that will become the result. This allows us to split up the first part of the sentence: ‘I have a $value’ from ‘I like $object’. opening up a whole new range of possibilities, and more importantly: saving use lots of duplicate work. The do-patterns become a little different though. First the input-patterns:

Topic: HAVE

^s:pronoun.subject (have|has) a ^value:noun

because ^s:pronoun.subject (have|has) a ^value:noun

 

Topic: LIKE

^w:pronoun.subject (like|likes) ^object:noun [.]

because ^w:pronoun.subject (like|likes) ^object:noun [.]

As you can see, not much has changed except that they are now 2 sets of patterns and each set has a version with and without ‘because’ in the front. We could also have written them as:

Topic: HAVE

[because] ^s:pronoun.subject (have|has) a ^value:noun

Topic: LIKE

[because] ^w:pronoun.subject (like|likes) ^object:noun [.]

But we aren’t. Instead, we keep each input-pattern in it’s own rule so that each can have it’s own set of do-patterns. This way, the ‘because’ version can be treated differently. Basically, what it comes down to is this: when there is no ‘because’, we simply store an extra memory field called ‘subj’ which allows us to recall the left part of the asset operation (excluding the attribute). When we have a because, we check if the ‘subj’ field is set and if so, we store the ‘:why’ in this field. Here are the do patterns:

Topic: HAVE

#bot.who = $s:ResolvePerson

#bot.Inverted = “#bot.Inverted because $s:InvertPerson ^verb.have:conjugate(#bot.who) a $value”

#bot.attribute = $value

#bot.who += $value

#bot.value = #bot.who.($value)

#bot.Subj = #bot.Who

#bot.Subj.(#bot.attribute):why = “because $s:InvertPerson ^verb.have:conjugate(#bot.who) a $value”

Topic: LIKE

#bot.who = $s:ResolvePerson

#bot.Inverted = “#bot.Inverted because $s:InvertPerson ^verb.like:conjugate(#bot.who) $value”

#bot.value = yes

#bot.attribute = $value

#bot.who.like.($value) = yes

#bot.Subj = #bot.who.like

#bot.Subj.(#bot.attribute):why = “because $s:InvertPerson ^verb.like:conjugate(#bot.who) $value”

The full code example can be found in {documents}\NND\Demos\Why_Because2.dpl. As you can see, it’s a bit more code then where we originally started. Though if you look a little closer, a lot of it is boiler-plate stuff: store who, attribute, value, subj, inverted.
Key advantage here: with only a few patterns we can have any type of combination: have because like, like because have,  have because have, like because like, because have, because like, have, like, have because like because have,….

The basic set-up is always the same, we dissect the sentence into it’s parts so that they can be reused in other parts. here’s what we need:

• calculate ‘who’ (the asset form of the subject part in the sentence = I, you, he,…) so we can reuse it and don’t have to recalculate it each time.
• store the the inverted sentence, for output generation (can always be useful)
• the attribute and value (‘color’ is the attribute of ‘yellow’). In this example, strictly speaking not really required, but other parts of the concept rely on this data, so best to get used to it.
• subj: sometimes, the ‘who’ isn’t enough to find out where some data needs to be stored. ‘like’ (and most other verbs) is a good example of this. So if we want to get to the correct data path later on, we need to store this new path, hence the existence of ‘subj’.
• If ‘when’, ‘where’, ‘how’,… is also present in the sentence, these are all data parts that can be stored like attribute, value or more complex sub structures.

There are a few extra do-patterns required to get this working correctly. The ‘who, inverted, value, attribute, subj’,… fields of the #bot are all temporarily, that is: they are supposed to be used as mid-term memory, for as long as the current input is being processed, so that the information can be passed along from one pattern to another. This means that we need to remove the data after the input has been processed so that it wont interfere with any of the next input. This can be done from the Chatbot’s properties view (select the menu item view/chatbot properties, next go to the ‘Do after output’ tab.). here’s how it would look like for this example (can be simplified, which we will do in the next example):

#bot –= Inverted

#bot –= Who

#bot –= Subj

#bot –= attribute

#bot -= value

Also, in this example, I only used thesaurus variables. You can achieve similar results with regular variables, but there has to be a small change in the pattern definition for it to work properly. Everything has to do with the fact that a regular variable can only determine it’s end by what is defined after the variable, and if the pattern definition ends with a regular variable, it will collect the remainder of the input and never jump to another pattern. So we need to put something behind the variable if the ‘because xxx’ needs to be handled correctly. This can be done by moving the ‘because’ from front to back like so:

Topic: HAVE

I have a $value [.]

I have a $value because

Topic: LIKE

I like $value [.]

I like $value because

The biggest disadvantage: you need extra patterns to handle a ‘because xxx’ (not shown or included in the demo), but on the plus side, the do-patterns become a little simpler using this type of pattern definition style. For a complete example, see: {Documents}\NND\Why_Because.dpl.

Sub topics

There’s one more trick we can use to make the patterns more flexible and which will also resolve a final problem caused by using multiple rules as we did in the previous step. You see, finding a list of unrelated rules is primarily done to recognize multiple sentences in the input and not for splitting up a single sentence. That’s because all the outputs from those rules are always automatically combined. So you can’t change the order or content. This can make output management a little tricky.

The solution comes in the form of sub-topics or sub-rules. With this technique, it’s possible to reference a topic or rule by it’s name from within a pattern in the same or other topic. This allows us to split the ‘because’ out into a third topic and then group them all back together into a single rule, which will be the final, single result. So, on the input side, it becomes more flexible, and thanks to a special variable ‘$output’ and a switch in the chatbot properties, we can also take control of the output side. more on that later, lets first start with the input patterns, how do you declare sub-topics?

Topic: HAVE

^s:pronoun.subject (have|has) a ^value:noun

Topic: LIKE

^s:pronoun.subject (like|likes) ^value:noun [.]

Topic: BECAUSE

because

Topic: BECAUSEHANDLER

~have

~like

~becauseHandler ~because ~becauseHandler

The first 2 input patterns should be familiar by now, nothing has changed since before, only the ‘because’ version has been eliminated. The first new topic is also nothing special, just a single word ‘because’.  The magic happens in the last topic, which groups all the other topics together.

~ is used to indicate a Topic reference. It’s always followed by the name of a topic and possibly a dot followed by the name of a rule. It’s meaning is simple: include all the patterns in the rule(s) of the specified topic at the location of the reference. Here’s an example for sub rules:

~have.statement because ~like.statement //presumes that topics ‘have’ and ‘like’ have a rule labeled ‘statement’

Now, if you look at the last topic: ‘BECAUSEHANDLER’ you’ll notice that it only contains references to other topics, it’s a root topic. In this example, it’s purpose is to provide a place to declare the output for every topic, so we can combine things correctly + it also stores the ‘why’ relationship. Also, if you look at the last pattern, it references it’s own topic, 2 times. This is recursion and allows us to recognize a sequence of ‘becauses’ like: I have x because I like y because I have z,….

You might be wondering why it’s the BECAUSEHANDLER that stores the ‘:why’ link and not the ‘BECAUSE’ itself. That is because at the time of the ‘Because’ pattern, the reason is not yet known (this is defined in the next pattern, which hasn’t been processed yet), so it can’t link anything up yet. To overcome this, we make certain that there is an extra rule that gets executed after every other part of the sentence: the BECAUSEHANDLER.  In other words, the ‘becauseHandler’ is a way to perform some code after all the patterns have been processed.

By the way: topic names can be edited in the ‘project view’ (select the topic, press F2 or right mouse click/rename). A topic name should be unique within the project if you want to use it as a sub-topic, otherwise it’s not that important, but the UI will always warn about duplicate names and those topics will have a red icon instead of blue. The name of a rule is always visible in the ‘description view’s title when the rule is selected.  It can be changed in the topic editor: select the entire rule (don’t click on a pattern, but on the background of the rule). With F2, you get a dialog to change the name.

Let’s continue with the do patterns.  For ‘have’, ‘why’ and ‘like’, they remain very similar: the patterns are used to store the inverted sentence, who (asset), the attribute, the value and the ‘subject’. In this example though, instead of directly storing it under the ‘bot’, it is stored underneath ‘mem’ so that we can move the entire result set with 1 statement later on. So here’s a small example of the ‘have’ do-patterns:

#bot.mem.attribute = $value

#bot.mem.who = $s:ResolvePerson

…

And so on. The really interesting stuff happens in the ‘BECAUSE’ and ‘BECAUSEHANDLER’ topics. Note that this time, we have some do-stuff in the ‘calculate’ area and others in the ‘do’ section. The major difference here: ‘Calculate’ is done, just before any of the conditions are evaluated, so this allows us to do pre-calculations that can be used in those conditions.

Topic BECAUSE:

#bot.because = #bot.mem

#bot -= mem

Topic BECAUSEHANDLER:

Rule ~becauseHandler ~because ~becauseHandler

Calculate:

$result = “because #bot.mem.Inverted”

$path = #bot.because.Subj.(#bot.because.attribute)

Output when: #($path):why == $result

Yes, I now #bot.because.inverted because #bot.mem.inverted\.

else

I see, #bot.because.inverted because #bot.mem.inverted\.

       Do

#($path):why = $result

Rule ~have

$output

First off, BECAUSE: this moves the ‘mem’ field to ‘because’ and ‘mem’ is cleaned/deleted. Basically, we store the data of the previous sentence and prepare to collect the data for the next sentence. The ‘because’ field will later on be used to link to the newly collected ‘mem’ field. Note that this rule doesn’t generate any output.

Secondly comes the ‘BECAUSEHANDLER’. This builds up the result that needs to be stored in ‘:why’ and calculates the location where this info needs to be stored (in $path). Before actually committing the data to memory though, a check is done to see if it was already known. If so, a different response is given compared to when it is not yet known. In the latter case, the info is also stored.

For the other rules (~have and ~like), we simply declare the $output variable in the output section, indicating that we want to reproduce the output of previous topic.  Note that the use of this $output variable can be controlled in the chatbot’s properties view. When turned off, it will function as a regular variable, and the output of all the patterns will simply be combined. This allows you to select between a simple styled bot or something more advanced.

Finally, as already mentioned, we still need to do some clean-up after the input. Since we have grouped all the mid-term memory in 2 fields: ‘mem’ and ‘because’, cleanup becomes a little simpler (Note: sometimes the ‘because’ part doesn’t exist, but that’s ok, nothing will be removed in this case):

#bot –= Mem

#bot -= because

I guess that’s about it for now.

Well, we went from simple, straight forward, fire-cracker-leveled patterns to something that’s more akin to ‘rocket science’. The combination of memory, thesaurus and sub-topics might just turn out to be a very explosive mix. I for one, am very interested to see where all this will eventually lead too… Stay tuned.

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

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

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

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

Note: Deprecated!

Most development tutorials start out with an ‘Hello world‘ type of application.  This one doesn’t.  The issue I had was the fact that a neural network is inherently a responsive system, that is, everything it does is a reaction to input.  So, I figured, to illustrate this better, I could show a simple echo application.  It’s just as simple to make as a ‘Hello world’ thingy, but actually does something:
echo back everything sent to it.

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
• in the middle is a list box containing the current conversation: all the text you sent interleaved with the answers of the network.
• 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.
• with a toolbar on top of it containing
  • a button to send the text to the sin.
  • a combo box to select the way the sin splits up the input strings into neurons
  • Some editing commands to cut, save or clean the conversation log
  • a toggle button for turning the speakers on/off

If you make certain that ‘Speaker‘ is pressed and your loud speakers are turned on, you should hear ‘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 other code clusters).

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.  Of 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 variables 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 it generates so the code can be called after all other links were executed.  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 but predictable 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…

Editorial Note: This was one of the first neural algorithms I ever wrote. In fact, it was even used to get the initial engine running. As the core and my skills progressed, it became clear that this little example can actually be written in many different ways, some of which better and faster then this example. As of version 0.6 of the designer, I’ve included an improved version of this algorithm, which uses the minimum nr of statements (I can think of) to achieve a simple echo: 4

• Output(CurrentSin, BeginTextBlock)
• Output(CurrentSin, CurrentTo, ‘ ‘)
• Output(CurrentSin, EndTextBlock)
• Delete(CurrentFrom)

Note: Deprecated!

Despite it’s youth, N²D is already quite a large and rather complex application. Things like this tend to have a steep learning curve.  Of course, climbing a mountain is a lot easier if you have a map and proper control over your equipment.  I am working on the map, tools are up to you though.  There are many ways you can play with the application without actually having to design a proper neural network. Here’s a short guide.

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 databases 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:done).  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.

Update: Aici doesn’t use words that are imported from this data source. I have found the thesaurus tree a bit awkward to use, and more importantly, lots of relations, useful to Aici are missing, while hordes of others remain unused.

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: only valid in image, App has been updated)
• 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 the clusters to which 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

Note: Drawing features have been moved to the next version.

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. Evoker specifications are now done on the same page as the frame elements.
• 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. FrameNet has proven to be somewhat incompatible. You can still view this data, but no longer perform an import.

Note: although frames have expanded considerably since this was written, most is still valid, except where indicated (5th august 2010)

Importing frames

As already mentioned, FrameNet’s data structure hasn’t been found very useful in the creation of Aici. Frame format definitions have drifted since, so import is no longer available.

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.