Showing posts with label nodes. Show all posts
Showing posts with label nodes. Show all posts

February 8, 2015

Cleaning Up The Map

With the node map, running a function may or may not be very taxing. But even if it's not, excessive use of these small functions do build up. The node map has no actual idea how the functions operate. It only know that the functions do operate, somehow, and some return data, while others don't. Certain ones will actually help the node map achieve it's goal, while others will just process data. It is important to try and reduce the size of the map by removing unnecessary uses of functions. (Such as having 13 functions processing a line of data that goes no where, is completely useless. To remedy this, the node map is designed with a "cost". The idea is to find the shortest path, sort of speak. When giving a function to the node map, a cost would also be supplied. This cost would explain to the node map how extensive it is against CPU. A function which just adds two numbers is very simple, and can be called many more times then say, a distance formula. So the add function would have a much lower cost then the distance formula. Here's how these costs are counted:

The sum of each cost of all functions on the map is collected. Next, the "fitness" of each trial is collected. The sum is taken away from this number, and the fitness continues down it's path. By doing it this way, the node map will take function cost into account, and only use functions which help it reach it's goal better then the amount of power it would require at it's current state. If a function is just sitting there taking up space, it is just draining the fitness. The node map will catch on to this, and remove the useless function instance.

February 7, 2015

Node Map Learning, and Other Learning Functions

Now, node map learning is functional, and is capable of learning on it's own. Though, through the trial-and-error-like method of learning, any function that has non-static data could screw up the whole learning process, right? Surely something as constantly changing as another learning function would slow all learning to a crawl, forcing the node map to take many more passes to travel the same distance, right? Well, yes and no. Though this logic is correct, to an extent, it actually would really help the AI.

The best way to think of this is like a business. The AI represents the entire company. The node map is the CEO of that company. Each function you hand the node map is another employee type working under the CEO. The types in this case are not actual employees, but are "job titles" which can be filled by multiple people, or simply not used at all. The CEO's job is to get the business operating as well as possible with only these job titles and no more. The only thing the node map (CEO) is able to do is choose where in the company to put each job title. So when the process first starts, he'll look at things, and make logical guesses; passing data from person to person. The thing about learning algorithms in this: they are adaptable. Employees like this have no special talent in a single field, which is difficult for the company to find them a position, but they can adapt to any position, given enough time. Like a business has managers, and people working below them, and other managers, and even more people working below them, node maps can be nested. All forms of learning algorithms are able to be placed inside of a node map and nested. Though, how these are nested is up to the node map.

As stated above, a potential issue with using functions that operate in a non-static manner are likely to throw off the node map's calculations. This is true, and will always slow down the node map's learning curve. In the example of a business, the CEO is putting different people in positions everywhere, where they function poorly. So it moves them. This repeats, a lot. And because a learning algorithm can only learn if it is not moved from it's current position, the curve only has a change to grow when the node map is focusing another another area, instead of the learning algorithm. When the node map places a learning function higher up in the chain, then if has a less chance of being changed, and thus given a much larger chance to learn and grow.

At this point, all of the functions and learning algorithms, including the main node map, are all attempting to work together in order to master their environment. Each one will often trip over each other, or misread data from each other. But, they are help each other. A single algorithms success significantly improves the success of the others. A single algorithms failures can be patched by the others. It is important to use learning algorithms inside a node map, because of this. It may slow down things at first, (by a lot) but it really speeds things up in the long run, and gives the node map much more flexibility.

February 2, 2015

Node Map Learning


Artificial Intelligence is an amazing topic. The whole concept of a computer program learning about it's environment and adapting to it is amazing. I've always loved AI, and have made many attempts to reproduce it. Though I have run into numerous problems along the way. Mostly due towards my lack of knowledge on the subject, and because of the ridiculous amount of work involved to make such a program. Though this is to be expected. AI is not a simple subject. There's so much involved in it, that it's almost necessary to use large teams to design anything of a decent scale. Though it can be done. So why don't we have AI around us commonly if it possible? Well, in a small sense we do. Neural Networks for example, are used at banks to help read off hand writing into computer text, and can do so with over 99% accuracy. But this isn't the type of machine learning I am referring to. What about emotions? Self set goals? These things are possible, and have been created in several instances. But the design behind them almost seem primitive compared to even small animals. This is because even though we have many different algorithms to aid in machine learning, they all have one thing in common. They are slow. It will often take many, many, many passes before the computer finally gets anywhere logical. Yes, in a sense the human mind is the same way, taking the first several years of our lives to learn about how to interact with the world around us. But we can't wait that long. For a computer, an environment on a scale such as ours would take almost centuries to understand, and lots of storage space. Not to mention a ridiculous CPU to calculate decisions in real time. Resources we don't have to spare. That's why AI is such a largely studied field. It's constantly coming up with new ways to speed things up, and make it more efficient. That's why I'm here. I proposing a new type of learning method which I hope will make learning on a mass scale much easier. Though I do not fully understand every part of the algorithm yet, I hope to keep fleshing it out more and more over time. This information right here is a basic summary of the algorithm, rather then any detailed math behind it.


The Node Map Learning method is machine learning concept which is hopefully better at understanding much larger and more complex environments then regular algorithms such as Neural Networks and Genetic Algorithms. It works by basically creating it's very own node map, (which functions similar to a program's code, shown right) then filling this node map with many, many functions. Anything that can be given to it. This includes stuff like distance between two points, sorting a list, adding numbers, and of course, actual functions for interacting with the environments. The AI takes all this data, and tries to organize it into a complex tree of data processing to work with such. The tree is constantly changing and evolving. Some of the functions given to the AI might be things such as Neural Networks or Genetic Algorithms, in which case it would also use these functions, and as the AI operated, would also learn to make better use of these functions. One last thing to note, is that each limb of the tree, (the data that comes out of functions, and gets thrown into other ones) must have a "type" assigned to it. Such as "number". This means that a function which accepts 1 input in the form of a number can only accept data that is assigned as a type of number. Data types can extend other data types. Such as "integer" would extend "number". Thus, all integers can be used as numbers, but not all numbers can be used as integers. The tree grows constantly as well, becoming more and more complex as needed. This process occurs in a similar method to genetic algorithms. The AI will semi-randomly (see paragraph below) start testing out different tree designs by adding, removing, or replacing branches on the tree. If the new design functions better, use that tree instead. If not, revert to previous tree. This process continues infinity, until there is absolutely no better way of designing the tree, without completely remaking it.

It chooses a base design by randomly creating X number of completely random tree designs initially. (X is determined by the complexity of the environment, though is usually around 100 or so. Though can be much higher for intricate environments.) Then it tests all X concepts, and looks for patterns in each one, and compares these patterns to how well it did. For example, the AI may test 250 designs, and looking at the designs, trees the used the pattern "Function 1 > Function 2 > Function 3 and 4" tended to have better results, while trees that use the pattern "Function 1 > Function 4" seemed to function very poorly. Taking all the patterns into account, it designs a new tree a sees how it functions. Constantly testing it, changing it, and making it better. Each and every new tree that is tested is broken down into a list of patterns and given a numerical value based on how well it functioned. This builds up after a while, and eventually will give the AI a very clear idea of what kind of designs work better then others.

This is my concept. I hope to have a working proof of concept out later. Thanks for taking the time to read this, and follow to keep updated. I will be posting more on the subject soon.