Re: [eclipse-clp-users] multi-loop and if then statement

From: liu.yu.senior.china <liu.yu.senior.china_at_...6...>
Date: Tue, 8 Sep 2009 16:28:53 -0500
Dear Mr. Winterer,

Thank you so much. I understand and agree what you said. But it doesn't work and I get a No. To debug, I first replace the line with (1$=1)=>(1$=1). All the solutions of Fs are produced as expected. Then I replace the line with (Fi $= Levels[J]) => (1 $= 1) and get a No.

From my understanding, even if all the Fi $= Levels[J] in the loop are false, the clause should still return a yes because they are not constraints on Fs.

I am sorry to bother you.





发件人: Thorsten Winterer 
发送时间: 2009-09-08  15:07:58 
收件人: liu.yu.senior.china 
主题: Re: multi-loop and if then statement 
Hash: SHA1
liu.yu.senior.china schrieb:
> Dear Mr. Winterer,
> Thank you for your help. THe problem lies in that line. I changed the line to Fi$=Levels[J] => Z, to test how constraint implications worka. However, I get No. 
You would get "no" since Z is a variable, not a constraint. See below.
> If I change the line to Fi==Levels[J] -> Vi is Voltage[J]; true  , I  can get all the solutions of Fs, but Vs is not instantiated in all the solutinos. The condition never succeeds!! It seems contradictory to build the constraints before labeling and let them take effect after labeling.
In this instance, the test for equality "Fi == Levels[J]" fails, so you
will always end up in the else-statement "true". Therefore, Vi is never
You need to distinguish between the unification =/2, test for equality
==/2, and equality constraints like $=/2. In your case, the Fi variables
have domains that contain the values of Levels[J]. Therefore, using
either the unification =/2 or the equality constraint $=/2 will succeed
and the then-statement "Vi is Voltage[J]" is immediately executed.
However, since Fi is not instantiated and Levels[J] is ground, the test
for equality fails, and the else-statement "true" is immediately executed.
> Besides, I don't understand why constraint implication (=>) will take effect after labeling. Is it the reasoning to choose it insteand of if else ?
The constraint implication waits until the truth value of one constraint
is known. Only then will the truth value be propagated and possibly the
truth value of the other constraint is set. For this, you need
constraints that have reified forms, like $=/2. The reified form is
$=/3, i.e. $=(X,Y,B) where B will be 1 if X equals Y and 0 if X does not
equal Y.
So if you use
(Fi $= Levels[J]) => (Vi $= Voltage[J])
1. Vi is set to equal Voltage[J] iff Fi equals Levels[J]
2. Levels[J] is removed from the domain of Fi iff Vi does not equal
But this is only triggered once enough is known about Fi or Vi to make
this decision, i.e. during labeling.
By the way, is/2 is not a constraint but will evaluate the right-hand
side immediately and unify the left-hand side with the result. You need
to use $=/2 for the right-hand side of your constraint implication.
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -

Received on Tue Sep 08 2009 - 21:29:18 CEST

This archive was generated by hypermail 2.3.0 : Sat Aug 24 2019 - 09:15:01 CEST