Optimal boolean expressions evaluation
Optimal boolean expressions evaluation
What is known tactic for creating optimal boolean query expressions, for example if i have this query:
(OR (AND (= A B) (= C D))
(AND (= A B) (= Y P)))
faster evaluation would be:
(AND (= A B)
(OR (= C D) (= Y P)))
, this is not only lisp related but it's natural to solve this in lisp form
Thanks
(OR (AND (= A B) (= C D))
(AND (= A B) (= Y P)))
faster evaluation would be:
(AND (= A B)
(OR (= C D) (= Y P)))
, this is not only lisp related but it's natural to solve this in lisp form
Thanks
Re: Optimal boolean expressions evaluation
btw. i posted this here because it's part of something i'm doing in Common Lisp and i'm interested in CL solutions (also it's natural to do this in sexp) .... wiki link can help too
Re: Optimal boolean expressions evaluation
I don't know that much about prepositional logic, but this seems to be an NPhard problem. Some relevant Wikipedia links: Circuit minimization (note that digital circuits are equivalent to boolean expressions), Karnaugh maps,Quineâ€“McCluskey algorithm, Espresso heuristic logic minimizer.
I haven't seen any code for doing that in CL, but I haven't looked. It is quite likely that there might be some in some older archives like CMU Common Lisp Repository.
I haven't seen any code for doing that in CL, but I haven't looked. It is quite likely that there might be some in some older archives like CMU Common Lisp Repository.
Re: Optimal boolean expressions evaluation
A couple things to watch for:
 Shortcircuiting operators (AND fails after first nil, OR passes after first t) may change the optimal result, especially if you can accurately predict truth frequencies.
 If shortcircuiting operators protect mutating tests, refactoring may be impossible.
 Shortcircuiting operators (AND fails after first nil, OR passes after first t) may change the optimal result, especially if you can accurately predict truth frequencies.
 If shortcircuiting operators protect mutating tests, refactoring may be impossible.

 Posts: 61
 Joined: Mon Jul 07, 2008 8:06 pm
 Location: Toowoomba, Queensland, Australia
 Contact:
Re: Optimal boolean expressions evaluation
This makes me want to be able to tell if a particular form is a mutating/sideeffect one or not. I suppose it would be kinda cool to have a compiler macro for this kind of thing.
Re: Optimal boolean expressions evaluation
of course there is no mutating tests here, we can simplify this:
to
and this should lead to:
Code: Select all
(OR (AND (= A B) (= C D))
(AND (= A B) (= Y P)))
Code: Select all
(OR (AND a b)
(AND a c))
Code: Select all
(AND a (OR b c))

 Posts: 406
 Joined: Sat Mar 07, 2009 6:17 pm
 Location: Brazil
 Contact:
Re: Optimal boolean expressions evaluation
This kind of problem reminds me the type inference made by SBCL.
Internally, SBCL transforms a type specifier (like 'array or 'string) into an object. The function that retrieves such object is sbkernel:specifiertype. The function that gives the specifier back is sbkernel:typespecifier. Types like '(and string array) and '(or integer character) are constructed using sbkernel:typeintersection and sbkernel:typeunion.
I believe this is much similar to what you want to do, since SBCL can simplify some nested type unions / intersections similarly to the simplification of boolean expressions. You may refer to these functions (using M. using Slime) and see if it helps.
Unfortunately, it seems not to be able to simplify the following expression, which is what you would want it to do:
Internally, SBCL transforms a type specifier (like 'array or 'string) into an object. The function that retrieves such object is sbkernel:specifiertype. The function that gives the specifier back is sbkernel:typespecifier. Types like '(and string array) and '(or integer character) are constructed using sbkernel:typeintersection and sbkernel:typeunion.
I believe this is much similar to what you want to do, since SBCL can simplify some nested type unions / intersections similarly to the simplification of boolean expressions. You may refer to these functions (using M. using Slime) and see if it helps.
Code: Select all
cluser> (sbkernel:typespecifier
(sbkernel:typeintersection (sbkernel:typeunion (sbkernel:specifiertype 'array)
(sbkernel:specifiertype 'fixnum))
(sbkernel:typeunion (sbkernel:specifiertype 'array)
(sbkernel:specifiertype 'integer))))
(or array fixnum)
cluser> (sbkernel:typespecifier
(sbkernel:typeunion (sbkernel:typeintersection (sbkernel:specifiertype '(integer 2 1))
(sbkernel:specifiertype '(integer 1 2)))
(sbkernel:typeintersection (sbkernel:specifiertype '(integer 2 1))
(sbkernel:specifiertype '(integer 0 3)))))
(integer 1 1)
cluser> (sbkernel:typespecifier
(sbkernel:typeintersection (sbkernel:typeunion (sbkernel:specifiertype 'character)
(sbkernel:specifiertype 'fixnum))
(sbkernel:typeunion (sbkernel:specifiertype 'character)
(sbkernel:specifiertype 'array))))
character
cluser> (sbkernel:typespecifier
(sbkernel:typeintersection (sbkernel:typeunion (sbkernel:specifiertype 'character)
(sbkernel:specifiertype '(satisfies foo)))
(sbkernel:typeunion (sbkernel:specifiertype 'character)
(sbkernel:specifiertype '(satisfies bar)))))
(or character (and (satisfies bar) (satisfies foo)))
Code: Select all
cluser> (sbkernel:typespecifier
(sbkernel:typeunion (sbkernel:typeintersection (sbkernel:specifiertype 'fixnum)
(sbkernel:specifiertype '(satisfies foo)))
(sbkernel:typeintersection (sbkernel:specifiertype 'fixnum)
(sbkernel:specifiertype '(satisfies bar)))))
(or (and fixnum (satisfies foo)) (and fixnum (satisfies bar)))
;;; it would be better if it was (and fixnum (or (satisfies foo) (satisfies bar)))
;;; like in your example