# for Data Mining

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

# 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

# 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 ).``````

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

FO(·) misses:

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

# 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 ).``````

# Modularity

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

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

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)).
}.
}``````

# 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)

# Quantifier Elimination

Reducing the number of quantifiers makes for smaller groundings

Skolemization: Replace existential quantifiers by (Skolem) variables:

• Unnested ∃: introduce skolem variable
• Nested ∃: introduce functions
``````∃a : P(a).
∀a : ∃b : Q(a,b).``````
``````P(S).
∀a : Q(a,S(a)).``````

Requires support for functions

Extensions & other techniques exist:

• Rewrite  quantifiers to ​
• Rewritings such as in Presburger Arithmetic (Cooper1972)

# Oracles

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

# Questions?

## Matthias van der Hallen

matthias.vanderhallen@cs.kuleuven.be

Celestijnenlaan 200A, Leuven

+32 16 37 39 84

#### ICLP DC - WIP

By Matthias van der Hallen

• 1,002