Re: [eclipse-clp-users] saving the resolution list of a call

Am 17.05.2010 08:31, schrieb Thorsten Winterer:
> Am 16.05.2010 17:22, schrieb Christian Wirth:
>    
>> expand(X,ResListIn,[F/A|ResListOut]) :-
>> functor(X,F,A),clause(X,C),((C=true)->(ResListOut=ResListIn);(join_string([F,A,"rec"],"/",String1),(containsKey(String1)->(ResListOut=ResListIn,call(X));(expand(C,ResListIn,ResListOut))))).
>>
>> containsKey(Key) :- clause(logicStorage(Key,_)).
>>
>> logicStorage is a dynamic predicate and contains all recursive
>> predicates. The resolutionlist of those predicates should not be saved.
>> And ideas how to increase the speed further ? If requiered, i would also
>> be willing to make changes to the eclipse source code to have this
>> resolution list available.
>>
>>
>>      
> Instead of this:
>
> expand(X,ResListIn,[F/A|ResListOut]) :-
>          functor(X,F,A),
>          clause(X,C),
>          (
>              C = true
>          ->
>              ResListOut=ResListIn
>          ;
>              join_string([F,A,"rec"],"/",String1),
>              (
>                  containsKey(String1)
>              ->
>                  ResListOut=ResListIn,
>                  call(X)
>              ;
>                  expand(C,ResListIn,ResListOut)
>              )
>          ).
>
>
>    
Thx for formatting, i added some comments:

expand(X,ResListIn,[F/A|ResListOut]) :-
         functor(X,F,A),
         clause(X,C),
         (
             C = true %clause is resolved to a fact
         ->
             ResListOut=ResListIn
         ;
             join_string([F,A,"rec"],"/",String1),
             (
                 containsKey(String1) %clause is recursive
             ->
                 ResListOut=ResListIn,
                 call(X) %do not expand rescurisve clauses
             ;
                 expand(C,ResListIn,ResListOut) %all other clauses
             )
         ).

> I would use something like this:
>
> expand(X,ResListIn,[F/A|ResListOut]) :-
>          (
>              clause(X,true)
>          ->
>              ResListOut=ResListIn
>          ;
>              functor(X,F,A),
>              recursive(F,A)
>          ->
>              ResListOut=ResListIn,
>              call(X)
>          ;
>              expand(C,ResListIn,ResListOut)
>          ).
>
>
> 1. The clause body C is only needed for the check C=true. You can use
> clause(X,true) directly.
>    
It's used later on in the expand clause, as u can see.

> 2. The use of join_string and containsKey seems expensive. Instead of
> forming a string and then testing for that you can test for F and A
> directly. You would need to rewrite containsKey, but I would consider
> replacing that dynamic predicate with a static one anyway: If the list
> of recursive predicates is known at the beginning, you can collect the
> Functor/Arity specifications and then compile corresponding facts (I
> used recursive(F,A) in the code above). By compiling them into a static
> predicate, access will be much faster than with a dynamic predicate.
> Depending on the number of recursive predicates, and therefore the
> specifications that need to be checked, storing them in a data structure
> that allows faster access than iterating over the facts should be
> considered even if the list of recursive predicates is not known a priori.
>    
The dynamic predicate contains a bit more then the information if a 
predicate is recursive. It also contains the recursive clause and the 
terminating alternative clause.
That's why there is a "/rec" in the string at the end. I will do of 
course the replacement with a static predicate, but that shouldn't 
change much. The recursive predicate count is pretty low normally.

But i just got another idea, i will try out. Keep the normal call(X), 
but adding something like set_store(I,Clause) to all relevant clauses 
forhand. I have only to retrieve the stored information then. I assume 
this should be alot faster.

Cheers Christian