Game theoretically, the outcome of a game is determined by four factors: 1) 
skill of player A, 2) skill of player B, 3) luck of player A and 4) luck of 
player B.  
When two players of equal strength play a game, 1) and 2) cancel out, and the 
outcome is solely determined by 3) and 4).

Although Gnubg's neural nets are not 100% perfect and although Gnubg calculates 
'luck' slightly different than 'skill', the above holds in practice quite well. 

Since the end result of your session was close, I assume that you let Gnubg 
play Gnubg on equal settings... Try it again with unequal settings (e.g. Expert 
vs Beginner) and you'll see that bad luck can be compensated by skill (and vice 
versa).


--boomslang


--- On Sun, 6/9/09, Adi Kadmon <[email protected]> wrote:

> From: Adi Kadmon <[email protected]>
> Subject: [Bug-gnubg] GNU's "luck-measure" seriously questionable
> To: [email protected]
> Date: Sunday, 6 September, 2009, 1:20 PM
> Hi all,
>  
> Backed by further analysis, I still insist (see my mail
> from 14 August) that GNU's luck measure lacks practical
> value.
>  
> I made a money-sessoin match to 100 points with GNU, cube
> included, without Jaccoby rule. It ended 101:90 to GNU, and
> consisted of 120 single games. I analyzed the whose session
> with 2-ply Supremo. Then I checked carefully and found out
> that in all 120 games (without a single exception!) the side
> who won the game had the better (or less bad) numerical
> luck-measure.
> 
>  
> Combined with my previous analysis of 29 single games with
> a human opponents, which yielded a similar result (29 out of
> 29), this suggests that the correlation between GNU's
> luck-measure and a game's result is 1 or very-very close
> to 1. Given this, I can see no value in the existing
> (04-2009 version) luck-measure, which should have left at
> least some room for skill as a determinant in a game's
> result.
> 
>  
> I can attach the above-mentioned session-file for the
> readers to check for themselves, if anyone could give me an
> address where my mail with an attachment won't be
> "rejected".
>  
> -- Adi
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> Bug-gnubg mailing list
> [email protected]
> http://lists.gnu.org/mailman/listinfo/bug-gnubg
>






_______________________________________________
Bug-gnubg mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnubg

Reply via email to