[Cs5500] Smart History probable fix

[Madhuvanthi Balasubramanian]

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
-------------- next part --------------
HTML attachment scrubbed and removed