Self-Reflective Interactive Realities

A.I. SpaceGraph

another reason for going directly to JOGL is that i see an opportunity to make an AI scenegraph
a scenegraph is just a framework for managing what drawing commands are performed
so what i'm saying is that certain parts of dANN could form that framework
which is why i wondered if dANN had anything like a quadtree or octree
it seemed similar to that VectorSet or VectorMap we were discussing
for using GraphDrawing to find contents in a hypersphere
a scenegraph is usually a DAG
i think a more appropraite term is 'SpaceGraph'
not scene
described here http://automenta.com/spacegraph

How does space graph differ from scene graph?

scenegraph is just a term used in computer graphics
i'm making a connection between AI and 2d/3d computer rendering
the other side of it, is input sensing
the mouse cursor for example (and multitouch too) generate a sequence of events
and changes in state
the input logic too could benefit from AI

2D Prototype

just working on a 2D model right now
which would be suitable for graph drawing (and interaction)
it does zooming and panning and now i can do intersection with rectangular areas

what i'm saying is that we can do even better than ordinary ‘scenegraphs’ potentially
whether it optimizes it or replaces it entirely

Why focus on user-interfaces rather than AI “work”?

because the graph drawing stuff could form the basis for a new desktop UI
and as a result, apps like netbeans would be obsolete
because we could in essence program directly into it
i'm thinking deeply about it because it may hold a chance of accelerating development, in the long long term
if the system can reason about its drawing commands, its input sense, and what it is working with, it will be completely reflectively AI
then the entire system state can be persisted in graphs and shared over the network
no need for the file system, trac, etc anymore
Git might be a good versioning system to use for serialized graphs
(there is JGit pure java impl of Git which can be used to make a virtual filesystem interface)
for example, code and issues would be linked explicitly
so realizing all this, i'm trying to make a simple 2D interactive framework that dANN can hook into this way
for at minimum, graph layout, text input, and drawing connections between things
i mean a user-inputted drawn connection
like sketches or wires
i think i've found a minimum list of UI functionality necessary to achieve this
full graph reflexivity
even typing the letter 'a' would start to bring up associations
'...is the first letter of English alphabet'

Dont you think for that to happen the AI needs to reach a more mature level?

everything necessary exists right now. its not really AI, just designing it in a way that it can be utilized by AI components like graphs, neural networks, genetic algorithms, etc
then as soon as we can construct those AI components from within the system, we can accelerate experimentation
because all of the results will be right there

Why move to JOGL instead of Java3D?

for interactive graph panning, zooming, and clicking buttons
JOGL is more direct
Java3D's scenegraph is nearly made obsolete when compared with Ardor3D or JME3
some of its terminology are really unweildly, like 'viewplatform' etc
anyway Ardor3D and JME use JOGL as their underlying OpenGL interface
https://jogl.dev.java.net/

implementation: the "Logic" class

Definition of the Logic class:

Formula------------ Constant ------------------------ Atom
                |                                          |
                --------- Variable                  ---------- Char, and String
                |                                          |
                --------- Apply-Operator       ---------- Number ------------ Integer, Real, Bool, etc...
                |                                                                        
                --------- Apply-Functor


Atom:  {  string: name,  int: index  }                                 // atoms are eg: "john", "mary"
Variable:  {  int: index  }
Apply-Operator:  {  char: op,  Formula[]: arguments  }          // op applied to 1 or more arguments
Apply-Functor:  {  Atom: functor, Formula[]: arguments  }    // functor applied to 1 or more arguments
                                                                                      // functor can be function or predicate
                                                                                      // functor's name is just an Atom

Definition of FOL terminology:

This set of terminology is standard for FOL:

1. At the top level is the formula (or proposition, or sentence, or logic statement, all synonyms).
2. A formula can be a rule or a fact.  A rule is of the form
        A <- X, Y, Z, ...
   And a fact does not contain the "<-" operator.
3. Each formula consists of a number of literals joined by logical operators (aka connectives) such as AND and OR, and operations can be nested.  Note that NOT is a unary operator.  Eg:
• (loves john mary)                                     is a literal
• (NOT (female john))                                is a literal
• (AND (loves john mary) (female mary))    are 2 literals joined by AND
• (OR (AND (p X) (q Y))  (r Z))                  is nested
4. Each literal consists of a predicate plus its arguments, eg:
• (loves john mary)                    where love = predicate with 2 arguments
• (male paul)                             where male = predicate with 1 argument
• (female (daughter-of paul))      where female = predicate with 1 argument, "daughter-of" is a function symbol
5. Terms (or arguments) can be:
• variables   (eg:  X, Y, Z)
• constants   (eg:  john, mary, 17, "String")
• functions of other terms   (eg:  daughter-of(john),  sine(3.14))

That's all!

Our simplified terminology:

In anticipation of higher-order logic:

1. The notion of predicates and functions are combined into functors.
2. We can also absorb functors into operators, but this is not currently done.
3. In FOL, a function-application is not a formula, but this is relaxed in our definition.  Potentially it can lead to ill-formed formulas.  For example, sine(3.14) is clearly not a formula;  but we want to allow some functions that return formulas.

The result is more elegant, and we can express this by a set of re-write rules:
     formula ===> constant
     formula ===> variable
     formula ===> (functor formula1 formula2 ...)
     formula ===> (op formula1 formula2 ...)

More about rules

Rules are of the form:

     A <- B, C, D, ...

where A is the "head", B,C,D,... is the "body", and "<-" is just a special operator like "AND";  we can call it "COND" for conditional.

Each "," is equivalent to an "AND".  So, the above rule is represented as:

     (COND A (AND B C D...))

where "AND" can accept more than 2 arguments.

( In our logic, <- translates to a link in a Bayesian network.  For this reason, it seems not very meaningful for a formula to have "<-" inside the body instead of at the head position. )

Some special cases:

1. If a rule has no head, it is still a rule, such as:
        (interesting X)    means "everything is interesting"
   -- note that all variables are implicitly universally quantified, ie, the above is really:
        for-all X,  interesting X
2. We can ignore the case where a rule has no body (it's not useful).
3. A rule without variables is still a rule, eg:
        wet <- rains
        not cloudy <- sunny

Representing variables and constants

Notice that we can use any way we want to represent variables and constants internally.  In my Lisp code, variables are like "?1" etc and constants are "john" etc.  In a more sophisticated KB, we would of course use some kind of indexes.

Code

This is Russell's C# code, and Chuck's Cobra code.  When in doubt, please conform to the definition above.

Porting Genifer LISP to Scala or Clojure, July 1st

Per YKY's instructions, I am getting ready to port Genifer's existing LISP code located at...

http://launchpad.net/genifer

...to either Scala or Clojure, JVM languages which can inter-operate with Java.  In doing this I hope to provide a framework that will ultimately unify AI libraries like Genifer, dANN, Neuroph, and others.


_KY_: The porting is 3 steps:

1. unification algorithm
• this contains a "unify" written in Haskell:
  http://propella.blogspot.com/2009/04/prolog-in-haskell.html
2. best-first search
3. substitution management
4. optional: [ forward chaining ]
5. optional: [ abduction ]

YKY recommends that I review:

• the target language
• the 2 chapters about logic and inference from "Artificial Intelligence: A Modern Approach"
• the Genifer slides on Deduction which explains YKY's LISP code in a very detailed way

Code will be commited to Genifer's Google Code repository.