Integrating Logic and Machine Learning

"We may be utilizing machine learning 'too little, too late'.  (IE, we're using too little ML and using ML not early enough).  Thus we may be already going down a slightly wrong path...  we should correct this by taking ML seriously and try to find the best way to incorporate ML in our architecture..." --YKY

interfacing with dANN has been my goal while designing Genifer's Java layer.  when it's finished, it will allow us to combine dANN's components with Genifer concepts.

dANN provides several "machine learning" (and related) components:

• dynamic bayesian networks
• many types of neural networks
• dimensional embedding aka graph drawing
• graph metrics
• etc...

Genifer's logic can remain in LISP -- Java may not be allowed to interfere - but the concepts will be reference-able

LISP will be able to bind formulas to Java method calls.  for example, using graph drawing:

List<Atom> getNeighbors(similarityGraph, center, radius)

so now that we know this, the question becomes: how do we create integrative designs that utilize Genifer and dANN as (internal) components?

well we could create many types of integrative designs.  though we may have a chance to evolve them: we can declaratively instantiate new instances of the system inside itself.

http://picocontainer.org/introduction.html


"Constructor Injection is a Dependency Injection variant where a component gets all its dependencies via its constructor."


"The most important benefits of Constructor Injection are:

• It makes a strong dependency contract
• It makes testing easy, since dependencies can be passed in as Mock Objects
• It is very succinct in terms of lines of code
• Classes that rely on Constructor Injection are generally Good Citizens
• A dependency may be made immutable by making the dependency reference final"

Systems like Picocontainer, and Spring Framework, are used to declaratively specify "wirings" of component dependencies.  This amounts to a hierarchical property tree listing the interfaces, implementation classes, and constant parameters in order to fill a "container" aka "context".

more later on this...

Logic-Driven OpenGL Drawing Loop

click to zoom:

Example Fluxus Script:

(define (render)

   (scale (vector 0.5 0.5 0.5))

   (colour (vector 0 0.5 1))

   (draw-cube))

(every-frame (render))

seeAlso:

• http://docs.racket-lang.org/quick/
• http://en.wikipedia.org/wiki/Model%E2%80%93View%E2%80%93Controller
• http://en.wikipedia.org/wiki/Opengl
• http://www.pawfal.org/fluxus/

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.

Why "uncertainty on top of logic" is bad

I have made this point before, but this is a better way to put it:

If we put "logic on top of uncertainty", then the uncertainty calculus operates underneath the logic and the logic cannot "see" its workings, ie, the uncertainty calculus is invisible from the logic's POV.  This is an advantage, as we can make queries about logic statements and the uncertainty calculus will work "behind the scene" -- we don't have to worry about it at the logical level.

Contrast this with "uncertainty on top of logic".  Now every statement in the KB is shrouded within a layer of uncertainty calculus.  We cannot query statements directly, because some nodes' TVs will be buried in probabilistic functions as their arguments.  Seeking the TV would involve finding the inverse of those probabilistic functions -- which can be extremely complicated for a logic to handle automatically, ie:
     given          X = f(A, B, C, D, ...)
     where          f  is the probability function
     solve for     A     in terms of X, B, C, D, ...