[Cs5500] Smart History probable fix
Karl Lieberherr
lieber at ccs.neu.edu
Thu Dec 1 14:35:05 EST 2011
I was told that the run-time-stack-overflow might happen for a very
unbalanced tree only: the decision tree for
HSR(100000,1).
Was such an unbalanced tree in the game?
-- Karl
On Thu, Dec 1, 2011 at 2:06 PM, Tugba Koc <tkoc at ccs.neu.edu> wrote:
> Hi Madhu,
>
> I run test tournaments for both MMG and HSR. I made the changes that Asish
> sent and smart history looks fine. For HSR I changed MaxN to 100000. I
> didn`t get any exception but I run tournaments with baby avatars. I think I
> should also run them with teacher avatars. From where can I get teacher
> avatar?
>
> Thanks,
>
> Tuba
>
> ----- Original Message -----
> From: "Madhuvanthi Balasubramanian" <balasubramanian.m at husky.neu.edu>
> To: "Ahmed Abdelmeged" <ahmed.mohsen at gmail.com>
> Cc: "Karan Bhat" <bhat.k at husky.neu.edu>, "Managing Software Development" <
> cs5500 at lists.ccs.neu.edu>
> Sent: Thursday, December 1, 2011 1:50:53 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [Cs5500] Smart History probable fix
>
>
> Hi guys,
>
>
> I made both changes that Ahmed proposed and ran a bunch of MMG
> tournaments. The smarthistory files are back to the proper way they were
> (with one set of responses for every claim).
> I've committed both changes to the repository and the revision # is now 76.
> I'm going out on some personal work, so could someone please run HSR
> tournaments too, on this version and make sure the changes are consistent?
> I believe we have both HSR and MMG tournaments coming up soon.
> Thanks Ahmed.
>
>
>
>
>
>
>
> On Thu, Dec 1, 2011 at 1:09 PM, Ahmed Abdelmeged < ahmed.mohsen at gmail.com> wrote:
>
>
> That's exactly the issue. However, I disagree with the solution.
> According to the "standard/default" mmg configuration below, proposed
> claims need not necessarily be new.
> scg_config[
> domain:mmg.MMGDomain
> protocols: scg.protocol.ForAllExistsMax
> tournamentStyle: full round-robin
> turnDuration: 60 //seconds
> maxNumAvatars: 20
> minStrengthening: 0.0000000001
> initialReputation: 100.0
> maxReputation: 1000.0
> reputationFactor: 0.4
> minProposals: 1
> maxProposals: 1
> numRounds: 5
> proposedClaimMustBeNew: false
> minConfidence: 0.5
> ]
> mmg.MMGConfig {{ mmg_config[ ] }}
>
> In fact, it is unfair to enforce claims to be new when we know that there
> is one optimal claim. Furthermore, it is impossible to enforce claims to be
> new when the domain has a single claim.
>
> The fix I'm proposing (which is essentially a completion of the
> IdentityHashMap fix) is to use reference equality for claims rather than
> semantic equality (i.e. the .equals method). The IdentityHashMap uses
> reference equality but HashMap uses "equals". There is another spot in
> smart history where claims are compared using "equals"
>
> public void updateClaimWithResponse(IdentityHashMap<Claim, Claim>
> newClaimOriginalClaim, Claim claim, ProtocolResponse response,
> RemotePlayerProxy avatar)
> {
> if (newClaimOriginalClaim.containsKey(claim))
> {
> claim.getInstanceSet().toString();
> Claim originalClaim = newClaimOriginalClaim.get(claim);
> for(ClaimWithResponse claimWithResponse : loc)
> {
> ==> if(claimWithResponse.getClaim().equals(originalClaim))
> {
>
> AnnotatedResponse aResponse = new AnnotatedResponse(new
> verbatim(avatar.getOpponent().getName()), response);
>
> //AnnotatedResponse aResponse = new
> AnnotatedResponse(new verbatim(avatar.getName()), response);
> List<AnnotatedResponse> responses =
> claimWithResponse.getResponses();
> responses = responses.append(aResponse);
> claimWithResponse.setResponses(responses);
> }
> }
> }else{
> System.out.println("debug");
> }
> }
>
>
> Changing it fixes the issue.
>
> A second issue I had was that avatars get into an infinite loop on
> proposing claims. I had been using a configuration file that requires
> players to propose 5 claims each time. The propose method can be rewritten
> with the knowledge that 1. proposed claims need not be new. 2. maxProposals
> is 1.
> public List<Claim> propose(List<Claim> forbiddenClaims) {
> List<Claim> claims = List.create();
> SCGConfig scg_cfg = config.getScgCfg();
> int maxProposals = scg_cfg.getMaxProposals();
> for(int i=0;i<maxProposals;i++){
> Claim claim = generateRandomClaim();
> // While loop commented out by Ahmed
> // there is a single claim in mmg as a result this while loop
> goes for ever
> //while(forbiddenClaims.contains(claim) ||
> claims.contains(claim)){
> claim = generateRandomClaim();
> //}
> claims = claims.append(claim);
> }
> return claims;
> }
>
> private Claim generateRandomClaim() {
> //Random r = new Random();
> return new
> Claim(MMGInstanceSet.getInstance(),ForAllExistsMax.getInstance(),0.61d,1);
> }
>
>
> I'm currently investigating two more issues regarding strengthening and
> agreement.
> Would Madhu or Karan apply these changes and may be double check this fix
> first?
>
>
>
>
> On Thu, Dec 1, 2011 at 2:53 AM, Ashish Joshi < joshi.as at husky.neu.edu >
> wrote:
>
>
>
>
> Hey guys,
> figured out the problem with the smart history
> The baby avatar is not generating random claims
> It always generates 0.61 for some reason
> It wasn't the case in the earlier version where it used random.nextdouble()
> Also the strengthened claim is nothing but original claim + min
> strengthening
>
> So in binarygame.java when a new claim (strengthened claim, original
> claim) is added to the hashmap newClaimOriginalClaim
> Those map to the same claim
> since each entry in the hash map is the same
> original claim => 0.61
> strengthened claim => 0.61+minstrengthening
>
> Hence in the smarthistory.java
> all new responses are appended to the response belonging to one claim
> and hence we see the appended response in the smart history file
>
> Use the following as the generateRandomClaim method in the avatar
>
> private Claim generateRandomClaim()
> {
> Random r = new Random();
> double d = r.nextDouble();
> //return new
> Claim(MMGInstanceSet.getInstance(),ForAllExistsMax.getInstance(),0.61d,1);
> return new
> Claim(MMGInstanceSet.getInstance(),ForAllExistsMax.getInstance(),d,1);
> }
>
> I've just tried it with the baby avatar
> If madhu/karan have the teacher avatar...they could try it with a couple
> of teachers and a baby
> We could check it in as the fix
> Attaching the smart history files I generated while hosting a tournament
> locally
>
>
> --
> Cheers
> Ashish Joshi
>
>
> _______________________________________________
> Cs5500 mailing list
> Cs5500 at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/cs5500
>
>
>
>
> --
> Ahmed
>
>
>
>
> --
> Thanks
> - Madhu
>
> _______________________________________________
> Cs5500 mailing list
> Cs5500 at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/cs5500
>
> _______________________________________________
> Cs5500 mailing list
> Cs5500 at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/cs5500
>
-------------- next part --------------
HTML attachment scrubbed and removed
More information about the Cs5500
mailing list