# 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.

Best,

Liu,Yu

2009-09-08

liu.yu.senior.china

-----BEGIN PGP SIGNED MESSAGE-----
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
instantiated.
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])
then
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
Voltage[J]
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.
Regards,
Thorsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKprmTUFhLgjx+3KQRAoidAJ9vVTHxqzS7yU6IvMFwQ9VhT17FqgCeJkqi
SpbCSgEMlpJVylsTuEH3IPA=
=eaR6
-----END PGP SIGNATURE-----
```
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