I thought I’d write something down on how I see things progress from here on. No dates and times, just a general idea of what I have planned for the next release (version 0.3), so here goes.
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).
Jan this is working out really great.
A while ago I was reading the book about Persuasion of humans (http://www.amazon.com/Influence-Psychology-Persuasion-Robert-Cialdini/dp/0688128165). The author presented a psychological idea that people use too make decisions. We do not rationally evaluate all the steps of a possible decision tree but instead we try to find a short cut based upon a certain trigger.
E.g you see an expensive product and immediately associate this with “good”: overtime, through experience and teaching, you’ve learned this kind of shortcuts because they often prove to be really valuable. (of course, marketing people can misuse this trick by raising the price of an item and hence making it more ‘qualitative’).
couldn’t you implement this kind of algorithm that scans the whole stack of possibilities and limits the amounts of current treads by eliminating some paths? What you’ll end up is a more boring engine but one that is predictable and faster
Link | September 30th, 2009 at 06:54
Yes, this is actually the easy part, it’s mimicing the less intelligent behaviour of humanity: simply recording events from the outside world and replaying them without interpretation (you would not believe how common this behaviour is and how often we do this). In fact, this is already (partly) implemented, in the scanner demo. I think the ‘understanding’ as we know it, is nothing more than the recognition of a set of flows and/or frames, which is what the scanner demo does. To get the processing time down, it also uses a lot of shortcuts, which are defined on the flow items. For instance, in the flow definition, an integer is defined as a sequence of digits without anything in between, while a double (float) is defined as a sequence of digits, followed by a [ , | . ] followed by a number of digits again. Recognising this in the input, causes a LOT of splits (each digit has 3 possible paths: for an int, the front of a double or the back of a double, so 3 splits for each digit). Some are required, for instance, the point doesn’t know if it’s the end of a sentence that has an int at the end, or if it is the middle of a float, so it creates a split that will be resolved once the section after the point is interpreted. But the second series of digits in a float for instance, they know exactly what they are, since the first digits and point have already been found, so the shortcut says that there is no split required for this, but instead it instructs the algorithm to take the path that says it’s the end of a float. This idea can be used on any kind of flow/frame, using the same already implemented algorithm (only the flows and the shortcuts need to be defined).
Auto creation of the shortcuts is the hard part, since ‘new’ links need to be created for this, based on the interpretation of already existing links, through an alghorithm. This hasn’t been programmed yet. I think it requires a new algorithm, that compares the new imput and it’s surrounding variables with something else. the output of this algorithm would be a series of new links that form the shortcut.
Link | September 30th, 2009 at 09:42
By the way, I figure that, for humans too, creating the correct shortcuts is actually the tricky part. As usual, there are many ways of doing this, and I suspect most people often take the easiest way for creating those links: simply recording from others, which is probably how I will be doing it initially.
Link | September 30th, 2009 at 12:19