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

Hello,

i have a working solution now (it seems, more tests needed).
But first things first:
I want to get all abstract moves, to determine the relation between facts.
An example:
I have the condition cell(X,Y,Player) and the effect cell(X,Y,blank), 
then i have a "remove" relation. Because the move replaces a 
player-dependent constant with a player-independent constant in a fact.
To not get 1000's of states is the reason why i dont want the variables 
instanciated. If only the variables are instanciated, that are making a 
difference to the condition/effect and not the position, the move count 
is not very big.

Now to my solution:
After Stefan pointed out some other problems and gave me some tips for a 
solution, i got something working by a combination of different 
approaches i had.
I'm generating a legal move and all effects to that move command. This 
is happening nearly without unification, but by simply converting the 
terms to CNF and determining the relevant predicate calls.
Of cause, one move command can describe several move. To test if one 
effect is applyable, i try to unify the effect conditions with the legal 
conditions.
Additionaly i do not convert terms to string/byte representations 
anymore. Thatway they stay a "term" always and the unification works 
correctly.

But as Stefan already pointed out, this stuff goes beyond what this 
mailling list is for. But if u are interested to see if my approach is 
going somewhere, maybe there is another way to stay in touch.
Maybe there is a GGP Forum somewhere out there i dont know ?

cheers Christian

Joachim Schimpf schrieb:
> Christian Wirth wrote:
>   
>> 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.
>>     
>
> Hi Christian,
>
> you are really going down a wrong track here.  You will save yourself a
> lot of frustration and unnecessary work if you take a step back, and think
> about what you are really doing here.  I think the questions that Stefan
> Schiffel (whose code you seem to be using) asked earlier, seriously need
> to be answered before you do any more coding!
>
> As far as I understand, Stefan's code is designed to work with ground
> states, that's why his use of findall's makes sense.  You try to use
> it in a different way, which as you notice, doesn't work.
>
> Can we come up with a very small example (not involving gdl etc) that
> demonstrates what kind of result you want to achieve when you evaluate
> a move starting from a nonground state?
>
> It seems to me that the whole idea of collecting all solutions does not
> make much sense when you don't start from a fixed given state.  If you
> don't know the starting location, you will have thousands of possible
> moves.  Constraint programming looks like right tool to deal with this
> (by constraining the possible moves and by working with an implicit
> representation of the space of alternative outcomes) but it requires
> a different way of modelling the problem.  Anyway, as I'd like to see
> a successful Eclipse application coming out of this, I'd be happy to
> make suggestions.  But seriously, don't waste any more time trying
> to abuse variable names!
>
>
> Cheers,
> Joachim
>
>
>
>
>
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______________________________________________
> ECLiPSe-CLP-Users mailing list
> ECLiPSe-CLP-Users_at_lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/eclipse-clp-users
>
>