[Cs5500] Smart History probable fix

[Karl Lieberherr]

This is a big relief. Thanks to the contributors. Yes, tonight are the last
two tournaments.

Ravi will administer them according to our schedule.

-- Karl

On Thu, Dec 1, 2011 at 1:50 PM, Madhuvanthi Balasubramanian <
balasubramanian.m at husky.neu.edu> wrote:

> 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