|
http://www.compsim.com |
Frequently Asked Questions |
Question: What is the "underlying technology" that defines KEEL?
Answer: There are three concepts that define KEEL Technology (all covered by Compsim patents). Before explaining the three concepts, it is important to understand the focus of the technology. KEEL was created to capture and package human-like reasoning (judgment) such that it can be embedded in devices and software applications. In humans this is a right-brain analog process that focuses on the interpretation of "values" for data items and the balancing of interconnected "valued items". It is the human's ability to exercise reason and judgment that has separated humans from computer programs in the past.
The first (and most fundamental) concept in KEEL provides a way to establish "modified values" for pieces of information. To begin with, a piece of information will have a potential value (or "importance"), just by its nature (what it is) and the nature of the problem being addressed. This piece of information can be supported or blocked by other pieces of information (driving or blocking signals). For example, one might have a task with a series of pros and cons. Neurons in the human brain have Exciting and Inhibiting Synapses. The importance of the task is modified by the pros and cons to determine the "modified value" of the task. KEEL Technology uses a "law of diminishing returns" to accumulate driving signals. It follows this with another "law of diminishing returns" to accumulate the blocking signals. Blocking signals take precedence over driving signals. In control systems this means that emergency stop will override all accumulated driving signals.
The second concept for KEEL technology is that we are (almost) never dealing with independent accumulations of information. Individual inputs may impact different parts of the problem domain in different ways. Inputs may cause the importance of other pieces of information to change. Information accumulated from the integration of one set of inputs may impact how other inputs are interpreted. So the second concept is that KEEL provides a way for information items to functionally interact with other information items. A set of functional relationships are provided that allow linear and non-linear relationships to be executed. Essentially, we have created the functionality of an analog computer.
KEEL "engines" are functions or class methods, depending on the output language selected. Within the KEEL Toolkit there are two optional processing methods available: The first is an "iterate until stable" approach. The second approach pre-qualifies the design and creates an optimal processing pattern for the worst case scenario.
The third concept that defines KEEL is the dynamic graphical language. Because we are commonly dealing with subjective designs (from a human standpoint), there are several advantages of dealing with graphical language. The first advantage is that the designer is learning how to describe his/her system while it is being designed. The designer can stimulate individual inputs and "see" the information propagate throughout the system. The designer can "see" the impact of change immediately. The designer can create 2D and 3D graphs and see how items interact. A KEEL "engine" is automatically created and executed behind the scene as it is being developed and tested using the dynamic graphical language. When the design is complete, it can be exported as conventional C, C++, C++ .NET, C#, Java, Python, Visual Basic 6, Visual Basic .NET, Flash, and other languages for integration with the rest of the production system.
It is also important to understand that KEEL models are equivalent to formulas. They are explicit (traceable by looking at the dynamic graphical language and observing how individual inputs propagate through the system). Designs can easily be extended by adding new inputs to the system and functionally linking them to other data items. We suggest that rather than dealing with complex mathematical formulas, that the models are much easier to understand by viewing and interacting with the "KEEL dynamic graphical language".
One question that has been asked several times: What came first, the KEEL execution model (concepts 1 and 2) or the KEEL dynamic graphical language (concept 3)? The answer is that concept 1 came first as we created a model for integrating pros and cons when addressing common structured business problems. Then the functional integration (concept 2) and the dynamic graphical language (concept 3) came together as we began to address dynamic, non-linear, inter-related, multi-dimensional problems that we found would be necessary to be solved for embedded autonomous systems.
While KEEL has been developed to provide human-like reasoning that can be embedded in devices, it can also be used to describe the human-like behavior of physical systems. Consider, for example, the degradation of physical systems that seem to have a mind of their own as components wear out and degrade over time or perform differently as they heat up. All of these non-linear relationships can easily be modeled and simulated with KEEL. Once one understands "how" KEEL is used to create and execute this processing model, we often suggest that the user forgets "how it works" and starts "thinking in curves". In this way, the designer thinks about the (often) non-linear relationships between information items, not how the information is actually processed.
Finally, we would suggest that the only way to get an in-depth understanding of the KEEL underlying technology is to work with it directly at a KEEL workshop. In the 2 to 3 day workshop you will gain an understanding of how to create and debug KEEL cognitive engines, how the KEEL engines process information, and how to integrate the engines into systems.
Question: Why do you differentiate Rules from Judgment?
Answer: Rules are (or are supposed to be) explicit. They define explicit behaviors that are to be produced in response to explicit circumstances. In computers rules are commonly described with IF | THEN | ELSE logic or CASE statements. Judgment, on the other hand, is a human characteristic focused on the interpretation of information in order to decide how to apply rules. It commonly requires "balancing" of (sometimes conflicting) alternatives. In human terms, judgment is considered a parallel process performed by the right hemisphere of the brain. KEEL provides the ability to exercise these parallel, judgmental functions on a sequential processing computer.
Another viewpoint was expressed by Dr. Horst Rittle in the 1970s. He coined the terms "tame problems" and "wicked problems". He indicated that with "tame problems" one could write a formula and obtain a "correct" answer. With "wicked problems" one hopes for a "best answer". His field was city planning. He was suggesting that it would be difficult or impossible to write a formula to control a city. We would extend this concept by saying it takes "judgment" to determine how to allocate resources to operate a city.
With KEEL we are allowing devices and software applications to take on some of the judgmental reasoning functions that have historically been impractical to implement. We would suggest that one additional requirement when automating these judgmental functions is that they must be 100% explicit and auditable. One doesn't want to mass produce devices that exercise poor or unexplainable judgment. With KEEL, all decisions and actions are 100% explainable and auditable.
Question: Unless I am missing something, it appears you have implemented an analog computer on a digital computer – that is, you can accept various inputs, scale them, combine them, and provide a scaled output. Let me know what I missed on the engine itself. For example, I didn't see any indication of the ability to support non-linear inputs (for example, thermocouples) or to generate non-linear outputs. I'm trying to figure out what is unique about this.
Answer: Yes, you are totally correct about KEEL representing the functionality of an analog computer. KEEL is intended to model human judgmental decision-making, which is pretty much an analog process. The very small memory footprint of a KEEL "cognitive engine" makes KEEL-based solutions available to some embedded applications, where other approaches would not be practical. Because we are interested in analog “decisions” or “control applications” we can easily handle non-linear inputs and create non-linear outputs (sample graph below). In general, if you already have a specific formula that calculates a correct answer for every input condition then KEEL would probably not be appropriate. On the other hand, if you need to create a system that exerts "relative control" in a dynamic or complex environment, then KEEL might be appropriate. The KEEL toolkit allows the design to be created without writing conventional "rule based" code. The engines created from the design can be integrated into existing applications with very little effort. One other note: KEEL actions or decisions are completely explainable and auditable. This differentiates them from neural nets and fuzzy logic.
One characteristic of a real analog computer is that all inputs are handled simultaneously (or at least determined by the propagation delays through the circuits). Commonly, digital computers process information sequentially. With KEEL, the processing of information is handled within what we call a "cognitive cycle". A snapshot of the system (inputs and outputs) is taken at the beginning of the cognitive cycle. Then, within the cognitive cycle, the system iterates the analytical process until a stable state (of all variables) is achieved. (This equates to the propagation delay through an analog circuit.) Then the cognitive cycle is terminated so the outputs can be utilized.
Think of how a human might make a judgmental decision between a number of inter-related alternatives. The human integrates pros and cons of each alternative and determines how potentially conflicting objectives are met. The human may allocate resources across several of the alternatives or apply all resources towards one alternative. The human will be balancing each alternative against the others to determine how to proceed. This is an iterative process for the human because the selection of any alternative cannot be done in isolation. All alternatives must be considered together. KEEL-based solutions perform the same way. The entire system is processed during the KEEL cognitive cycle.
ALSO: While an analog computer "could" be designed such that unstable conditions could exist, the KEEL design tools highlight and disallow these designs.
The 3D graph above shows the integration of two non-linear functions (2 in and 2 out). With KEEL we are commonly dealing many-to-many relationships that cannot be graphed in just 3 dimensions. The KEEL dynamic graphical language provides another way to "see" and "test" these types of relationships.
Question: How does KEEL differ from Fuzzy Logic?
Answer: KEEL has often been compared to Fuzzy Logic. Both KEEL and Fuzzy Logic can support relative, judgmental, analog values. Fuzzy Logic, however, is difficult to explain or audit in human terms. Fuzzy Logic is based on the concept of linguistic uncertainty, where human language is not sufficient to exactly define the value of words: cold, cool, warm, hot… Geometric domains are used to describe values: the degree of cold is described as participation in the cold geometric domain. Geometric domains are combined to approximate what the data is supposed to mean. The process is called fuzzification. There is art in selecting the appropriate geometric shapes that are used in Fuzzy Logic.
KEEL, on the other hand, defines information with explicit values and explicit relationships. KEEL supports the dynamic changing importance of information, which allows the reasoning model to change with the environment. Complex relationships can be traced to see their exact impacts. It is easy to see and audit the reasoning process. The graphical language can be animated to show decisions and actions at any point in time. This makes KEEL an appropriate choice when the decision or actions of the system need to be explained and understood.
Question: How does KEEL differ from Artificial Neural Nets (ANN)?
Answer: While both KEEL and Artificial Neural Nets support 'webs' of information relationships, ANN webs are taught by showing them patterns to recognize. When an ANN-based system makes a decision, it is based on the interpolation between points it was taught. ANN based systems cannot explain why they make decisions. Because they are taught patterns, they have problems recognizing situations that they have not been taught. In other words, they do not react well to surprise situations. Since ANN based systems may not be able to explain why they do what they do, the developers of ANN-based systems may be subject to liability concerns in safety critical systems (if they make the wrong decision due to insufficient pattern training). When new information items need to be included in a neural net system, the entire training phase may need to be repeated. This may be a significant cost and time-to-market concern.
KEEL webs model the judgmental reasoning of human experts by defining explicitly how information items are valued and how each information item interacts with other information items (KEEL Technology is an "expert system" technology). Because KEEL webs are designed with a set of visible graphical rules, every decision / action can be explained and audited. KEEL based systems are also easy to extend without starting over.
Question: How would you compare KEEL to probability based solutions (Bayesian / Markov / etc)?
Answer: Probability based solutions work well when you can obtain good statistics. This might be the case in static situations, like diagnosing disease in patients where normal values are gathered across a large number of tests. However, it is often difficult to get good statistics, especially on non-linear systems composed of multiple inputs. With KEEL, one uses common sense to define how information is to be interpreted. For example, defining concern about running out of fuel is not really a probability problem. With KEEL, you would model how you interpret your concern for running out of fuel in your decision to pursue some goal. With KEEL you model how you want the system to process information. You do not create answers to specific problems. This way you create a robust solution that can solve a number of problems, not just an individually stated problem.
The thought process for a probability based system focuses on the best way to solve a problem, while with KEEL, one models what the system will do, given a variety of inputs and options.
Sometimes there is a risk in probability-based systems for them to be corrupted by incorrect or misleading probabilities (overwhelmed with too much data and lack of auditability). There may be too much "trust" in the data.
Question: How does KEEL differ from conventional AI Expert Systems?
Answer: Conventional rule-based systems use approaches like Forward and Reverse Chaining. Reverse chaining systems start with a solution and work back through all the data to determine whether the solution was valid. This approach has worked for simple decisions when some data might be missing. Forward chaining systems start with the data and try to determine the solution, but suffer from missing information components. Rule-based systems supplied the concepts of confidence factors or certainty factors as part of the math behind the results. These types of systems were commonly used to evaluate static problems where the rules are fixed and the impact of each rule is stable. In many real world decision-making situations rule based systems quickly become complex and hard to understand. Computer programs based on rule based systems are usually expensive to develop and difficult to debug. Furthermore, they can be inflexible, and if changes occur, may require complete recoding of system solutions. Bayesian analysis is another approach that focuses on statistical analysis and may be appropriate when there is an opportunity to gather a strong confidence in probabilities. This approach may not work well in dynamic environments.
KEEL defines rules by identifying information items with a level of importance. Each information item can impact other information items to create a web of information. Components of the information web can be exposed as outputs of the system. The 'expert' (designer) defines the information items, defines how important each is, and defines how they inter-relate, using a graphical toolkit. This map of information defines the rules. Forward and reverse chaining models can be created in KEEL. But this is done without textual programming. The graphical model allows complex situations to be modeled rapidly and tested before being translated to conventional code. In some cases, KEEL systems can use information derived from Bayesian Analysis, Fuzzy Logic, ANN systems as well as sensors, database driven solutions, or human input.
Question: How does KEEL differ from scripted AI languages like CLIPS?
Answer: They are completely different for several reasons. First, CLIPS is a toolset and a language. KEEL is a technology that incorporates a processing engine architecture, as well as a toolset and language.
CLIPS is like a number of "scripting" languages that utilize text based "rules". It has the same fundamental IF | THEN | ELSE structure of most conventional programming languages. These languages support a number of services that support what we call "Conventional AI" applications. It appears that one programs CLIPS like any other "conventional" programming language, meaning that one uses an "editor" to write the script. This can then be compiled into an application. At the machine level, one is probably left with (potentially large) methods that are described with the script. Like any scripted computer language, they may suffer from typing errors as well as logic errors. Debugging these applications is often a time consuming activity.
CLIPS is completely different than KEEL. We don't suggest that there is anything wrong with scripted languages or conventional programming tools. We suggest that these scripted languages map to a human's left brain activity. KEEL focuses on "judgment and reasoning" that, we suggest, are more image processing (right brain) functions, than static rule-based functions. KEEL is more like differential calculus, except that it is done graphically rather than with scripted formulas. There is no "text" in KEEL, except for naming data items and the "names" are not used at all in the logic. This means you cannot have a "typing" error. You only have to deal with the relationship issues.
With KEEL one is designing systems where the solution is the analog (relative) control of multiple variables. KEEL focuses on solving dynamic, non-linear problems, where the importance of information items change continually. It addresses inter-related problem sets, where each solution impacts other problems within the same problem domain.
With scripted languages the designer is thinking in terms of defining "rules" of how the system is to operate. It is common for a designer to consider a rule from a static situation. With KEEL, the designer is thinking about how information items interact in the solution of a problem. The designer thinks of dynamic, non-linear relationships (curves). The designer is observing the system balance alternatives. The designer then determines if the performance is appropriate.
Question: Why do you suggest there is a different "mindset" for the developer?
Answer: We suggest that concept development in KEEL is different from other paradigms. For example: developing a simple computer program: The "programmer" has an idea or is given an idea for a program. He/she may or may not outline the program structure using some kind of graphing technique to show data flow. Then coding begins. The programmer is involved in thinking about how to structure the code to make things happen. The programmer's mindset is focused on symbol names and language instructions and how to use the computer instructions to accomplish the task. Depending on the program, the programmer may build a user interface to test the program. Only then can anyone evaluate how well the programmer accomplished the task.
With KEEL, the "designer" is considering many things when creating the application. The designer is considering:
Using KEEL, all of this is done graphically, so the designer is always involved in the problem (not how to create "code" to express the problem). The designer is constantly "testing" the design as it is created to see how it reacts. When the model is complete, it can be given to the "programmer" to integrate it with the rest of the system.
With KEEL, one is commonly dealing with complex scenarios that many times have non-linear components (the changing importance of information items based on time, space or simply the relationships between other information items). Many times the problems have never before been characterized because of their complex inter-relationships. This means that the designs evolve as they are being developed and the designer clarifies his or her understanding of the problem. The KEEL "dynamic graphical language" greatly accelerates this process. Changes can be made and reviewed immediately. There is no need to translate the idea into "code" where the code has to be debugged before it can be evaluated.
For this reason, we suggest that domain experts (not necessarily mathematicians or software engineers), can create and debug the models for these non-linear systems, greatly reducing lifecycle costs to the user/organization.
Another benefit is the visibility of the solution. If these complex behaviors were encoded using common IF | THEN | ELSE logic, the result would likely be a large monolithic code segment that would be difficult to understand. With KEEL, the model is easily visible where inter-relationships and the instantaneous importance of information can be seen while designing the system. Auditing of decisions and actions is easily available. With KEEL's "animation" capabilities, one can even monitor the reasoning capabilities of systems while they are in operation.
Question: How does KEEL compare to curve fitting approaches?
Answer: A common practice is to measure the real world and attempt to create a "formula" from the data accumulated.
This approach is used when there is little (or no) "understanding" of the problem. By "understanding" we mean that an expert doesn't know enough about the problem to describe it in a formula. Data is used to derive a synthetic understanding. This approach may use some kind of curve fitting (pattern matching) approach. One risk to this type of approach is that the measured data may be subject to external influences that may not have been measured or accumulated in the dataset. This results in "garbage in - garbage out" types of problems. If this happens, one may not even recognize that there is a problem. It is often difficult to trace back to how the data was gathered and accumulated.
With KEEL, one uses a human's understanding (even if it is limited), to model the system. The dynamic nature of the KEEL language helps the human test the model under various scenarios by stimulating inputs and observing the response. This is an iterative process as the human fine-tunes his/her understanding of how the information is to be interpreted under varying situations. One could say that it is even an evolutionary process, since the models are likely to be refined over time to take advantage of new information items and new control variables. KEEL focuses on creating models that will get better and better over time. The human "learns" how to describe his/her understanding as the models are being created and refined. The result is a visually explicit model that allows one to "see" how data items are interpreted at any instant in time. This visually explicit approach allows the models to be challenged. This is all part of the evolutionary process. In some cases, KEEL-based systems can be designed to evolve on their own. These systems can use a variety of techniques to incorporate adaptive behavior.
Policies (for humans or for machines) described in KEEL are explicit, compared to those described with a human (verbal or written) language, where most terms are subject to individual interpretation.
Question: Does KEEL learn?
Answer: The term "learning" is subject to many interpretations in the cognitive domain. We would say that KEEL technology adapts, rather than learns. We would suggest that a system that learns will have to be able to automatically accept new information (inputs) that it has never seen before and automatically determine how that new information relates to and impacts all of its existing information. KEEL technology is an expert system technology that requires a human expert to define the reasoning model. The human expert must define how each input relates to all the other pieces of information and what outputs are to be created. In this way, the human expert defines how the system will adapt to changing inputs. The human expert is in control.
We would suggest that a true learning system will decide, on its own, how to integrate new information sources. A human might be termed a true learning system. At birth, the human knows nothing (from a judgmental reasoning standpoint). The baby is exposed to new information and evolves to adulthood. Some adults turn out good, and do good things; and some turn out bad, and do bad things. We would suggest that this evolutionary process is not what we want in machines that are mass produced. There would be the potential of creating devices that evolve differently and perform differently. This could make them uncontrollable.
Auditable Teachability: We would suggest that KEEL Technology provides services to create "teachable" systems. A number of services and techniques are built into the KEEL Toolkit that provide system engineering tools to support systems that need to be periodically updated and extended.
There may be applications, however, that can benefit from the incorporation of true learning abilities. It may be possible to use KEEL engines as policemen to oversee this type of system. This is an area of potential research.
So our answer to the question as to whether KEEL learns, is NO. KEEL can adapt, if that is what the expert wants it to do.
Question: Is KEEL scalable?
Answer: KEEL is scalable in multiple ways. First, a single KEEL "engine" (the encapsulation of a KEEL design), is not limited by the number of inputs and outputs. We say, somewhat tongue-in-cheek, that a single KEEL engine can address all the problems of the world with 3K of code and some relatively large tables. Realistically, however, we just say that the size of a KEEL "engine" is just unlimited. In some cases, it is more appropriate to break "large" problems into manageable partitions. If these "chunks" are to be processed on a single microprocessor (computer), then we have system integration tools that will automatically wire multiple engines together (so they can be compiled together).
On the very small scale, KEEL "engines" are optimized to the extent that services that are not required by the cognitive design are left out of the conventional source code. This addresses the need for embedding cognitive solutions in very small devices (e.g. sensor fusion). This may reduce the approximately 3K even further.
We also say that KEEL is architecture independent. Here we are talking about how KEEL "engines" are distributed. Because KEEL engines operate independently (at any instant), they operate just like a collection of humans, each with their own responsibilities. Some kind of network infrastructure can tie them together to allow them to share / exchange information. Each entity (human or KEEL engine) uses the information available at the time the information is processed. While we do have tools to integrate multiple KEEL engines together on a single microprocessor, we do not supply tools to integrate information across a network. There are various commercial and proprietary solutions to handle this infrastructure and KEEL should be able to be integrated into any of them.
Question: Why do you call KEEL a "technology" rather than "tool"?
Answer: We define technology as a "way to do things" (as in a technical approach) and a tool as something that "facilitates the implementation of the technology".
We call KEEL a 'technology' because it is more than just a tool. It is a new way to process information. A MIG welding torch is a tool. With it, you can create a wide variety of mechanical structures. The KEEL Toolkit (with the dynamic graphical language) includes a set of tools used to create KEEL 'Engines' which encapsulate the new way to process information. The KEEL technology 'patent portfolio' covers the basic algorithms, the architecture for the KEEL Engine, and the KEEL dynamic graphical language. Licensees to KEEL Technology get access to the toolset and the right to embed the KEEL Engines in their devices and applications. Licensing KEEL Technology would be like licensing the right to use a MIG welding torch to build mechanical structures composed of MIG welded components. NOTE: A MIG (metal inert gas) weld is a specific type of weld. A KEEL Engine processes information in a specific way.
Question: What do you do if you don't think your domain experts "think in curves"?
Answer: While we suggest that when one designs a KEEL system, one "thinks in curves" (because we are commonly focusing on non-linear systems); one almost never starts with this level of complexity. Non-linear relationships between data items are usually an evolutionary enhancement to a design. The process of developing KEEL solutions is to first identify the outputs (or the items that can be controlled). Then the inputs to the system are added (the items that contribute to controlling the outputs). Then the linkages between items are added with wires. These relationships are almost always linear at the beginning. Remember this is done in seconds as "positions and arguments and wires are just dropped on the screen". Then (maybe) the importance of different inputs is adjusted. Maybe several inputs need to be combined before controlling another output. KEEL designs are extended. The designer drops functionality into the design and tests to see that it performs.
This is an iterative (design, test, modify) development process. Non-linear relationships are gradually incorporated into the design. So, while we suggest that domain experts "think in curves", this is just a natural progression of the design refinement process. It is also easy to integrate and test these types of relationships. When one goes through KEEL training, the concept of "thinking in curves" is taught so the user gets experience creating these types of systems.
In some cases, linear or state change control is satisfactory for production systems. But in other cases, as the design is refined, it is obvious that some kind of non-linear relationship (curve) might be appropriate. These can be merged into the design from the library of curves supplied with the toolkit, or they can be created by the domain expert and integrated into the design.
Question: If a KEEL-based system is based on a human expert's opinion, what do you do if there is more than one expert and they disagree?
Answer: It is true that the rules developed with the KEEL Toolkit mimic how an expert models the reasoning process. When there is more than one expert, there is the possibility (likelihood) that there will be some level of disagreement. However, a company or organization or individual still has to take on the responsibility of deciding on a course of action (which expert to trust). The same is true with a KEEL design. Someone still has to take responsibility of choosing which expert is correct, or at least deciding on how to integrate the opinions of both into a final decision or action.
While KEEL Technology will not make that decision for the system designer, the graphical language exposes all of the reasoning. When experts describe their decision-making reasoning using the English language (or another verbal or textual language), one is usually left with only a loose definition of the reasoning that was used. In other words, the English language is not very good at describing dynamic, multi-variable, non-linear, inter-related problem sets. This is especially true of safety critical systems or manufacturing systems. This is why these types of systems are commonly described with conventional computer languages.
So our response to the question focuses on why it is necessary to describe a human expert's judgmental reasoning with a graphical language. This graphical language is explicit. It can be reviewed, tested, and audited. In this manner, when there are disagreements between experts, the model can be investigated and refined over time.
Question: How can you use KEEL if you don’t know what the outputs and inputs are?
Answer: In complex problem domains it is common that you don't know all of the inputs and outputs up front. It is likely, however, that you can identify at least some of the outputs. These will be the control variables that you will use to respond to your problem domain. Given the output variables you know, you should be able to identify some potential inputs. A key attribute of KEEL Technology is that it is so easy to add inputs and outputs to the model using the KEEL "dynamic graphical language". This "ease of use" characteristic should help you "think" about how the inputs and outputs collectively inter-operate in your problem domain.
Another characteristic of "solving" complex problems is that the solution may evolve. You may add new sensors, whose data can participate in the solution. You may identify a new "symptom" that impacts the overall goals of the system and needs, either to be controlled or taken into account.
The KEEL dynamical language helps one think about solving the problem and gives you the opportunity to stimulate inputs and visualize the results. Addressing these kinds of problems with KEEL Technology (language and execution environment) is much simpler than attempting to describe hypothetical problems to a mathematician and getting his/her solution implemented using conventional software techniques, where it can only then be tested.
In summary: When you are not sure of the inputs and outputs, it is easy to hypothesize on what they might be and how they might inter-operate with KEEL Technology. When you are comfortable with the results the model can be easily deployed in more advanced simulations and emulations and finally delivered in a product or service. When you have defined and documented your model in KEEL it provides an explicit explanation that can always be reviewed and extended with ease.
Question: How is the concept of "surprise" handled by KEEL Technology (compared to ANN)?
Answer: One of the problems with ANN-based (Artificial Neural Net) solutions is that they do not react well to surprise. ANN-based systems are pattern matching systems that are taught. If they have not been taught a particular pattern of inputs, they will just interpolate between what they have been taught and create an answer. With KEEL, one describes how to interpret information, not patterns. There is no interpolation between taught points.
The concept of "surprise" can be decomposed at multiple levels. First, one can encounter scenarios with a known set of inputs combined in unexpected ways. With KEEL, one can examine the system and observe how it was interpreted. If changes are needed they can easily be made. With ANN there is no way to know "how" an answer was derived, so it can only be addressed with increased training.
Another way of decomposing "surprise" is for a system to encounter new variables that impact the problem domain that were never before considered. This would be like a "person" walking down the street and a Martian appeared from behind a bush. An ANN-based system will respond, although it is now clear how. We have some ideas of how one might build a KEEL-based system that would know how to handle this kind of surprise and would like to discuss this with selected organizations. The abstract "Considerations for Autonomous Goal Seeking" identifies the project.
Question: Isn't the KEEL graphical language just another way to create a formula?
Answer: It is true that the KEEL graphical language is translated into conventional computer languages for processing, which could possibly be expressed as a textual/numeric formula. However, when the problem is a multi-variable, multi-output, inter-related, non-linear, dynamic system, the development and testing of such a numeric formula (using the common definition of a mathematical formula) would be difficult (very difficult)! Using the KEEL graphical language and the dynamic support built into the KEEL Toolkit, these systems are relatively easy to construct and test. Also, because the KEEL language can be deployed into several different conventional languages, it is easy to build test systems (simulators or emulators) to perform extensive system tests before deploying them in production environments. So the answer is "yes" (formulas are created), but because of the complexity of the formulas, they can best be visualized in the KEEL graphical language.
Because another benefit of using KEEL Technology is the ability to audit complex systems, the technology supports reverse engineering of actual actions. By importing snapshots of real-time input data into the design environment, one can "see" the reasoning performed by production applications. This is accomplished by viewing the importance of individual data items and tracing the wires to view inter-relationships.
One additional advantage in the use of KEEL Technology and the KEEL graphical language is built into the KEEL Toolkit. It constantly monitors for unstable situations and warns the designer if such a model would be created. Because KEEL Technology balances information, it would be possible to create a system that would never stabilize (go left - go right - go left - go right....). The design environment watches to insure the designer does not create this kind of system. Should one attempt to develop this type of a system manually (hard coded formulas), additional tools may be necessary to insure that an unstable design is not created.
Question: How does the KEEL graphical language differ from other "graphical languages"?
Answer: Most other graphical languages use wires or arrows to show data flow or logical processing flow between graphical components. The graphical components themselves commonly encapsulate functionality. This is completely different than the KEEL graphical language. With KEEL Technology, the functionality is defined by the wires between connection points on the graphical icons. The functionality defined in this way is explicit. Within KEEL designs, there is no "hidden" processing within boxes. While there is a functional ordering from source connection points and sink connection points (information provider to information user) this is a functional definition rather than a data flow process. The wires define how one data item impacts others. During the "cognitive cycle" all relationships are evaluated. This is similar to processing a formula, where one is not interested in what happens part way through processing the formula. One is only interested in the results of processing the formula. Within the KEEL graphical language the bars represent values, not functions. This is somewhat similar to "microcode" that would be processed behind the scene in a microprocessor during an instruction cycle.
One can also look at most other graphical languages as a decomposition of a design into pieces that can be viewed as separate functions that are processed sequentially. With KEEL the concept is that all items are processed during the same time frame (the cognitive cycle). Order is not important to the outcome and intermediate states are not important as they are not visible to the outside world.
Another view of most other graphical languages is that they can perform (or encapsulate) conventional computer code that has the capability to perform mathematical functions, like 1 + 1 = 2. The KEEL language has no mathematical functions. It has no conditional branch instructions. It can, however, identify the most important value. It does provide ways for one item to influence other items in non-linear ways. Conventional logic (external to the KEEL Engines) is still used to perform mathematical functions. This is similar to left and right brain functionality. Conventional logic is used for left brain functions and KEEL is used to perform (subjective, image processing) right brain functions.
Question: What types of problems are best suited for a KEEL solution?
Answer: KEEL can be used to solve problems
- Where human experts are required to interpret information to make the best decisions or take the most appropriate actions
- Where devices must operate autonomously and make judgmental decisions on their own
- Where devices are required make control adjustments / decisions when human operators are not present
- When repetitive human judgmental decisions are prone to error
- Where trained operators are potentially tricked into overlooking critical attributes
- Where human experts take too long to make judgmental decisions
- When the judgmental decisions of the expert system must be explained (when it is important to know why actions were performed.)
- When it is not economical to develop and maintain straight line code (IF, THEN, ELSE) because the problems are complex (non-linear systems)
- Situations where the environment is dynamic, and the importance of information changes, and the system must react to change
- Where there is an advantage to be able to create one design and execute it on multiple platforms: device, software, web
- Where the small memory footprint of a KEEL solution is an advantage
- Where architectural issues may prohibit other solutions (KEEL technology is architecture independent)
- Where there are many complex models to be created and "ease of use" / "rapid development cycles" are required.
Question: How does KEEL work in a collaborative environment?
Answer: One View of Collaboration: We have had several questions about using KEEL in a collaborative environment. Potentially there are systems of autonomous robots that need to share information and coordinate tactics and strategies to pursue goals.
KEEL Technology does not handle any of the infrastructure duties that move information items between devices. KEEL Engines can be thought of as individual humans with specific domain expertise. Each one operates independently, and at any "instant in time" with whatever information they have at their disposal. Their design (created with the KEEL dynamic graphical language) interprets each of the inputs relative to some set of problems. They can be configured to handle missing or old information, just like humans. If the exchange of information is necessary to pursue group goals, the KEEL Engines should perform just like human equivalents: If new information is provided, that information is used. The new information can be augmented with a trust factor if that is appropriate. The information value can degrade over time if that is necessary. If expected information is not provided, policies can be used to describe what to do (use historic information, use synthetic information, ...). The system designer has the responsibility to manage the sharing of information items by whatever means is appropriate. The KEEL designer (policy maker) creates the policies that handle the information (or lack of information) that needs to be interpreted and acted upon.
Another View of Collaboration: In other cases, the collaboration is between humans. In this case, the value of KEEL is two-fold: First, the English language (written or verbal) is almost always subject to individual human interpretation. It is not explicit. With KEEL, the policies / practices / reasoning approaches can be explicitly described with the KEEL dynamic graphical language and can be reviewed and audited when necessary. Decisions and actions created by KEEL Engines can easily be reverse engineered. KEEL provides a means of explicitly sharing "how information is to be interpreted", even in complex, dynamic, non-linear, inter-related scenarios. Second, there are many times that collaboration is involved in the interpretation of specific scenarios. The issue is weighting individual information items rather than describing how information items are inter-related. In this case, policies can be packaged as KEEL engines that accept input to control the weighting of individual data items. This weighting can then be exposed to show its impact on the overall system of inter-related problems.
Question: Why do you call KEEL a new form of mathematics?
Answer: KEEL provides a way to define functional relationships between information items. Calculus is the conventional method for defining explicit functional relationships. See sample relationships that can be created with the KEEL dynamic graphical language. KEEL allows explicit complex functional relationships to be defined without resorting to calculus or complex quadratic equations.
Question: Is KEEL deterministic?
Answer: The answer is "yes" with some qualifications. First, KEEL Engines (cognitive functions) process all information in what we call a "cognitive cycle". This is accomplished in either of two ways: One way is to iteratively process all inputs until a stable set of all outputs is detected. We tell you the maximum number of cycles this will be for any design. The second way (somewhat faster and somewhat more memory) is for the KEEL Engine to process the data in an optimal way. Again there will a maximum number of lines of code processed.
In the first way, the information is processed faster, when some or all of the inputs DO NOT change.
Thus for any KEEL design, there will be a maximum number of instructions processed. There may be some 'jitter' when fewer than the maximum number of instructions is processed.
There is one way, however, where KEEL would not be deterministic. The development environment continues to monitor a user's design for possible unstable designs. Under normal circumstances the user will want these unstable situations to be detected and rejected automatically. There is a switch that disables this automatic rejection (although the user is still warned of the bad design). If the user chooses to allow these "circular references"; then the design would not be deterministic. For example: B is a function of A; C is a function of B; and A is a function of C. Another example: A person has two bosses of equal rank. One boss tells the employee to go left and the other tells the employee to go right. In this second example, one iteration through the KEEL engine would calculate 'left'; the next would calculate 'right', the next 'left', the next 'right'.....(never stabilizing) We would suggest that designs with these unstable designs are never used. However, the toolkit has an option to allow this instability if you choose, because, in some cases it is educational to 'see' an unstable situation in operation.
Question: Do you / How do you handle temporal data?
Answer: Temporal (time) related pieces of information and distance related pieces of information can be used both directly and indirectly. There is a subtle difference. When used directly they are just like any other data item. Our UAVs executing collision avoidance are using distance information directly to determine how to react. They are commonly used indirectly and are used to control how other pieces of information are interpreted or valued.
Here is an example: Time is commonly used to establish the importance of another piece of information. For example a weather pattern might have very little impact on a decision or action that needs to be made now if the weather pattern won't get here for several days. On the other hand, it may have a significant impact if one is creating plans for an event that will take place when the weather pattern will coincide with the event. Temporal data can be used to create plans or to establish expectations over time.
Time might be used as a qualifying factor for aging data. The older it is the less value it might have. Similarly the impact of a threat may vary with its distance: the farther away the less threat. This impact is probably not linear. Time and distance impacts on decisions and actions are excellent examples of the types of problems KEEL can be used to model. Their impacts are commonly changing as the time and distance changes and decisions or actions need to be adjusted.
Time and distance information components can be used differently in different parts of the same problem domain, just like any other piece of input information.
One needs to remember that with KEEL, we are integrating all pieces of information together at an instant to make decisions and control actions. Some of the decisions or actions can be tactical (immediate) and others can be strategic (planning / longer term related). One designs the system to model how information items (including temporal data items) are integrated for that instant to address both tactical and strategic problems.
Question: Does KEEL require assigning weights to input variables?
Answer: A key component to judgmental decisions is an evaluation of the importance of information. There are several ways to assign weights. First all of our inputs and outputs are normalized to values between 0 and 100 (floating point or integer) depending on your target application.
These weights can be defined externally to the KEEL engine. They can also be scaled internal to the KEEL engine. When combining data items inside of a KEEL engine, a single piece of information may impact different parts of the problem space with different levels of intensity. KEEL handles this as well. Another key point in a KEEL solution is that information can change in importance (to different parts of the problem) dynamically. The concept of importance is critical to many KEEL applications. The importance of data can be set at design time (fixed) and/or it can be changed dynamically based on other influencing inputs.
Question: How does KEEL address probabilistic information and fuzzy problems?
This is a two part question. First, with
probabilistic information, one assumes that statistics and probabilities are
available to be used to interpret the information. Formal statistics are
commonly used as inputs to a KEEL Engine when they are available. The following
example shows a system where two options are considered. In this case the
probability input is through input 0 and the two options are input through
inputs 1 and 2. If the "probability" is set to 50 (meaning equal or 50/50),
then if options 1 and 2 are equal there is an equal probability and either
option is a viable choice. With KEEL, there is never confusion about which one
to choose. It finds the first value with the highest rated answer. In this case
option 1 is indicated with the
icon.
Manipulating the probability input (0) and/or the Option 1 or 2 inputs (which
would correspond to a confidence value or quality of information value), will
allow the system to re-evaluate the information.
The second part of the question (fuzzy problems) is addressed with KEEL's support for non-linear interpretation of data. We suggest that the KEEL language (or another dynamic graphical language) is the most effective way to address soft or (fuzzy) problems. These types of problems are more image processing functions than they are text or numeric formula based problems. They are analog problems and KEEL is essentially an analog system.
Some may feel neural nets may be most appropriate for these types of problems. However, we would argue that these may not foster the development of any real understanding of the problem domain. We would suggest that it is more appropriate to develop an understandable model and refine it over time in order to improve a process. This is especially true in decisions or actions where human safety and significant risk is involved. In these cases, the process must be auditable and it must be correctable if necessary. KEEL provides a system that can be audited, and can be corrected or extended with relative ease.
Question: When you say “small footprint”, exactly what do you mean? Small enough for a PDA? Small enough for a microcontroller based device?
Answer: We have compiled KEEL applications for an H8 microprocessor. Certainly it would work with other 8 bit micros. So it could go in your cell phone and other low end devices. The code created with the KEEL toolkit is the same, no matter how large the application. When I say code, I am referring to the instructions that process the inputs and outputs. KEEL is table driven, so the more inputs and outputs, and the more relationships you have, the larger the tables. So you wouldn't put the knowledge and understanding of the universe in an 8 bit micro, but if you had some kind of memory manager and enough time to analyze the data, you could do it. Time is relative. In our case, the larger the system, the longer it takes to process. We have a memory calculator that will calculate the memory needed for an application, but you have to approximate the design to use it.
Question: What processors can you target - Intel x86 I presume, but what about the processors typically used in WinCE or Palm devices? Is there an OS requirement?
Answer: The KEEL Toolkit can produce C, C++, C++.NET, Java, MATLAB/Octave, Python, Visual Basic Version 6, VB.NET, C#, Adobe/Macromedia Flash ActionScript code (Version 2 and 3), PLC Structured Text, JavaScript, and VBScript. We are not dependent on an OS (except for VB and VB.NET) which run on Microsoft OS. We are also not dependent on any particular architecture. In a command and control system for the military the KEEL engines might be distributed across a network. In an automobile, we will most certainly be distributed across a network where KEEL engines might focus their attention on special decisions and communicate with higher level KEEL engines to determine how to control the car. Other applications might be specialized and operate within a single engine. We have other tools that allow one to integrate several KEEL engines in one higher level application. This helps when the problem is more complex and you want to work on pieces separately.
Question: What language was used to create the KEEL tools? I think I can create KEEL-like tools using a variety of COTS tools. Why would I license KEEL Technology from Compsim?
Answer: The language used to create the KEEL Toolkit, Compsim Management Tools, the KEEL Function Block Development Tools, etc. is unimportant to the user. Compsim has developed a portfolio of patents (granted and pending) that covers the KEEL technology space, not the specific implementation of the tools. So creating KEEL technology in any language would be an infringement of KEEL patents. Compsim does not "sell" KEEL "tools", it licenses KEEL technology that includes a set of tools that can be used "as is", or that can be used as prototypes for a set of tools that would be productized by the licensee. Compsim's patent portfolio includes the dynamic graphical language for capturing and testing human-like judgmental reasoning, a model for integrating subjective information to make judgmental decisions, an architecture for integrating judgmental reasoning in devices and software applications (microprocessor based), and an architecture for implementing judgmental reasoning in an analog circuit.