Re: [eclipse-clp-users] Getting legaly named variables / Unifiying Term Lists

From: Christian Wirth <tyrion_at_...215...>
Date: Thu, 11 Feb 2010 14:57:00 +0100
Ok, sorry for writing not more, but thought yesterday i have now 
completed the current feature (except the small problem) ... but after 
sleeping a night over it, i think i must possibly change something 
somewhere else.

Here now the complete problem:

I have term's in CNF that i split up according to some predicates. The 
splitted clauses are added to lists, but this must happen without prolog 
trying to bind the variables.
So i decided to convert the terms into strings bevor adding, to prevent 
the binding. As several times mentioned, i need to preserve variable 
names/numbers exactly.
term_to_bytes preserves variable names but not numbers. term_string does 
preserve the numbers but not the names.
In theory term_to_bytes should also perserve the numbers, but it doesn't 
work for me ...
I so i used set_var_name to name all variables and use term_to_bytes.

I can't reproduce the problem without the complete programm .. i assume 
it hase something to do when the variables are getting bound, but here 
is the relevant code at least:

myCall(TermA,S1),myCall(TermB,S2),union(S1,S2,S)

myCall(Term,State) :- 
conjunctionlist(Term,List,StringState),maplist(bytes_to_term,StringState,State).

%Splits state dependent (d_true) from other facts. Temporary conversion 
to string to prevent prolog from solving
conjunctionlist((A,B),Independent,Dependent) :- 
conjunctionlist(A,IndependentA,DependentA),conjunctionlist(B,IndependentB,DependentB),union(IndependentA,IndependentB,Independent),union(DependentA,DependentB,Dependent),!.
conjunctionlist((A;B),Independent,Dependent) :- 
conjunctionlist(A,Independent,Dependent).
conjunctionlist((A;B),Independent,Dependent) :- 
conjunctionlist(B,Independent,Dependent),!.
conjunctionlist(\+(d_true(Arg,_)),[],[SArg]) :-  preserve(\+(Arg),SArg),!.
conjunctionlist(d_true(Arg,_),[],[SArg]) :- preserve(Arg,SArg),!.
conjunctionlist(Term,[Term],[]).

preserve(Term,String) :- (foreacharg(X,Term) do 
((var(X),set_var_name(X,'Var'));true)),term_to_bytes(Term,String).


Kish Shen schrieb:
> Christian Wirth wrote:
>> i'm currenlty using set_var_name in my programm to get lists like this:
>>
>> List=[pred(Var#1,Var#2)].
>>
>
> I am not quite sure what you mean by "get lists like this". 
> lib(var_name) is designed purely to allow unique names for variables 
> when they are printed. You should not use them in any other way.
>
>> i have now a second list
>>
>> List2=[pred(Var#3,Var#4),pred2(Var#3,Var#4)]
>>
>> and then i call union(List,List2,Result) and Result becomes 
>> [pred(Var#1,Var#2),pred2(Var#3,Var#4)], but i need 
>> [pred(Var#1,Var#2),pred2(Var#1,Var#2)]
>>
> I am not sure I understand how you got this. What exactly did you write?
>
> I just tried:
>
> set_var_name_counter('Var', 1),set_var_name([W,X,Y,Z], 'Var'),
> L1 = [pred(W,X)], L2 = [pred(Y,Z),pred2(Y,Z)], union(L1,L2, L)
>
> and here is the the result:
>
> W = Var#1
> X = Var#2
> Y = Var#1
> Z = Var#2
> L1 = [pred(Var#1, Var#2)]
> L2 = [pred(Var#1, Var#2), pred2(Var#1, Var#2)]
> L = [pred(Var#1, Var#2), pred2(Var#1, Var#2)]
>
>> this should work, but it only does with "normal" variable names like 
>> Var .. not with the # in between.
>
> I don't understand this at all. Using lib(var_name) should not have 
> any effect on how the program behave, it only affects the way a 
> variable's name is printed. What do you mean it does not work with # 
> in between?
>
>> Now i have to choices changing set_var_name to create legal names, 
>> but the function is build in ??
>> .. or to get union to somehow correctly consider all named variables ?
>
> Are you somehow thinking of usng these names in your own source code? 
> The source code names have nothing to do with the names lib(var_name) 
> produces -- the non-legal names is there to prevent you confusing 
> names you write in your source from the names printed using 
> lib(var_name).
>
> Cheers,
>
> Kish
Received on Thu Feb 11 2010 - 13:57:09 CET

This archive was generated by hypermail 2.3.0 : Thu Feb 22 2024 - 18:13:20 CET