You can subscribe to this list here.
2004 |
Jan
(4) |
Feb
(1) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(14) |
2010 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Tim C. <tim...@ya...> - 2013-05-02 13:36:06
|
http://www.cpms-business-consultants.com/cntujcgb.php Single Mom Makes $89,844/Yr in Her Spare Time on The Computer |
From: Tim C. <tim...@ya...> - 2013-04-06 15:06:55
|
http://www.serrurerie-cannes.com/zatyrx/dgxikju.gnt Tim Cleaver 4/6/2013 4:06:46 PM gwgsniqgqzaezqrx zwblgr |
From: Tim C. <tim...@ya...> - 2013-04-01 00:29:56
|
http://www.dorukokullari.com/ugnzelo/qjok.ddk?tivj Tim Cleaver 4/1/2013 1:29:43 AM izvslbxohbtuqvbamnnlzwtsy zixloasz |
From: Tim C. <tim...@ya...> - 2013-03-07 23:35:10
|
http://www.cedetroit.com/vj/ftjriwh/xwgppf/zydf/xkulwwdkn Tim Cleaver 3/8/2013 12:21:52 AM |
From: Bajor T. <baj...@ho...> - 2012-05-15 16:17:19
|
Hi Dear Jason Users! I would like to make an executable file from my Jason application. I have found an option what makes a jar file under the Plugins/Jason/Create an executable jar option in jEdit IDE. But the jar while what it made have a problem. It cant find the jacamo.infra.JaCaMoInfrastructureFactory.java file. Is it a bug or only me get this message? And how should i solve it? I tried to find this file on the internet, somewhere, but it was useless. Any advice, someone? Or there is an another way to make an executable file? Thanks a lot! Kumar |
From: Francisco G. M. <fra...@uv...> - 2012-03-09 15:11:10
|
Hi all, I think I have found a bug when doing two consecutive subtractions. Here I attach a simple project in which the following operations are made: X = 1 - 1 - 1 Y = (1 - 1) - 1 Curiously, only Y is evaluated as -1, while X is equal to 1. Best, Fran -- ------------------------------------------- Dr. Francisco Grimaldo Moreno (PhD) (Id. GnuPG: 0xBAEC75A7) Departament d'Informàtica Escola Tècnica Superior d'Enginyeria (ETSE) Universitat de València Avinguda de la Universitat, s/n 46100 Burjassot-València (SPAIN) Tel: +34 96 354 44 87 (+34 96 354 45 65) Fax: +34 96 354 47 68 Email: fra...@uv... Web: http://www.uv.es/grimo ------------------------------------------- |
From: Jomi H. <jom...@gm...> - 2010-05-11 13:03:21
|
Hi Tim, thanks again for such a great job: find and solve the problem! I simply added your solution in the subversion. Cheers, Jomi On 11/05/2010, at 05:26, Tim Cleaver wrote: > Jason Devs, > > There is an issue when an uninstantiated variable is compared to a number term implementation. This is because a VarTerm is a NumberTerm. When comparing them, solve is called on the uninstantiated VarTerm which causes an exception and evaluates the VarTerm as 0. > > There is a statement in the tests (src/test/TermTest.java:569-570) that variables should be greater than other terms when different types of terms are compared. > > Attached is a patch that prevents the exception being thrown and results in uninstantiated variables being compared greater than other terms. When the variable is bound, however, the comparison is based on the variable's value instead. Thus, a variable bound to a number implementation of 4 is greater than a number implementation value of 2. > > I have included a patch to VarTermTest.java that highlights the problem and a patch for NumberTermImpl.java that solves it. The result passes both the jason junit tests and the as-unit tests as well. > > cheers, > Tim Cleaver > > > <NumberTermImpl.java.patch><VarTermTest.java.patch>------------------------------------------------------------------------------ > > _______________________________________________ > Jason-bugs mailing list > Jas...@li... > https://lists.sourceforge.net/lists/listinfo/jason-bugs -- Jomi Fred Hubner Federal University of Santa Catarina Department of Automation and Systems Engineering PO Box 476, Florianópolis, SC 88040-900 Brazil http://www.das.ufsc.br/~jomi |
From: Tim C. <tim...@ya...> - 2010-05-11 08:26:21
|
Jason Devs, There is an issue when an uninstantiated variable is compared to a number term implementation. This is because a VarTerm is a NumberTerm. When comparing them, solve is called on the uninstantiated VarTerm which causes an exception and evaluates the VarTerm as 0. There is a statement in the tests (src/test/TermTest.java:569-570) that variables should be greater than other terms when different types of terms are compared. Attached is a patch that prevents the exception being thrown and results in uninstantiated variables being compared greater than other terms. When the variable is bound, however, the comparison is based on the variable's value instead. Thus, a variable bound to a number implementation of 4 is greater than a number implementation value of 2. I have included a patch to VarTermTest.java that highlights the problem and a patch for NumberTermImpl.java that solves it. The result passes both the jason junit tests and the as-unit tests as well. cheers, Tim Cleaver |
From: Jomi H. <jom...@gm...> - 2010-02-08 11:48:55
|
Hi Tim, thanks for the patch. I included it in the subversion. Cheers, Jomi On 08/02/2010, at 04:29, Tim Cleaver wrote: > Jason developers, > > The last patch I sent regarding the ObjectTermImpl equals method is > not 100% correct. There is a case where a variable can be assigned a > value. In such circumstances the variable must equate with anything > equal to what it is bound to. This patch fixes this issue and adds > an additional test to demonstrate that the equality is now/again > reflective. Now an ObjectTermImpl and a variable that is bound to an > ObjectTermImpl (that is equal to the other ObjectTermImpl) will be > equal. > > regards, > Tim Cleaver > > Send instant messages to your online friends http://au.messenger.yahoo.com > <ObjectTermImpl.equality. > 2 > .patch > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term > contracts > Personal 24x7 support from experience hosting pros just a phone call > away. > http://p.sf.net/sfu/theplanet-com_______________________________________________ > Jason-bugs mailing list > Jas...@li... > https://lists.sourceforge.net/lists/listinfo/jason-bugs -- Jomi Fred Hubner Department of Automation and Systems Engineering Federal University of Santa Catarina PO Box 476, Florianópolis, SC 88040-900 Brasil http://www.das.ufsc.br/~jomi |
From: Tim C. <tim...@ya...> - 2010-02-08 06:29:19
|
Jason developers, The last patch I sent regarding the ObjectTermImpl equals method is not 100% correct. There is a case where a variable can be assigned a value. In such circumstances the variable must equate with anything equal to what it is bound to. This patch fixes this issue and adds an additional test to demonstrate that the equality is now/again reflective. Now an ObjectTermImpl and a variable that is bound to an ObjectTermImpl (that is equal to the other ObjectTermImpl) will be equal. regards, Tim Cleaver Send instant messages to your online friends http://au.messenger.yahoo.com |
From: Jomi H. <jom...@gm...> - 2009-12-21 11:43:07
|
On 21/12/2009, at 06:14, Tim Cleaver wrote: > Jomi, > > Glad to hear you found a better fix for the anonymous variable issue. mostly you found! Thanks (I've just adapted some parts) > I will test it using my personal project soon. > > I have found what appears to be a trivial bug in Trigger.java. None > of the j/as unit tests fail as a result of the fix. Patch is attached. this kind of typo is terrible to find. Thanks again. (it is committed on SVN) best, Jomi > > regards, > Tim > > > > __________________________________________________________________________________ > See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ > <Trigger.getTerm.fix.diff> -- Jomi Fred Hubner Department of Automation and Systems Engineering Federal University of Santa Catarina PO Box 476, Florianópolis, SC 88040-900 Brasil http://www.das.ufsc.br/~jomi |
From: Tim C. <tim...@ya...> - 2009-12-21 08:14:23
|
Jomi, Glad to hear you found a better fix for the anonymous variable issue. I will test it using my personal project soon. I have found what appears to be a trivial bug in Trigger.java. None of the j/as unit tests fail as a result of the fix. Patch is attached. regards, Tim __________________________________________________________________________________ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ |
From: Jomi H. <jom...@gm...> - 2009-12-19 13:10:26
|
Tim, I committed new versions of Literal and Structure that passed on all tests. For Literal, I went back to the original version (which do not clone all the rule, just the head), it is 3 times faster and seems not related to the original bug. Attached the project I used to measure that |
From: Jomi H. <jom...@gm...> - 2009-12-18 19:29:07
|
Hi Tim, I include (partially) your suggestions into the SVN of Jason. (details attached -- I've tried to optimise some parts.... If you could check...) notes: 1. we cannot comment the makeVarAnnon in TransitionSystem (I added a new test to show it) 2. with this line uncommented, one of the tests do not pass. (it could be a problem in "if" ... I'll see) best, Jomi Revision: 1566 http://jason.svn.sourceforge.net/jason/?rev=1566&view=rev Author: jomifred Date: 2009-12-18 19:24:45 +0000 (Fri, 18 Dec 2009) Log Message: ----------- add some code from Tim to solve makeVarsAnnon problem (not finished) Modified Paths: -------------- trunk/applications/as-unit-test/src/jason/tests/BugUnamedVars.java trunk/applications/as-unit-test/src/jason/tests/TestAll.java trunk/src/jason/asSyntax/ArithFunctionTerm.java trunk/src/jason/asSyntax/Literal.java trunk/src/jason/asSyntax/Pred.java trunk/src/jason/asSyntax/Rule.java trunk/src/jason/asSyntax/Structure.java trunk/src/jason/asSyntax/VarTerm.java trunk/src/test/RuleTest.java trunk/src/test/TermTest.java Added Paths: ----------- trunk/applications/as-unit-test/src/jason/tests/TestUnnamedVar.java Modified: trunk/applications/as-unit-test/src/jason/tests/ BugUnamedVars.java =================================================================== --- trunk/applications/as-unit-test/src/jason/tests/BugUnamedVars.java 2009-12-18 14:10:31 UTC (rev 1565) +++ trunk/applications/as-unit-test/src/jason/tests/BugUnamedVars.java 2009-12-18 19:24:45 UTC (rev 1566) @@ -20,15 +20,26 @@ ag.parseAScode( "wrap([],[]). "+ "wrap([_ | Rest], [wrapped(_) | Result]) :- wrap(Rest, Result). "+ + + "wrap2([], _). "+ + "wrap2([_ | Rest], Result) :- wrap2(Rest, Temp) & Result = wrapped(_, Temp). "+ + "+!start : wrap([a,b,c],R) & R = [wrapped(a), wrapped(b), wrapped(c)] <- jason.asunit.print(ok)."+ - "+!start : wrap([a,b,c],R) & R = [wrapped(a), wrapped(a), wrapped(a)] <- jason.asunit.print(nok). " + "+!start : wrap([a,b,c],R) & R = [wrapped(a), wrapped(a), wrapped(a)] <- jason.asunit.print(nok). " + + "+!test2 : wrap2([1, 2, 3], Result) & Result = wrapped(1, wrapped(2, wrapped(3, 4))) <- jason.asunit.print(ok). " ); } @Test(timeout=2000) - public void testWrap() { + public void testWrap1() { ag.addGoal("start"); ag.assertPrint("ok", 20); } + + @Test(timeout=2000) + public void testWrap2() { + ag.addGoal("test2"); + ag.assertPrint("ok", 20); + } } Modified: trunk/applications/as-unit-test/src/jason/tests/TestAll.java =================================================================== --- trunk/applications/as-unit-test/src/jason/tests/TestAll.java 2009-12-18 14:10:31 UTC (rev 1565) +++ trunk/applications/as-unit-test/src/jason/tests/TestAll.java 2009-12-18 19:24:45 UTC (rev 1566) @@ -23,6 +23,7 @@ TestLoop.class, TestPlanbodyAsTerm.class, TestPlanFailure.class, - TestVarInContext.class + TestVarInContext.class, + TestUnnamedVar.class }) public class TestAll { } Added: trunk/applications/as-unit-test/src/jason/tests/ TestUnnamedVar.java =================================================================== --- trunk/applications/as-unit-test/src/jason/tests/ TestUnnamedVar.java (rev 0) +++ trunk/applications/as-unit-test/src/jason/tests/ TestUnnamedVar.java 2009-12-18 19:24:45 UTC (rev 1566) @@ -0,0 +1,22 @@ +package jason.tests; + +import jason.asunit.TestAgent; + +import org.junit.Test; + +public class TestUnnamedVar { + + @Test(timeout=2000) + public void testUnnamedVar() { + TestAgent ag = new TestAgent(); + + // defines the agent's AgentSpeak code + ag.parseAScode( + "+!test <- A=a(B); !t(A); jason.asunit.print(A). "+ + "+!t(A) <- B=3. " + ); + ag.addGoal("test"); + ag.assertPrint("a(B)", 10); // cannot print(a(3) + } + +} Modified: trunk/src/jason/asSyntax/ArithFunctionTerm.java =================================================================== --- trunk/src/jason/asSyntax/ArithFunctionTerm.java 2009-12-18 14:10:31 UTC (rev 1565) +++ trunk/src/jason/asSyntax/ArithFunctionTerm.java 2009-12-18 19:24:45 UTC (rev 1566) @@ -66,8 +66,17 @@ public boolean isStructure() { return false; } - + @Override + public Literal makeVarsAnnon(Unifier un) { + if (isEvaluated()) { + return null; + } else { + return super.makeVarsAnnon(un); + } + } + + @Override public boolean isLiteral() { return false; } @@ -81,7 +90,7 @@ public boolean isEvaluated() { return value != null; } - + @Override public boolean isGround() { return isEvaluated() || super.isGround(); @@ -97,7 +106,8 @@ */ @Override public boolean apply(Unifier u) { - if (isEvaluated()) return false; + if (isEvaluated()) + return false; super.apply(u); if ((function != null && function.allowUngroundTerms()) || isGround()) { Modified: trunk/src/jason/asSyntax/Literal.java =================================================================== --- trunk/src/jason/asSyntax/Literal.java 2009-12-18 14:10:31 UTC (rev 1565) +++ trunk/src/jason/asSyntax/Literal.java 2009-12-18 19:24:45 UTC (rev 1566) @@ -264,7 +264,6 @@ Unifier current = null; Iterator<Unifier> ruleIt = null; // current rule solutions iterator Rule rule; // current rule - Literal cloneAnnon = null; // a copy of the literal with makeVarsAnnon boolean needsUpdate = true; public boolean hasNext() { @@ -291,40 +290,28 @@ while (ruleIt != null && ruleIt.hasNext()) { // unifies the rule head with the result of rule evaluation Unifier ruleUn = ruleIt.next(); // evaluation result - Literal rhead = rule.headClone(); - - // unnamed vars should be replaced (see bug of Tim Cleaver) - replaceUnnamedVarsToUnnamedVars(rhead); - - // then apply and replace other free variables - rhead.apply(ruleUn); - rhead.makeVarsAnnon(ruleUn); - - - Unifier unC = un.clone(); - if (unC.unifiesNoUndo(Literal.this, rhead)) { - current = unC; + if (ruleUn.unifiesNoUndo(Literal.this, rule)) { + current = ruleUn; return; } } // try literal iterator + // + // we make the variables in the belief (be it a fact or rule) and not + // in this as this may be included in the scope of a plan. if we rename + // the variables in this and it is in the scope of a plan then the + // variables in the event and the body of the plan won't reflect the + // naming. thus, making the resulting unifier not reflect the entire + // scope of the plan. while (il.hasNext()) { Literal b = il.next(); // b is the relevant entry in BB if (b.isRule()) { - rule = (Rule)b; - - // create a copy of this literal, ground it and - // make its vars anonymous, - // it is used to define what will be the unifier used - // inside the rule. - if (cloneAnnon == null) { - cloneAnnon = Literal.this.copy(); - cloneAnnon.apply(un); - cloneAnnon.makeVarsAnnon(un); - } - Unifier ruleUn = new Unifier(); - if (ruleUn.unifiesNoUndo(cloneAnnon, rule)) { // the rule head unifies with the literal + rule = (Rule)b.clone(); + rule.makeVarsAnnon(); // make the variables in the rule anonymous + Unifier ruleUn = un.clone(); + if (ruleUn.unifiesNoUndo(Literal.this, rule)) { + // the rule head unifies with the literal so match the body ruleIt = rule.getBody().logicalConsequence(ag,ruleUn); get(); if (current != null) { // if it get a value @@ -333,7 +320,7 @@ } } else { Unifier u = un.clone(); - if (u.unifiesNoUndo(Literal.this, b)) { + if (u.unifiesNoUndo(Literal.this, b)) { // b.copy().makeVarsAnnon())) { current = u; return; } @@ -345,18 +332,6 @@ }; } - private void replaceUnnamedVarsToUnnamedVars(Literal l) { - final int size = l.getArity(); - for (int i=0; i<size; i++) { - Term ti = l.getTerm(i); - if (ti.isUnnamedVar()) { - l.setTerm(i, new UnnamedVar()); - } else if (ti instanceof Literal) { - replaceUnnamedVarsToUnnamedVars((Literal)ti); - } - } - } - /** returns this literal as a list with three elements: [functor, list of terms, list of annots] */ public ListTerm getAsListOfTerms() { ListTerm l = new ListTermImpl(); @@ -425,6 +400,11 @@ public Iterator<Unifier> logicalConsequence(final Agent ag, final Unifier un) { return LogExpr.createUnifIterator(un); } + + @Override + public Literal clone() { + return this; + } } @SuppressWarnings("serial") @@ -442,5 +422,10 @@ public Iterator<Unifier> logicalConsequence(final Agent ag, final Unifier un) { return LogExpr.EMPTY_UNIF_LIST.iterator(); } + + @Override + public Literal clone() { + return this; + } } } Modified: trunk/src/jason/asSyntax/Pred.java =================================================================== --- trunk/src/jason/asSyntax/Pred.java 2009-12-18 14:10:31 UTC (rev 1565) +++ trunk/src/jason/asSyntax/Pred.java 2009-12-18 19:24:45 UTC (rev 1566) @@ -400,7 +400,7 @@ VarTerm uv = varToReplace(ta, un); if (uv != null) lt.setTerm(uv); - else if (ta.isStructure()) + else if (ta instanceof Structure) ((Structure)ta).makeVarsAnnon(un); if (lt.isTail()) { uv = varToReplace(lt.getNext(), un); Modified: trunk/src/jason/asSyntax/Rule.java =================================================================== --- trunk/src/jason/asSyntax/Rule.java 2009-12-18 14:10:31 UTC (rev 1565) +++ trunk/src/jason/asSyntax/Rule.java 2009-12-18 19:24:45 UTC (rev 1566) @@ -23,6 +23,8 @@ package jason.asSyntax; +import jason.asSemantics.Unifier; + import java.util.Map; import java.util.logging.Level; import java.util.logging.Logger; @@ -77,6 +79,13 @@ return body; } + @Override + public Literal makeVarsAnnon(Unifier un) { + if (body instanceof Literal) + ((Literal)body).makeVarsAnnon(un); + return super.makeVarsAnnon(un); + } + public Rule clone() { Rule r = new Rule((Literal)super.clone(), (LogicalFormula)body.clone()); r.predicateIndicatorCache = null; Modified: trunk/src/jason/asSyntax/Structure.java =================================================================== --- trunk/src/jason/asSyntax/Structure.java 2009-12-18 14:10:31 UTC (rev 1565) +++ trunk/src/jason/asSyntax/Structure.java 2009-12-18 19:24:45 UTC (rev 1566) @@ -281,20 +281,48 @@ for (int i=0; i<size; i++) { Term ti = getTerm(i); VarTerm uv = varToReplace(ti, un); - if (uv != null) { + if (uv != null) setTerm(i,uv); - } else if (ti.isStructure()) { - Structure tis = (Structure)ti; - if (tis.hasTerm()) { - tis.makeVarsAnnon(un); - } - } + else if (ti instanceof Structure) + ((Structure)ti).makeVarsAnnon(un); } resetHashCodeCache(); return this; } protected VarTerm varToReplace(Term t, Unifier un) { + if (!t.isVar()) + return null; + VarTerm vt = (VarTerm)t; + VarTerm deref = un.deref(vt); + if (deref.isUnnamedVar()) + return new UnnamedVar(); + + // if the variable hasn't been renamed given the input unifier, then rename it. + if (deref.equals(vt)) { + // forget the name + VarTerm var = new VarTerm("_" + UnnamedVar.getUniqueId() + t); + // if deref has annotations then we need to replicate these in the new variable + if (deref.hasAnnot()) { + var.setAnnots(deref.getAnnots().cloneLT()); + var.makeVarsAnnon(un); + } + un.bind(deref, var); + return var; + } + // otherwise it has already been renamed in this scope so return + // the existing renaming + // ensure that if the input term has an annotation and the existing + // renaming doesn't then we add the anonymized annotations + if (vt.hasAnnot() && !deref.hasAnnot()) { + deref.setAnnots(vt.getAnnots().cloneLT()); + deref.makeVarsAnnon(un); + } + return deref; + } + + /* + protected VarTerm varToReplace(Term t, Unifier un) { if (t.isVar() && !t.isUnnamedVar()) { // replace t to an unnamed var VarTerm vt = un.deref((VarTerm)t); @@ -309,6 +337,7 @@ return null; } } + */ @Override public void makeTermsAnnon() { Modified: trunk/src/jason/asSyntax/VarTerm.java =================================================================== --- trunk/src/jason/asSyntax/VarTerm.java 2009-12-18 14:10:31 UTC (rev 1565) +++ trunk/src/jason/asSyntax/VarTerm.java 2009-12-18 19:24:45 UTC (rev 1566) @@ -414,6 +414,16 @@ } @Override + public Literal makeVarsAnnon(Unifier un) { + if (value == null) + return super.makeVarsAnnon(un); + else if (getValue().isLiteral()) + return ((Literal)getValue()).makeVarsAnnon(un); + else + return null; + } + + @Override public String toString() { if (value == null) { String s = getFunctor(); @@ -436,7 +446,7 @@ public void setAnnots(ListTerm l) { if (value != null) if (getValue().isPred()) - ((Pred) value).setAnnots(l); + ((Pred) getValue()).setAnnots(l); else logger.log(Level.WARNING, "The setAnnots '"+l+"' in "+this+" was lost, since this var value is not a Pred. The value's class is "+getValue().getClass().getName(), new Exception()); else Modified: trunk/src/test/RuleTest.java =================================================================== --- trunk/src/test/RuleTest.java 2009-12-18 14:10:31 UTC (rev 1565) +++ trunk/src/test/RuleTest.java 2009-12-18 19:24:45 UTC (rev 1566) @@ -2,9 +2,11 @@ import jason.asSemantics.Agent; import jason.asSemantics.Unifier; +import jason.asSyntax.ASSyntax; import jason.asSyntax.Literal; import jason.asSyntax.LogExpr; import jason.asSyntax.Rule; +import jason.asSyntax.Structure; import jason.asSyntax.VarTerm; import java.util.HashMap; @@ -80,12 +82,20 @@ ag.getBB().add(r); Iterator<Unifier> iun = Literal.parseLiteral("r([],a(20),X)").logicalConsequence(ag, new Unifier()); - assertEquals(iun.next().get("X").toString(),"b(20,4)"); - + //assertEquals(iun.next().get("X").toString(),"b(20,4)"); + assertTrue(iun.hasNext()); + Literal result = Literal.parseLiteral("r([],a(20),X)"); + Unifier u = iun.next(); + assertTrue(u.get("X").isStructure()); + assertEquals( ((Structure)u.get("X")).getArity(), 2); + assertEquals( ((Structure)u.get("X")).getFunctor(), "b"); + result.apply(u); + assertEquals(result, Literal.parseLiteral("r([],a(20),b(20,4))")); + iun = Literal.parseLiteral("r([],a(20),b(X,Y))").logicalConsequence(ag, new Unifier()); - Unifier u = iun.next(); - assertEquals(u.get("X").toString(),"20"); - assertEquals(u.get("Y").toString(),"4"); + u = iun.next(); + assertEquals(u.get("X"), ASSyntax.createNumber(20)); + assertEquals(u.get("Y"), ASSyntax.createNumber(4)); } Modified: trunk/src/test/TermTest.java =================================================================== --- trunk/src/test/TermTest.java 2009-12-18 14:10:31 UTC (rev 1565) +++ trunk/src/test/TermTest.java 2009-12-18 19:24:45 UTC (rev 1566) @@ -16,6 +16,7 @@ import jason.asSyntax.ObjectTermImpl; import jason.asSyntax.Plan; import jason.asSyntax.Pred; +import jason.asSyntax.StringTermImpl; import jason.asSyntax.Structure; import jason.asSyntax.Term; import jason.asSyntax.Trigger; @@ -27,9 +28,11 @@ import jason.bb.BeliefBase; import jason.bb.DefaultBeliefBase; +import java.util.ArrayList; import java.util.Collections; import java.util.HashMap; import java.util.Iterator; +import java.util.List; import java.util.Map; import junit.framework.TestCase; @@ -601,10 +604,21 @@ l2.makeVarsAnnon(); u.clear(); assertTrue(u.unifies(l1, l2)); + + // ensure that the anonymized instance of AgY unified to 32 + assertEquals(u.get((VarTerm) l1.getTerm(0)), new NumberTermImpl(32)); + // ensure that the first anonymized instance of QuadY2 unifies to 33 + assertEquals(u.get((VarTerm) l1.getTerm(1)), new NumberTermImpl(33)); + // ensure that the second anonymized instance of QuadY2 unifies to 33 + assertEquals(u.get((VarTerm) l1.getTerm(2)), new NumberTermImpl(33)); + // ensure that the anonymized instance of V unifies to 33 + assertEquals(u.get((VarTerm) l2.getTerm(2)), new NumberTermImpl(33)); + l2.apply(u); assertEquals("calc(32,33,33)", l2.toString()); l1.apply(u); assertEquals("calc(32,33,33)", l1.toString()); + } public void testMakeVarAnnon3() { @@ -636,7 +650,17 @@ } */ l.makeVarsAnnon(u); - assertEquals("p(_2)", l.toString()); + // ensure that X derefs to _2 + assertTrue(u.deref(new VarTerm("X")).equals(new UnnamedVar(2))); + // ensure that unifying a value with X will bind a value for all aliases as well. + Term val = new StringTermImpl("value"); + u.unifies(new VarTerm("X"), val); + assertTrue(u.get(new VarTerm("X")).equals(val)); + assertTrue(u.get(new VarTerm("Y")).equals(val)); + assertTrue(u.get(new VarTerm("Z")).equals(val)); + assertTrue(u.get(new UnnamedVar(4)).equals(val)); + assertTrue(u.get(new UnnamedVar(2)).equals(val)); + assertTrue(u.get(new UnnamedVar(10)).equals(val)); } public void testMakeVarAnnon5() { @@ -648,6 +672,32 @@ assertEquals("[s("+l.getTerm(0)+")]", l.getAnnots().toString()); } + // test from Tim Cleaver + public void testMakeVarsAnnon6() { + // if we make a literal anonymous multiple times, the instances should not + // be equal but should eb unifiable. + Literal literal = Literal.parseLiteral("literal(Variable, _)"); + List<Literal> literals = new ArrayList<Literal>(); + literals.add(literal); + // create a list of anonymized l1s + for (int i = 0; i < 5; i++) { + literals.add((literal.copy()).makeVarsAnnon()); + } + // ensure that all the anonymizations of Variable are different + // ensure that all the anonymizations of _ are different + // ensure that all pairs are unifiable + for (Literal l1 : literals) { + for (Literal l2 : literals) { + if (l1 == l2) { + continue; + } + assertFalse(l1.getTerm(0).equals(l2.getTerm(0))); + assertFalse(l1.getTerm(1).equals(l2.getTerm(1))); + assertTrue(new Unifier().unifies(l1, l2)); + } + } + } + public void testAddAnnots() { Literal p1 = Literal.parseLiteral("p1"); Literal p2 = Literal.parseLiteral("p2[a1,a2]"); This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Jason-developers mailing list Jas...@li... https://lists.sourceforge.net/lists/listinfo/jason-developers On 14/12/2009, at 21:17, Tim Cleaver wrote: > Jomi, > > Having sent you my updated patch I returned to my personal project. > However, it seems that your solution isn't sufficient for my needs. > I had figured that my simplified example was sufficient to capture > the entire issue. It wasn't. Here is another simple demonstration of > insufficient anonymous variable renaming that my project > necessitates. I hope this test case captures all my needs so you > don't have to reopen this bug again. I am trying to avoid sending my > actual project code as its complexity hides the real issues. > > wrap([], _). > wrap([_ | Rest], Result) :- wrap(Rest, Temp) & Result = wrapped(_, > Temp). > > !test. > > !test : wrap([1, 2, 3], Result) & Result = wrapped(1, wrapped(2, > wrapped(3, 4))) <- .print("ok"). > > Similar to last time, each anonymous variable in wrapped(_, Temp) > should be unique. Unfortunately it seems your fix does not provide > this. The patch sent in my previous email does. Perhaps it can be > adapted to work with your fix? > > regards, > Tim > > > > __________________________________________________________________________________ > See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ -- Jomi Fred Hubner Department of Automation and Systems Engineering Federal University of Santa Catarina PO Box 476, Florianópolis, SC 88040-900 Brasil http://www.das.ufsc.br/~jomi |
From: Tim C. <tim...@ya...> - 2009-12-14 23:17:14
|
Jomi, Having sent you my updated patch I returned to my personal project. However, it seems that your solution isn't sufficient for my needs. I had figured that my simplified example was sufficient to capture the entire issue. It wasn't. Here is another simple demonstration of insufficient anonymous variable renaming that my project necessitates. I hope this test case captures all my needs so you don't have to reopen this bug again. I am trying to avoid sending my actual project code as its complexity hides the real issues. wrap([], _). wrap([_ | Rest], Result) :- wrap(Rest, Temp) & Result = wrapped(_, Temp). !test. !test : wrap([1, 2, 3], Result) & Result = wrapped(1, wrapped(2, wrapped(3, 4))) <- .print("ok"). Similar to last time, each anonymous variable in wrapped(_, Temp) should be unique. Unfortunately it seems your fix does not provide this. The patch sent in my previous email does. Perhaps it can be adapted to work with your fix? regards, Tim __________________________________________________________________________________ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ |
From: Tim C. <tim...@ya...> - 2009-12-14 04:08:40
|
Jomi, I continued working on my approach and was basically finished by the time I saw your alternative. I am glad it is fixed. I am attaching my new patch just as a FYI, for posterity :^) and incase you can steal from it if other bugs relating to this are identified in future. This patch satisfies the old meaning of testMakeVarsAnnon4 and all the asunit tests as well. The primary change is in literal.java. It always anonymizes the beliefs (both rule and fact) from the beliefs as they are pulled out. It clones them first so as to not pollute the belief base with the new names. Because the beliefs are renamed and not the context of plans, the mapping from old names to new can be discarded. As such, a separate unifier is used to collect the renamings for rules (although a hashmap from vars to vars would probably be better). Structure.java has been updated to use the input unifier passed to makeVarsAnnon as a mapping from old variables to new. Thus, all variable are renamed, not just the anonymous ones. This renaming process will also inspect the annotations to ensure their renamings are consistent also. Basically you can call makeVarsAnnon on any structure and you will be given a consistent anonymisation that will respect any input manual renamings. All this aside, thank you again for fixing my original problem. regards, Tim __________________________________________________________________________________ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ |
From: Jomi H. <jom...@gm...> - 2009-12-09 12:04:32
|
Hi Tim, I tried a lot to use your solution... but the consequences for other parts of the interpreter are quite difficult to adapt. So, I implemented another solution. A kind of "two phases" replacement. I firstly replace "_" to new unnamed vars, and then proceed as usual. The changes are in the Literal.java class. I'll forward you the diff generated by the commit on SVN. Thanks again for the help, Jomi On 08/12/2009, at 02:37, Tim Cleaver wrote: > Jomi, > > I have revisited the patch for anonymous variables. This time I have > implemented it against the current public svn version 1561. The > change to Structure.java is the same (although tidied up a bit). > This time, however, I have updated TermTest.java as well. These > changes aim not to change the intent of the tests, only the way they > are carried out (although I may have made mistakes in identifying > their intent, given they aren't named descriptively nor documented). > Most of the changes revolve around moving from using toString to > testing the objects directly using equals and u.unifies. A side- > effect of this is that you can change the way the involved objects > are converted to strings without breaking the tests. > > The test I had the most difficulty in understanding was > testMakeVarAnnon4(). It appears that a unifier is created, a manual > renaming of one of the variables is made and it is tested that this > manual renaming is respected in makeVarsAnnon (i.e. the variable > isn't renamed further). If this is the case, then the new test > doesn't really capture that desired behavior. I think, but maybe > mistaken, that this behavior is inconsistent with solving my > original issue. Just because an unnamed variable hasn't attained a > value in the input unifier, does not mean it shouldn't be renamed. > Just because a named variable has been renamed to an unnamed > variable doesn't mean it does not need further renaming. If you > enforce renaming regardless of previous aliasing, then the old > renaming must be overridden. Thus, manual aliases cannot be > respected. If you ensure that you only rename a variable once given > an input unifier then situations where more than one aliasing is > necessary cannot be accommodated (like that situation identified in > my prior email). > > There is also an additional test that demonstrates the original > problem I was having. The original Structure.java will fail this > test. The patched version will not. The only downside to the new > Structure.java is that more anonymous variables are created than > previously (thus the removal of the count in testMakeVarAnnon3()). > Given the original problem was that not enough new variables were > created, I fail how to see this would be an issue. > > On a related issue, one of the original tests failed (with the new > Structure.java) because no unifier was passed into the makeVarsAnnon > method. Because makeVarsAnnon modifies the input unifier and an > empty default was supplied, the mapping from the old name to the new > was lost when the empty default unifier was discarded. Any attempt > at unification that does not use a unifier with the mapping from old > names to new will fail to assign values to the original variable. > Consequently, I believe that it would be beneficial to change the > interface of Literal.java to remove the makeVarsAnnon() method. This > would make it compulsory to pass in a unifier to this method. Given > clients won't know whether a given Literal will create new bindings > as a result of anonymizing the variables therein, clients don't know > whether to call makeVarsAnnon() or makeVarsAnnon(Unifier u). Most > will go with makeVarsAnnon() assuming it will Do the Right Thing, > not knowing they may lose > information about variable aliases. > > Hopefully this provides more insight into the issue and that a > solution can be arrived at soon. > > regards, > Tim > > > > __________________________________________________________________________________ > See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ > <UnnamedVarAnonymizeFix2.diff> -- Jomi Fred Hubner Department of Automation and Systems Engineering Federal University of Santa Catarina PO Box 476, Florianópolis, SC 88040-900 Brasil http://www.das.ufsc.br/~jomi |
From: Jomi H. <jom...@gm...> - 2009-12-08 13:52:06
|
You can also try the following AS program (ASUnit in file BugVarsAsArg reported by Stephen Cranefield) test_rule(A,a(A)). ml0(L,L). ml(V1,V2,R) :- ml0([V1,V2],R). append([], L, L). append([H|T], L1, [H|L2]) :- append(T, L1, L2). !test1. !test2. !test3. +!test1 <- ?test_rule(T,A); A = a(V); T=45; .print(V). +!test2 <- ?ml(A,B,L); A=1; B=2; .print(L). +!test3 <- L=[X,Y]; ?append(L, [Z], L2); Z=a; X=f; Y=i; .print(L2). // expected // 45 // [1,2] // [f,i,a] On 08/12/2009, at 02:37, Tim Cleaver wrote: > Jomi, > > I have revisited the patch for anonymous variables. This time I have > implemented it against the current public svn version 1561. The > change to Structure.java is the same (although tidied up a bit). > This time, however, I have updated TermTest.java as well. These > changes aim not to change the intent of the tests, only the way they > are carried out (although I may have made mistakes in identifying > their intent, given they aren't named descriptively nor documented). > Most of the changes revolve around moving from using toString to > testing the objects directly using equals and u.unifies. A side- > effect of this is that you can change the way the involved objects > are converted to strings without breaking the tests. > > The test I had the most difficulty in understanding was > testMakeVarAnnon4(). It appears that a unifier is created, a manual > renaming of one of the variables is made and it is tested that this > manual renaming is respected in makeVarsAnnon (i.e. the variable > isn't renamed further). If this is the case, then the new test > doesn't really capture that desired behavior. I think, but maybe > mistaken, that this behavior is inconsistent with solving my > original issue. Just because an unnamed variable hasn't attained a > value in the input unifier, does not mean it shouldn't be renamed. > Just because a named variable has been renamed to an unnamed > variable doesn't mean it does not need further renaming. If you > enforce renaming regardless of previous aliasing, then the old > renaming must be overridden. Thus, manual aliases cannot be > respected. If you ensure that you only rename a variable once given > an input unifier then situations where more than one aliasing is > necessary cannot be accommodated (like that situation identified in > my prior email). > > There is also an additional test that demonstrates the original > problem I was having. The original Structure.java will fail this > test. The patched version will not. The only downside to the new > Structure.java is that more anonymous variables are created than > previously (thus the removal of the count in testMakeVarAnnon3()). > Given the original problem was that not enough new variables were > created, I fail how to see this would be an issue. > > On a related issue, one of the original tests failed (with the new > Structure.java) because no unifier was passed into the makeVarsAnnon > method. Because makeVarsAnnon modifies the input unifier and an > empty default was supplied, the mapping from the old name to the new > was lost when the empty default unifier was discarded. Any attempt > at unification that does not use a unifier with the mapping from old > names to new will fail to assign values to the original variable. > Consequently, I believe that it would be beneficial to change the > interface of Literal.java to remove the makeVarsAnnon() method. This > would make it compulsory to pass in a unifier to this method. Given > clients won't know whether a given Literal will create new bindings > as a result of anonymizing the variables therein, clients don't know > whether to call makeVarsAnnon() or makeVarsAnnon(Unifier u). Most > will go with makeVarsAnnon() assuming it will Do the Right Thing, > not knowing they may lose > information about variable aliases. > > Hopefully this provides more insight into the issue and that a > solution can be arrived at soon. > > regards, > Tim > > > > __________________________________________________________________________________ > See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ > <UnnamedVarAnonymizeFix2.diff> -- Jomi Fred Hubner Department of Automation and Systems Engineering Federal University of Santa Catarina PO Box 476, Florianópolis, SC 88040-900 Brasil http://www.das.ufsc.br/~jomi |
From: Jomi H. <jom...@gm...> - 2009-12-08 12:59:51
|
Dear Tim, thanks for your careful analysis! it isn't indeed a problem that your changes do not pass the jUnit tests. We have a bug to fix and its solution can break not well designed test (as you noted). I am sorry for the lack of doc in the tests. (since ordinary users do not read java tests, we didn't give enough attention to doc in tests.) I tend to agree you all your comments. But I still need to check it deeper. We also have ASUnit (AgentSpeak Unit tests) to test AS programs (and thus the interpreter). And your changes make some of them to fail. That case is worst because their are AS programs with a known and well defined expected execution. If you want to run the ASUnit tests: cd applications/as-unit-test ant test (I hope I have some time tomorrow to see the problem) Thanks again, Jomi On 08/12/2009, at 02:37, Tim Cleaver wrote: > Jomi, > > I have revisited the patch for anonymous variables. This time I have > implemented it against the current public svn version 1561. The > change to Structure.java is the same (although tidied up a bit). > This time, however, I have updated TermTest.java as well. These > changes aim not to change the intent of the tests, only the way > they are carried out (although I may have made mistakes in > identifying their intent, given they aren't named descriptively nor > documented). > Most of the changes revolve around moving from using toString to > testing the objects directly using equals and u.unifies. A side- > effect of this is that you can change the way the involved objects > are converted to strings without breaking the tests. Yes. I agree. > > The test I had the most difficulty in understanding was > testMakeVarAnnon4(). It appears that a unifier is > created, a manual renaming of one of the variables is made and it is > tested that this manual renaming is respected in makeVarsAnnon (i.e. > the variable isn't renamed further). that's it. > If this is the case, then the new test doesn't really capture that > desired behavior. I think, but maybe mistaken, that this behavior is > inconsistent with solving my original issue. Just because an unnamed > variable hasn't attained a value in the input unifier, does not mean > it shouldn't be renamed. Just because a named variable has been > renamed to an unnamed variable doesn't mean it does not need further > renaming. If you enforce renaming regardless of previous aliasing, > then the old renaming must be overridden. Thus, manual aliases > cannot be respected. If you ensure that you only rename a variable > once given an input unifier then situations where more than one > aliasing is > necessary cannot be accommodated (like that situation identified in > my prior email). > > There is also an additional test that demonstrates the original > problem I was having. The original Structure.java will fail this > test. The patched version will not. The only downside to the new > Structure.java is that more anonymous variables are created than > previously (thus the removal of the count in testMakeVarAnnon3()). > Given the original problem was that not enough new variables were > created, I fail how to see this would be an issue. > > On a related issue, one of the original tests failed (with the new > Structure.java) because no unifier was passed into the makeVarsAnnon > method. Because makeVarsAnnon modifies the input unifier and an > empty default was supplied, the mapping from the old name to the new > was lost when the empty default unifier was discarded. Any attempt > at unification that does not use a unifier with the mapping from old > names to new will fail to assign values to the original variable. > Consequently, I believe that it would be beneficial to change the > interface of Literal.java to remove the makeVarsAnnon() method. This > would make it compulsory to pass in a unifier to this method. Given > clients won't know whether a given Literal will create new bindings > as a result of anonymizing the variables therein, clients don't know > whether to call makeVarsAnnon() or makeVarsAnnon(Unifier u). Most > will go with makeVarsAnnon() assuming it will Do the Right Thing, > not knowing they may lose > information about variable aliases. > > Hopefully this provides more insight into the issue and that a > solution can be arrived at soon. > > regards, > Tim > > > > __________________________________________________________________________________ > See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ > <UnnamedVarAnonymizeFix2.diff> -- Jomi Fred Hubner Department of Automation and Systems Engineering Federal University of Santa Catarina PO Box 476, Florianópolis, SC 88040-900 Brasil http://www.das.ufsc.br/~jomi |
From: Tim C. <tim...@ya...> - 2009-12-08 04:37:12
|
Jomi, I have revisited the patch for anonymous variables. This time I have implemented it against the current public svn version 1561. The change to Structure.java is the same (although tidied up a bit). This time, however, I have updated TermTest.java as well. These changes aim not to change the intent of the tests, only the way they are carried out (although I may have made mistakes in identifying their intent, given they aren't named descriptively nor documented). Most of the changes revolve around moving from using toString to testing the objects directly using equals and u.unifies. A side-effect of this is that you can change the way the involved objects are converted to strings without breaking the tests. The test I had the most difficulty in understanding was testMakeVarAnnon4(). It appears that a unifier is created, a manual renaming of one of the variables is made and it is tested that this manual renaming is respected in makeVarsAnnon (i.e. the variable isn't renamed further). If this is the case, then the new test doesn't really capture that desired behavior. I think, but maybe mistaken, that this behavior is inconsistent with solving my original issue. Just because an unnamed variable hasn't attained a value in the input unifier, does not mean it shouldn't be renamed. Just because a named variable has been renamed to an unnamed variable doesn't mean it does not need further renaming. If you enforce renaming regardless of previous aliasing, then the old renaming must be overridden. Thus, manual aliases cannot be respected. If you ensure that you only rename a variable once given an input unifier then situations where more than one aliasing is necessary cannot be accommodated (like that situation identified in my prior email). There is also an additional test that demonstrates the original problem I was having. The original Structure.java will fail this test. The patched version will not. The only downside to the new Structure.java is that more anonymous variables are created than previously (thus the removal of the count in testMakeVarAnnon3()). Given the original problem was that not enough new variables were created, I fail how to see this would be an issue. On a related issue, one of the original tests failed (with the new Structure.java) because no unifier was passed into the makeVarsAnnon method. Because makeVarsAnnon modifies the input unifier and an empty default was supplied, the mapping from the old name to the new was lost when the empty default unifier was discarded. Any attempt at unification that does not use a unifier with the mapping from old names to new will fail to assign values to the original variable. Consequently, I believe that it would be beneficial to change the interface of Literal.java to remove the makeVarsAnnon() method. This would make it compulsory to pass in a unifier to this method. Given clients won't know whether a given Literal will create new bindings as a result of anonymizing the variables therein, clients don't know whether to call makeVarsAnnon() or makeVarsAnnon(Unifier u). Most will go with makeVarsAnnon() assuming it will Do the Right Thing, not knowing they may lose information about variable aliases. Hopefully this provides more insight into the issue and that a solution can be arrived at soon. regards, Tim __________________________________________________________________________________ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ |
From: Tim C. <tim...@ya...> - 2009-12-05 00:10:24
|
Jomi, I had realized that jason had tests, but I admit to neglecting to run my patch through them (no cookie for me :^) ). I apologise for this. I, too, will look into the failing tests and my patch and attempt to fix one, the other or both. I am sorry I wasn't able to explain the problem sufficiently clearly, but now that we are on the same page, I am sure we can find a solution that is beneficial to all. regards, Tim __________________________________________________________________________________ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ |
From: Jomi H. <jom...@gm...> - 2009-12-02 18:24:07
|
Tim, I finally understand the problem! It is the whether R is > [wrapped(_1), wrapped(_1), wrapped(_1), wrapped(_1), wrapped(_1)]. or > [wrapped(_1), wrapped(_2), wrapped(_3), wrapped(_4), wrapped(_5)]. But I need to analyse it more carefully. Your solution seems to introduce other problems (it do no pass in the jUnit and asUnit tests). (it could be a problem in the tests, of course.) Thanks, Jomi On 01/12/2009, at 01:15, Tim Cleaver wrote: > Jomi, > > My understanding is that anonymous variables in prolog work > identically to normal variables except a unique name is generated > for each use. The wrap predicate in the example I provided will > generate in jason: > > wrap([_ | Rest], [wrapped(_) | Result]) :- wrap(Rest, Result). > > wrap([1, 2, 3, 4, 5], Result). > Result = [wrapped(_1), wrapped(_1), wrapped(_1), wrapped(_1), > wrapped(_1)]. > > (or some renaming of. i.e. _7 across the board or whatever). > Although each _1 variable is a unique java unnamed variable > instance, the unifier treats them as the same unnamed variable due > to their same name. See: UnnamedVar.java:clone. > > if (hasValue()) { > return getValue().clone(); > } else { > UnnamedVar newv = new UnnamedVar(getFunctor()); > newv.myId = this.myid; > if (hasAnnot()) > newv.addAnnots(this.getAnnots().cloneLT(); > return newv; > } > > They don't get new names because they don't have a value and their > names are already _1 (or whatever) so new UnnamedVar("_1") > calls into > super(name.length() == 1 ? "_" + (varCont++) : name) > i.e. supplying "_1" to the normal variable constructor. > > Unification bottoms out at getting the value of the anonymous > variables out of a hashmap (see Unifeir.java:unifyTerms:191-192). > Hashmaps use hashcode to test for equality. Since variables and > anonymous variables use the hashcode of their functor as their > hashcode, multiple instances of an anonymous variable with the same > functor will be seens as the same variable. Thus, once one of the > clones attains a value in the unifier, all instances do. I have > attached some JUnit tests that show this. > > Prolog on the other hand (which you can see if you issue the query > "trace." before your query) > will produce: > Result= [wrapped(_1), wrapped(_2), wrapped(_3), wrapped(_4), > wrapped(_5)]. > i.e. unique anonymous variables from the perspective of a unifier > (new anonymous names). > (or some renaming of i.e. _3, _4 etc or whatever). > > The reason p(b,a) = p(_,_) works is that it is equivalent to p(b, a) > = p(_1, _2). again, where _1 and _2 are unknown variable names to > any applicable unifier. The resulting unifier in this instance would > be {_1 = b, _2 = a} obviously. > > This is the behaviour my patch aims to introduce. However, not > knowing what else has changed since 1.3.1, I can't be sure it is > still applicable ;^). Also, I cannot be sure what complications > unifying predicates may introduce and, thus, haven't taken this into > account. Hopefully this helps explain the patch and I apologise if > this is all old news to you. > > regards, > Tim > > > > > __________________________________________________________________________________ > See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ > > > > __________________________________________________________________________________ > Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7. > Enter now: http://au.docs.yahoo.com/homepageset/ > < > Tests > .java > > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev_______________________________________________ > Jason-bugs mailing list > Jas...@li... > https://lists.sourceforge.net/lists/listinfo/jason-bugs -- Jomi Fred Hubner Department of Automation and Systems Engineering Federal University of Santa Catarina PO Box 476, Florianópolis, SC 88040-900 Brasil http://www.das.ufsc.br/~jomi |
From: Jomi H. <jom...@gm...> - 2009-12-02 14:05:46
|
Hi Tim, I agree with your comments. But there is still one thing I do not understand. The rule: wrap([_ | Rest], [wrapped(_) | Result]) :- wrap(Rest, Result). will be renamed to (in the current version and in yours): wrap([_1 | Rest], [wrapped(_2) | Result]) :- wrap(Rest, Result). how does it work that the value given to _1 will unify with _2. e.g. suppose we call wrap([a,b],R). this will initially unify { _1 = a, Rest = R }, _2 and Result has no values. Result and Rest will get values in the "return" of the recursion, but _2 not. So, how _2 get a value? For me, every _ has a unique name, as you said. So the two _ in the wrap rule are two different variables (_1 and _2) that should not unify. Surely I am missing something :-) Jomi On 01/12/2009, at 01:15, Tim Cleaver wrote: > Jomi, > > My understanding is that anonymous variables in prolog work > identically to normal variables except a unique name is generated > for each use. The wrap predicate in the example I provided will > generate in jason: > > wrap([_ | Rest], [wrapped(_) | Result]) :- wrap(Rest, Result). > > wrap([1, 2, 3, 4, 5], Result). > Result = [wrapped(_1), wrapped(_1), wrapped(_1), wrapped(_1), > wrapped(_1)]. > > (or some renaming of. i.e. _7 across the board or whatever). > Although each _1 variable is a unique java unnamed variable > instance, the unifier treats them as the same unnamed variable due > to their same name. See: UnnamedVar.java:clone. > > if (hasValue()) { > return getValue().clone(); > } else { > UnnamedVar newv = new UnnamedVar(getFunctor()); > newv.myId = this.myid; > if (hasAnnot()) > newv.addAnnots(this.getAnnots().cloneLT(); > return newv; > } > > They don't get new names because they don't have a value and their > names are already _1 (or whatever) so new UnnamedVar("_1") > calls into > super(name.length() == 1 ? "_" + (varCont++) : name) > i.e. supplying "_1" to the normal variable constructor. > > Unification bottoms out at getting the value of the anonymous > variables out of a hashmap (see Unifeir.java:unifyTerms:191-192). > Hashmaps use hashcode to test for equality. Since variables and > anonymous variables use the hashcode of their functor as their > hashcode, multiple instances of an anonymous variable with the same > functor will be seens as the same variable. Thus, once one of the > clones attains a value in the unifier, all instances do. I have > attached some JUnit tests that show this. > > Prolog on the other hand (which you can see if you issue the query > "trace." before your query) > will produce: > Result= [wrapped(_1), wrapped(_2), wrapped(_3), wrapped(_4), > wrapped(_5)]. > i.e. unique anonymous variables from the perspective of a unifier > (new anonymous names). > (or some renaming of i.e. _3, _4 etc or whatever). > > The reason p(b,a) = p(_,_) works is that it is equivalent to p(b, a) > = p(_1, _2). again, where _1 and _2 are unknown variable names to > any applicable unifier. The resulting unifier in this instance would > be {_1 = b, _2 = a} obviously. > > This is the behaviour my patch aims to introduce. However, not > knowing what else has changed since 1.3.1, I can't be sure it is > still applicable ;^). Also, I cannot be sure what complications > unifying predicates may introduce and, thus, haven't taken this into > account. Hopefully this helps explain the patch and I apologise if > this is all old news to you. > > regards, > Tim > > > > > __________________________________________________________________________________ > See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ > > > > __________________________________________________________________________________ > Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7. > Enter now: http://au.docs.yahoo.com/homepageset/ > < > Tests > .java > > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev_______________________________________________ > Jason-bugs mailing list > Jas...@li... > https://lists.sourceforge.net/lists/listinfo/jason-bugs -- Jomi Fred Hubner Department of Automation and Systems Engineering Federal University of Santa Catarina PO Box 476, Florianópolis, SC 88040-900 Brasil http://www.das.ufsc.br/~jomi |
From: Tim C. <tim...@ya...> - 2009-12-01 03:16:09
|
Jomi, My understanding is that anonymous variables in prolog work identically to normal variables except a unique name is generated for each use. The wrap predicate in the example I provided will generate in jason: wrap([_ | Rest], [wrapped(_) | Result]) :- wrap(Rest, Result). wrap([1, 2, 3, 4, 5], Result). Result = [wrapped(_1), wrapped(_1), wrapped(_1), wrapped(_1), wrapped(_1)]. (or some renaming of. i.e. _7 across the board or whatever). Although each _1 variable is a unique java unnamed variable instance, the unifier treats them as the same unnamed variable due to their same name. See: UnnamedVar.java:clone. if (hasValue()) { return getValue().clone(); } else { UnnamedVar newv = new UnnamedVar(getFunctor()); newv.myId = this.myid; if (hasAnnot()) newv.addAnnots(this.getAnnots().cloneLT(); return newv; } They don't get new names because they don't have a value and their names are already _1 (or whatever) so new UnnamedVar("_1") calls into super(name.length() == 1 ? "_" + (varCont++) : name) i.e. supplying "_1" to the normal variable constructor. Unification bottoms out at getting the value of the anonymous variables out of a hashmap (see Unifeir.java:unifyTerms:191-192). Hashmaps use hashcode to test for equality. Since variables and anonymous variables use the hashcode of their functor as their hashcode, multiple instances of an anonymous variable with the same functor will be seens as the same variable. Thus, once one of the clones attains a value in the unifier, all instances do. I have attached some JUnit tests that show this. Prolog on the other hand (which you can see if you issue the query "trace." before your query) will produce: Result= [wrapped(_1), wrapped(_2), wrapped(_3), wrapped(_4), wrapped(_5)]. i.e. unique anonymous variables from the perspective of a unifier (new anonymous names). (or some renaming of i.e. _3, _4 etc or whatever). The reason p(b,a) = p(_,_) works is that it is equivalent to p(b, a) = p(_1, _2). again, where _1 and _2 are unknown variable names to any applicable unifier. The resulting unifier in this instance would be {_1 = b, _2 = a} obviously. This is the behaviour my patch aims to introduce. However, not knowing what else has changed since 1.3.1, I can't be sure it is still applicable ;^). Also, I cannot be sure what complications unifying predicates may introduce and, thus, haven't taken this into account. Hopefully this helps explain the patch and I apologise if this is all old news to you. regards, Tim __________________________________________________________________________________ See what's on at the movies in your area. Find out now: http://au.movies.yahoo.com/session-times/ __________________________________________________________________________________ Win 1 of 4 Sony home entertainment packs thanks to Yahoo!7. Enter now: http://au.docs.yahoo.com/homepageset/ |
From: Tim C. <tim...@ya...> - 2009-11-30 08:24:37
|
Jason developers, There is an issue with the renaming of anonymous variables. I have attached an asl file that demonstrates what I see as the issue, a prolog file that demonstrates the expected behaviour, and a patch to be applied to src/jason/asSyntax/Structure.java that fixes the issue. This patch was generated relative to the current (1.3.1) release of jason. To summarize the issue: in a structure, when an anonymous variable is renamed a new instance of the anonymous variable is constructed via clone. However, from the perspective of a unifier these new instances are seen as identical due to them having the same anonymous name. Thus, even in cases where one would expect multiple unique anonymous variables to be constructed, one is left with a single variable (with multiple java instances). If there are any issues with the patch please let me know. regards, Tim Cleaver __________________________________________________________________________________ Last chance to win a Sony entertainment pack thanks to Yahoo!7. Hurry, ends Nov 30. Enter now: http://au.docs.yahoo.com/homepageset/ |