1. Bernd Fischer School of Electronics and Computer Science University of Southampton b.fischer@ecs.soton.ac.uk Requirements for an Algebraic-Logic Simplifier Implementation in Stratego

2. Background Formula simplification: (2*x–y-x)*(-x+-(-y-2*x)) → x**2-y**2 … should be the killer application of term rewriting … but isn’t: –no term rewrite engine comes with a strong simplifier –no open source library of rules … so why? –domain engineering effort high –technical limitations in existing rewrite engines No fundamental reason – strong rewrite-based simplifiers exist! computer algebra systems(Mathematica) research applications(AutoBayes) use home-brewed rewrite engines

3. Goals Today: outline requirements for simplification discuss implementation impact Mid-term: get developer support (ATerm / Stratego) get developer support (rule engineering) build kernel system sufficient for AutoBayes++ Long-term: release open-source versions of –symbolic algebraic-logic kernel –core computer algebra system

4. ACI1-Terms Common properties of mathematical operators: A ≙ associativity: x ∘ (y ∘ z) = (x ∘ y) ∘ z C ≙ commutativity:x ∘ y = y ∘ x I ≙ idempotence: x ∘ x = x 1 ≙ unit element: x ∘ 1 = x Corresponding term representations: A ≙ lists ACI ≙ sets AC ≙ bags 1 ≙ empty list/set/bag ∧ ∧∧ ∧∧ z x Tx yy ∧ xyz + ++ ++ z x 1x yy + xyz (2) (1)

5. ACI1-Terms Why use ACI1 term representations? smaller terms  less traversal –CAVEAT: benefit likely to be smaller with full sharing –common bag elements already shared… –… but additional sharing of compound terms possible (partially) compiles A / C rules  faster normalization –circumvents termination problems with C rule –CAVEAT: remaining rules need “to do the rest” x ∧ (x ∨ y) → x becomes xs1* ∧ x ∧ (ys2* ∨ x ∨ ys2*) ∧ xs2* → xs1* ∧ x ∧ xs2* simplifies integration of full ACI1 matching

6. ACI1-Terms Who should build the term representation? user?  Really Bad: needs rules and traversals to build terms rewrite engine (on traversal)?  Still Bad: can leave partially normalized terms term library (on term construction)?  Also Bad:needs backwards pointers re-builds terms mid-traversal  probably combination of rewrite engine and term library + a b + cd * + a + b * cb * d redex → unnormalized cc

7. ACI1-Terms Exposing the term representation? can be useful: x + x → 2*x x + n*x → m*x where eval(n+1) → m exposure of other aspects: –size? –order? becomes x → m*x (m) might be useful for strategies

8. ACI1-Matching Proper theory matching would be nice: simplifies rule implementation (x ∧ y) ∨ ( x ∧ ¬y) → x instead of zs1* ∨ (xs1* ∧ y ∧ xs2*) ∨ zs2* ∨ ( xs1* ∧ ¬y ∧ xs2*) ∨ zs3* → zs1* ∨ ( xs1* ∧ xs2*) ∨ zs2* ∨ zs3* instead of increases confidence bool_simplify('bool-cancel-or-4', _, _, _, or(Disjuncts),R) :- select(and(Conjuncts1), Disjuncts, DisjunctsM1), select(and(Conjuncts2), DisjunctsM1, DisjunctsM12), Conjuncts1 \== Conjuncts2, select(Q, Conjuncts1, ConjunctsRemaining), select(not(Q), Conjuncts2, ConjunctsRemaining), !, append([and(ConjunctsRemaining)],DisjunctsM12,DisjunctsNew), sort(DisjunctsNew,DisjunctsOut), R = or(DisjunctsOut).

9. ACI1-Matching Limited theory support: combination of pattern compilation and list matching (x ∧ y) ∨ ( x ∧ ¬y) → x becomes zs1* ∨ (xs1* ∧ y ∧ xs2*) ∨ zs2* ∨ ( xs1* ∧ ¬y ∧ xs2*) ∨ zs3* → zs1* ∨ ( xs1* ∧ xs2*) ∨ zs2* ∨ zs3* might be sufficient but can be tricky: list vs. element –detailed pattern analysis (+ signature information?) –user cooperation: (xs* ∧ y) ∨ ( xs* ∧ ¬y) → xs* must handle commutativity efficiently (x ∧ y) ∨ ( x ∧ ¬y) → x(x ∧ y) ∨ ( ¬y ∧ x) → x (y ∧ x) ∨ ( x ∧ ¬y) → x(y ∧ x) ∨ ( ¬y ∧ x) → x … –prevent combinatorial explosion of rule set

10. ACI1-Matching Limited theory support: combination of pattern compilation and list matching … integration with term traversal define:cancel1: (x ∧ y) ∨ ( x ∧ ¬y) → x apply:all(cancel1) to:… ∨ (x ∧ y) ∨ (x ∧ z) ∨ ( x ∧ ¬y) ∨ ( x ∧ ¬z) –prevent repeated list traversal handling of non-unitary matching? –perhaps define unitary set/bag matching

11. ACI1-Matching Full theory support: build-in full theory matching handling of non-unitary matching –add both don’t care non-deterministic don’t know non-deterministic matching operations (a la Elan) –use fail-strategy to control search space induced by matching –(perhaps) add fail-match strategy to cut “from inside”

12. Contextual Rewriting Sound simplification requires contextual information: divide: x / x → 1 where not(x → 0) sufficient for 1 / 1 but not for n / n

13. Contextual Rewriting Sound simplification requires contextual information: divide: C |= x / x → 1 where not(C |= x → 0) Rewrite engine manages contexts on term traversal –default: propagation into subterms (cf. congruence strategies) –exceptions: specified by user –integration transparent to user |= is not a term constructor (I think…) –interferes with “normal” rewriting C contains explicit context information c-cond: C |= (p ? t : f) → (C |= p) ? (C ∧ p) |= t) : (C ∧¬ p) |= f) c-plus: C |= x + y → (C |= x) + (C |= y) only conceptually!

14. Contextual Rewriting contexts == dynamic rules?

15. Contextual Rewriting contexts == dynamic rules? not quite… –introspection: can analyze contents of context –join / extension: can use different operations to extend contexts  by default: logical conjunction  strategy-controlled: deduction, abstract interpretation contexts == strategies? –|= is lifted to strategy operator: first argument is context, second argument is strategy x ≥ 0 |= (x ≤ 0) ? f(x) : t can infer x = 0 by analysis of (x ≥ 0) ∧ (x ≤ 0) but not by applying x ≥ 0 → true c-cond(S, T): (C |= S) ? (T(C ∧ (#1))) |= S) : (T(C ∧¬(#1))) |= S)

16. Binders Need to support different kinds of binders: – ∀ x:p(x) –∑ –let alpha-conversion? explicit substitutions?

17. Conclusions some ACI1-support is required context-handling would be nice no idea (still) how to handle binders learning by doing