ModelInference / texada

Efficient techniques for mining LTL formulae over linear input traces

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Subformula memoization in checkers.

bestchai opened this issue · comments

The only current memoization in texada is memoization of first occurrences in the map trace checker.

We would like some further memoization of subformulas in the prefix tree (and perhaps linear) checkers. The idea for subformula memoization comes from the fact that certain formula trees have children that contain non-overlapping atomic propositions,
I.e. the formula "s,t without z responds to p after q until r", in LTL:
G (q -> (p -> (!r U (s & !r & !z & X((!r & !z) U t)))) U (r | G(p -> (s & !z & X(!z U t)))))
has tree:

bigtree.png

Note that varying the bindings of q only modify one node of the tree. It is likely some of the information gotten from calculating the left side of the tree will be re-used for different q. (The exact evaluation on a node of the left tree would not happen in this case, because it is only evaluated if the specific q event occurs). This may cause speed-up.


What is less evident is how to effectively store this information. Currently ltl formulae tree are dealed with as pointers and are deleted after use. Simply stroing pointers in the map would not be very useful as new formulae are instantiated by creating totally new objects, not by reusing pointers.

However, comparing trees for real equality (i.e. by traversing them both and comparing) would likely be time intensive.

One suggested strategy was to "morph" the trees for different instantiations instead of creating new ones at each time. As such, some elements in the memoization map would be "invalidated" if they are affected by the morph, but others would not. For this to be useful, the order of instantiation would likely have to change.

Another idea is to change representation of instantiated property types. Instead of passing in a clone of the original formula with substituted atomic propositions, the original formula and the "instantiating function" (at code level, a map) could be passed to a checker. With information of which bindings are relevant for each node in the formula (i.e., which atomic propositions it contains), the keys to the memoization map could be a combination of pointers to the original formula node, the relevant variable->event mappings and the trace position. If the instantiations maps were stored in the checker, this would only minimally change checker code.

[Issue created by carolemieux: 2014-08-18]
[Last updated on bitbucket: 2014-08-20]

[Comment created by carolemieux: 2014-08-20]
This is resolved for prefix tree checkers, which was the main concern.

the command

-f '(G!y) | (!y U (y & Fx -> (!x U (a & !x & X(!x U z)))))' -p TEXADA_HOME/traces/resource-allocation/abb4cad.txt

took about 2m13 s without the memoization. It now takes about 9 seconds, which is equivalent to the the linear trace checker (~10 seconds). Probably because this is not a great prefix tree case (the traces are random).

Issue can be reopened if we decide to add this to linear and map checkers as well.

[Comment created by carolemieux: 2014-08-20]
Reopening to add comments...

[Comment created by carolemieux: 2014-08-20]
Closing Issue26

→ <<cset 4d2160107e25>>