bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Not quite {was: Re: [Bug-gnubg] Double Decisions


From: Roy A. Crabtree
Subject: Not quite {was: Re: [Bug-gnubg] Double Decisions
Date: Mon, 20 Aug 2007 17:28:24 -0400

I will have to agree with the idea, but disagree with the line of reasoning:

   gnubg cannot be assuming that the strengths are equivalent.

i) If gnubg assume the match is (it, it) that gives matched rates and 60% wins
ii) if gnubg assumes it is (it, you) that gives UNmatched rates and maximal verge of winning (80/99%)

iii) But I do not think that it would assume that it is playing (you, you), as I do not think THAT pairing would
    gives wins in the 80-99% region for severely LESS than optimal players.

Either:

a) gnubg is weighting the cube for condition and incorrectly assigning the figure, or
b) it is weighting for condition ii (or others) and recommending the preferential cube so as to up it's match win rate

    which I do not think, as it is to obvious an error to miss

OR:

c) the NNP engine has determined against millions of plays of games that:

    i)  each differing (or ther sum acumulated similar characteristic) NNP PRNG
        has a specific set of characterisitics IT can detect
    ii) that humans can NOT detect (**as easily: Ramanujans for math AND gammon exist**)
    iii) that gives it the ability to use a static tree of equivalence classes
     iv) buried in the NNP DB IMplicitly (not pulled out; as such:

    the game, the engine, the programmers are ALL honest BUT:

       gnubg succesfully "cheats" by having advanced knowledge of the PRNG

              by means of its millions of plays of experience no human will have

     to successfully predict AGAINST a human player

        based on its first 2-4 responses from the player

   as to which equivalence class it should go

   hidden (because of the static nature to the NNP network responses ALWAYS being the same
   to the same position in the same game in the all games in the same match
  (as opposed to being dynamically _differentiated_ based on your previous in-that-game-play)
 
      but NONETHELESS in an effectively different equivalence class

  that WILL respond to the nature of your PLAY on DIFFERENT POSITIONS
  based on its knowledge of WHAT ROLLS WILL OCCUR FROM THE PRNG.

   ALL of this calculated from the plays it HAS had and NOT because the CODE of the engine is dishonest.

You can see it most easily by watching the difference in the win rations form a PRNG to random.org.

And you can tell that random.org IS NOT FULLY RANDOM (look at the bit slicing algorithm that cuts out
long 1/0 sequences), in that the win rate is about 1/3 of the differential your human EXPECTATION

   as an expert gammon player, though perhaps not world class

will se or feel as what SHOULD have been the case as to cube pushes.

ALL of this hidden within the expected values of the relative field strenths of the ratings as given
with charactersitics (AKA "tells") that gnubg can see

     and that a world class player can see gnubg playing, AND AVOID the unstable areas
that a naive player favoring either fair dice or human rolled dice

    these are NOT the same

and hence, EXPECTING this, will play _towards_, and LOSE ground,

  becuse:

    the PRNG and TRNG involved are not those sequences.

And the NNP will ALSO have picked up characteristics in human rolled dice

   the SAME WAY

that most naive players will not see, and will also pick characteristics

   in HUMAN PLAY against FAIR dice as contraposed the rules of backgammon

in the same manner:

    at a sensitivity level (incremental contextual advantages across 4-8 moves)

that a world class player aint' gonna tell nobody he/she already sees.

And uses, to win.

of couse, that is only my ownhumble opinion

  of this rather brilliant piece of SW gnubg:

   it is fooling its own creators quite well...

On 8/20/07, Christian Anthon <address@hidden> wrote:
Hi Peter,

GNU backgammon is a world class opponent and assumes, in a sense at
least, that your and its strengths are equal. GNU backgammon's doubles
are based on this assumption. So while it in a given position would
win e.g. 60% of the games when playing against itself, it is likely to
win e.g. 80% (or even 99%) of the games when playing against you.
Especially in a complicated position like the one you report.

The bottom line is keep studying, for example by enabling the build in
tutor function.

Christian.

On 8/19/07, Peter Carlson <address@hidden> wrote:
> Why does gnu *almost* always recommend to take a double.  I have noticed
> after playing literally hundreds of games against gnu that 99% of the
> time it recommends to take a double it is just plain WRONG!  besides why
> would gnu offer a double if the odds weren't greatly in its favor to
> win???  here is just one example:
>
> Match MBlgARAAAAAA
> Position when 2x offered: bMdCgClwt4MBGA
> Position when I decided to resign: 7x8AAGB2NwiAAQ
>
> Peter
>


_______________________________________________
Bug-gnubg mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/bug-gnubg



--
Use Reply-To: & thread your email
after the first: or it may take a while, as
I get 2000 emails per day.
--

Roy A. Crabtree
UNC '76 gaa.lifer#
(For TN contact, email me to set up a confirmed date/time)
voicemail inbound only

[When you hear/read/see/feel what a y*ehudi plays/writes/sculpts/holds]
[(n)either violinist {Menuhin} (n)or writer {"The Yehudi Principle"} (n)or molder (n)or older]
[you must strive/think/look/sense all of it, or you will miss the meanings of it all]

address@hidden Forwards only to:
address@hidden CC: auto to:
address@hidden Be short < 160 chars cuts off; currently offline
address@hidden CC: auto to ^

http://www.authorsden.com/royacrabtree
http://skyscraper.fortunecity.com/activex/720/resume/full.doc
--
(c) RAC/IP, ARE,PRO,PAST
(Copyright) Roy Andrew Crabtree/In Perpetuity
    All Rights/Reserved Explicitly
    Public Reuse Only
    Profits Always Safe Traded
reply via email to

[Prev in Thread] Current Thread [Next in Thread]