Speed

• The Engineering Inference Engine is forward chaining using local propagation for high speed. Backward chaining, used by other inference engines, is slower because it is inherently a search process.
• There are no traditional IF THEN rules, as such. Once a function infers a value, the engine looks at the other functions connected to that value and selects one to execute if it can. This is very fast, and in combination with branches is equivalent to traditional IF THEN rules.
• Computational complexity is minimized. Nested iterations are where poorly-customized routines burn through CPU time, especially in complex engineering designs where iterations can go 5-10 levels deep. When deducing iterative functions, the Engineering Inference Engine distinguishes between parameters that change from one iteration to the next and parameters that do not. Unless constrained by the user, the Engine itself figures out which parameters to assume in order to deduce the value of a variable, and it omits extraneous calculations. It also prefers quicker functions to slower ones. Once a function is compiled, it is simply a list of operations that execute sequentially and run fast where it makes the biggest difference – inside loops!

Scalability

• The number of variables is limited only by memory size. The memory address of each variable is its unique identity within the Engineering Inference Engine. There is no central list of variables – the data structure is a decentralized network of pointers, and the inference engine operates upon them.
• New data types are built from basic ones. The basic data types are boolean, integer, double, complex double, and vectors and matrices thereof. There are also character, string and struct types. These data types are objects within the Engineering Inference Engine, so they can be inherited and combined to make composite types. For example, there is a data type with maximum and minimum limits, formed from a composite of three double variables encapsulated into a single object. It is used in connection with iterative functions.
• Any problem that can be represented by known functions can be solved. The Engineering Inference Engine is generic. Its functions are black boxes to it; they are simply function handles with lists of corresponding variables to use for parameters. The user manages the fundamental definition of the problem and decomposes it for the Engineering Inference Engine. The Engineering Inference Engine then solves it all by inferring which function handles to call in what sequence.

Reusability

• Models are object oriented. Object hierarchies are built using inheritance. Objects can be manipulated via the command line using dot notation (e.g. Root.Sub.Coordinates.z).
• A standardized engineering/physics ontology. The ontology mirrors the categorizations used in mathematics and engineering courses taught in schools and universities worldwide. For example, there are objects representing the thermodynamics of a simple compressible substance, the state of a fluid at rest, in motion, and within a duct. Each of these objects builds on the object before it by connecting with other objects in the ontology or adding new functions and variables that represent new quantifiable ideas. This forms a highly compact and reusable body of knowledge.
• The representation of knowledge within the Engineering Inference Engine is inherently more compact and reusable than conventional code. Metacognition defines three types of knowledge: Declarative, procedural and conditional. Traditional code is mostly procedural knowledge, but this is the type of knowledge that changes the most when a concept, for example a geometry or the flow of a fluid, is applied to a different situation.  In the Engineering Inference Engine, models are constructed of declarative and conditional knowledge, which changes little if at all in a well-decomposed ontology. Moreover, describing a problem in declarative and conditional terms guides the user to focus on defining the essence of the problem to be solved rather than the mechanistic writing and debugging of subroutines.