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 发件人： Thorsten Winterer 发送时间： 2009-09-08 15:07:58 收件人： liu.yu.senior.china 抄送： 主题： Re: multi-loop and if then statement -----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 : Wed Sep 25 2024 - 15:13:20 CEST