Home » forums » LtU Forum

ANN: Jekejeke Minlog 0.6.2 (forward debugging and hypothetical reasoning)

Dear All,

Just wanted to let you know that Jekejeke Minlog 0.6.2 is
out. There was some functionality in the Jekejeke Minlog
extension module that lay dormant until now. With this release
of Jekejeke Minlog we provide a first batch of built-ins for
hypothetical and counterfactual reasoning. Internally these
built-ins work with clause references and trailed undos.

To introduce hypothetical and counterfactual reasoning to
logic programming is not new, we draw here on work from
the 80's.

Jekejeke Minlog also provides variants that work without a
sub-goal and keep the update for the duration of the continuation.
The continuation variants of hypothetical and counter factual
reasoning form the update component of the continuation version of
forward chaining, which is used to implement constraint solvers.
Since new constraints, similar to unification results,
stay for the duration of the continuation.

Now that we have hypothetical and counter factual reasoning: Is
it useful and does it perform? To some extend we have already
answered this question by the implementation of our CLP(FD)
constraint solver. But the constraint solver makes also use
of the forward closure computation, so are there some interesting
applications not integrated with the forward closure?

Interestingly the answer seems yes. We managed to implement
tic-tac-toe via the continuation variant of the new Jekejeke
Minlog tool box.

In the old solution the board state is passed around in predicate
arguments. In the new solution we perform updates on the facts
via hypothetical/counter factual operations. Since the board state
is not anymore passed around we do not need a move/3 predicate.
Instead we can work with a move/1 predicate that has only one
parameter and that updates the knowledge base:

% move(+Player)
move(P) :-
   clause_ref(board(-,M,N), true, R),
   compile_ref(board(P,M,N), S),
   retire_ref(R),
   assume_ref(S).

Astonishingly the new solution is also performant. Our measurements
show the following figures for checking whether there exists
a winning strategy:

Old Parameter Solution: 124ms
New Update Solution: 224ms

Theoretically a certain advantage could be gained for bigger boards
via the update method, since it works only locally. Further forward
closure could come to the picture again to model complex moves.

Comments welcome.

Bye

Jekejeke Minlog 0.6.2

Tic-Tac-Toe with Parameter

Tic-Tac-Toe with Update

By j4n bur53 at 2013-01-07 19:49 | LtU Forum | previous forum topic | next forum topic | other blogs | 6563 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Hi

Dear All,

Was just off my keyboard for a couple of weeks. Please don't be shy to show your scrutiny or ask questions on Jekejeke Minlog.

I also made some G+ posts before I was off, showing a CSP interpretation of hypothetical and counter factual reasoning, and also some meta interpreter ideas:

http://plus.google.com/u/0/103259555581227445618/posts/hoLxUgeErAT

Best Regards

By j4n bur53 at Sun, 2013-02-10 11:14 | login or register to post comments

Newest Time Measurements / FRP based on LP

This could look like a pun into the face of all functional
/ reactive programming. But one could also view it as a new
variant of the very same idea.

Namely a logic programming flavored variant, whereby each
predicate is side effect free when it comes to backtracking,
but might have side effects in the continuation. The tic-tac-toe
example does NOT show some fancy composition operators, it
focuses merely on a proof of concept that the side effects
are really gone during backtracking, otherwise it would not
be possible to implement the tic-tac-toe that simple.

Just repeated some testing, with the current release
of Jekejeke Minlog. The release profits from some
findings by Jos De Roo that have been incorporated
earlier into the Jekejeke Runtime 0.9.7, and that
speed up the dynamic database.

As expected the update version is faster than the
parameter version now. I get for 10 runs of
tic-tac-toe the following result now:

Parameter Solution: 1200 ms
Update Solution: 1150 ms

I generally expect the update solution to be faster
in case:

- The state space is not small
- The state space can be accessed and
modified associatively, i.e. just-in-time
indexes (*) do help operating on the state space.

In the tic-tac-toe example this is already the case.
For example a move by a player is simply modelled
as follows:

    % move(+Player)
    move(P) :-
       clause_ref(board(-,M,N), true, R),
       compile_ref(board(P,M,N), S),
       retire_ref(R),
       assume_ref(S).

Thus an automatic index on the first argument of board/3
speeds up the search for a free place. Further for example
checking for a winning position reads:

    % win(+Player)
    win(P) :-
       board(P,0,0), board(P,1,0), board(P,2,0).
    Etc..

And this seems to be faster, than using state matching via
unification for the same purpose. Automatic indexes on the
second and third argument of board/3 help here.

Bye

P.S.: Just-in-time indexes have for example newly been
introduced into SWI-Prolog:
http://www.swi-prolog.org/pldoc/doc_for?object=section%282,%272.17%27,swi%28%27/doc/Manual/jitindex.html%27%29%29
But they are also found in the Jekejeke Runtime.

By j4n bur53 at Mon, 2013-09-16 21:25 | login or register to post comments