HO Support in Logic Specification Languages 

for Data Mining

Matthias van der Hallen - ICLP DC (31/08/15)

Me

Studied Engineering: Computer science
Graduated from KU Leuven in 2014

Joined the Knowledge Representation & Reasoning research group after graduation.

Promotor: Gerda Janssens
Copromotor: Marc Denecker

FO(·)

A grounder and solver that supports certain FO(·) extensions

Family of Languages extending FO with:

  • Type System
  • Arithmetic
  • Inductive Definitions
  • (Partial) Functions
  • Aggregates
  • ...

Data Mining

Challenges:

Large, or even infinite, domains: costly enumeration

Potentially backed by a traditional database

Same concepts reoccur often.

E.g. Homomorphism, isomorphism

Not much support for this in KR languages

Modularity

We write the transitive closure of binary relations very often:

∀a, b : ClosureOfP ( a, b ) ← P( a, b ).
∀a, b : ClosureOfP ( a, b ) ← ∃c : P( a, c ) ∧ P( c, b ).

 

  • Relations as First Class Citizens (HO)
  • Library Building Constructs
  • Structured Recursive & Generic Types: ADTs

FO(·) misses:

∀a, b : ClosureOfP ( a, b ) ← P( a, b ).
∀a, b : ClosureOfP ( a, b ) ← ∃c : P( a, c ) ∧ P( c, b ).

Modularity

  • Library Building Constructs: Templates

Higher Order Support is an important step towards Modularity:

Templates are Second Order definitions

{
   Closure(P,Q) ← {
                    Q(x,y) ← P(x,y) ∨ (∃ z: Q(x,z)∧Q(z,y)).
                   }.
}

Problem:

Many solving systems, such as IDP, depend on a grounding phase.

Grounding translates FO(·) constraints to a propositional level

but when domain enumeration is costly or impossible, we can't ground naively.

∀a : P(a) ⇒ ∀b : Q(a,b).
¬P(a1) ∨ Q(a1,b1).
¬P(a1) ∨ Q(a1,b2).
¬P(a2) ∨ Q(a2,b1).
¬P(a2) ∨ Q(a2,b2).

Smart Techniques

  • Lazy Grounding & Relevance
  • Quantifier Elimination & Rewriting
  • Oracles

We need smarter techniques to handle large domains and higher order constraints:

Lazy Grounding & Relevance

∀a : P(a) ⇒ ∀b : Q(a,b).
  • Grounds only when necessary
  • Only partially if formula is complex
  • Only relevant literals, i.e. the program's truth value depends on that of the literal

For large domains, this is grounded when:

  • P(a) is made True for some a

  • Q(a, b) is made False for some (a, b)

Lazy Grounding & Relevance

  • Support complex expressions s.a. Aggregates, nested function terms, ...
  • Optimize interaction with the solver

Upcoming work:

Quantifier Elimination

Reducing the number of quantifiers makes for smaller groundings

Skolemization: Replace existential quantifiers by (Skolem) constants:

  • Unnested ∃: introduce skolem constant

  • Nested ∃: introduce functions

∃a : P(a).
∀a : ∃b : Q(a,b).
P(S).
∀a : Q(a,S(a)).

Requires support for functions & CP

Extensions & other techniques exist:

  • Rewrite ∀ quantifiers to ​∃

  • Rewritings such as in Presburger Arithmetic (Cooper1972)

Oracles

Bootstrapping technique to allow quantification over predicates:
 

  • Ensure quantifications are existential

  • Encapsulate quantification body as theory

  • Solve this Existential SO theory using
    subsolver as oracle

  • Require it to pass/fail

Oracles

  • Efficiently share resources between different (sub)solver processes
  • Evaluate eager / lazy activation
  • How to represent information learnt from subsolver conflicts

Upcoming work:

Questions?

Matthias van der Hallen

matthias.vanderhallen@cs.kuleuven.be

Celestijnenlaan 200A, Leuven

+32 16 37 39 84

Made with Slides.com