[Cs5500] Smart History probable fix

[Tugba Koc]

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