[Top][All Lists]

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

Yes, it does cheat {ws:Re: How about docs on gnubg's net engine? (it c

From: Roy A. Crabtree
Subject: Yes, it does cheat {ws:Re: How about docs on gnubg's net engine? (it cheats !) {wa: Re: [Bug-gnubg] Searching for "BKG—A Program that Plays Backgammon"
Date: Fri, 15 Sep 2006 15:43:23 -0400

Thanks for the quick response: more below:

On 9/15/06, Albert Silver <address@hidden> wrote:
> As a side kvetch: Iws looking on gnubg's site for refs to the internal NNP
> engine, did not see them.
> Is this only in the code, or is there a white paper somewere I was too blind
> to see?


Be sure to change the Concise option (bottom left) to Full


Want the hardest opponent and need the most info; but this is simply to see what the engine
does relative to NNP possibilities.

Its a good program.

> By the way, the engine (more correctly, the learn-ed net) us much more
> clever than you may think:
> It has succesfully "hidden" the several ways it "misleads" players into
> traps, including "cheating"***:
>    It plays the _players_ as much as it plays the _game_.  It uses the
> players "tells":
>        game strategy shifts based on conistently flawed playing.

Could you give an example where it plays a different move from the
best one it found, so that it played against a flaw in the player's

1) It changed cubing on the basis of my play to where beavering would ALWAYS trigger to max
    on my initial proffer.  Match basis.  Which I have to proof/prove to you at least via screenshots;

     which would still not proof either faking on my side or alteration of the net inside or
     other perturbations. Harder to document averrably when remote.

2)  I will have to review the replay of saved games and document with screenshots; I have already had one play sent in
    with an end game variance (the "bug" under my name) that was different on arrival (pipcount sufficed to disaver)
    from what I saw.  More as I have it.

3) What does the engine do on equivalent moves?  (They occur often).

    If the engine is deterministic and single thread fixed order selective, then I assume any variant move
    on a fixed net with fixed game sequences (dice reinput) would prove the assertion something untoward was
    happening:  though this _should_ prove to you that the SW is in error during my execution (Or I am faking/lying),
    or to me that a viral attack (external third party having nothing to do with gnubg.

More to the point:

A)  What should be looked at would be two different games, matches, sessions, across two different
   oppositions (me as one, you as another, for example) where gnubg played a different result for the same position
   and roll WHEREVER in the roll sequence it ever occurred.

B) Against all such history.

C) Another are would be to check to see if roll play against game backup at a point of play
    has any deterministic sequence: since the rolls change when you back up, there will
    be a different play coming on each different roll.

      The deterministic pattern (where the net can "hide") is at a game backup

             to see alternative play which should maintain probability over short and long sequences,
             and have a hump in the mid region

      which can be seen is:

              of gnubg throws a roll a novice would or might say is cooking the dice

                           back up the game
                           force a reroll

                                 play to end but not final bearoff

                                      o as to see who wins

                           then back up to each "unfair" roll point and reroll

                                      to determine who would likely win by _playing_

                            and then compare against _random_ roil ordering

             and note if the following pattern erupts at each such point:

                    At at least three levels (of 3/9/27 rolls maybe deeper)

                    where the start of each level is not synched: they are aphasal

                          so that a loss of gnubg at the level above would trigger the lower level
                          already PAST the point of winning back or re-gaining the loss or more

                     see if you do or do not see:

                                 2 of 3, 5-6 of 9, 14-18 of 27, with the other chances half tie, half loss

                     of rolls that _win_ for gnubg

                                 (all of which to this point is roughly possibly normal by position & chance)

                    BUT that occur 75-95% in the order:

                                 win, win, loss/tie
                                 (2/3rs of 5-6) win, (balance of 5-6 of 9), (balance of loss/tie)
                                 (2/3rds of 14-18 of 27) ((2/3rds of remaining wins) some of the remaining wins to 18),
                                          (the rest of the wins,mainly losses) to 27.


                         the top level occurs where the naive players state "unfair!" about 3/2s more probably than
                                   positions and chance would dictate FOR THAT ORDER (win, win, loss/tie)

                        the second level 2/3rds of that difference, the third 4/9ths of the difference.

       Or thereabout.

If you do not see the pattern: it is different than what I observe:

When a major game shift occurs, it will almost 100% of the times

     at those points a naive player might cry "unfair!"

     the next 1-2 rolls have a highly probable result of still gaining most of the gain

            deterministically, with the 2nd-4th alternative roll being loss/tie

      and so froth.

     This is not a random sequence: it is the net successfully synching and triggering

        on a hidden characteristic of the PRNG

    This also occurs on the random.org sequences, at about 75% of the probability.

        Which means there is still a characteristic in that data at a less reliable chance

                  of recognizing and triggering.
  Since this occurs at the point of backup/replay, the only way to show it woud be to

      trap and save over the entire game

             all of such alternatives
             to see that the rolls fall in such an order

     and to do this across many games

because; gnubg does not log the alternative plays or the PRNG string: you would have to
know the entire match sequence and method/seed to be able to see this.

Or a massive effort of Save's to reduce and analyze.

IF present and not due to the game itself: I reiterate:

       I have a viral attack sequence going on at that level of expertise:

                and trapping the dice roll of a particular game is a trivial event for a hacker.

I also hate the fact that I cannot choose my seeds: the game on Windows overrules and uses the system clock.

So I cannot replay by regeneration using exactly the same setup.

Is there a method to generate and save the dice roll sequence fro the PRNG method/seed as a whole?

    If not, then a "hiding" point exists.

All of this is not possible at all if the net has no hysteretical properties.  Or: should not be.

>              Second kvetch: Am I incorrect in assuminhg that the net is not
> locked during successive plays?
>                   That it learns in the current match as well?

No, it doesn't learn during the match, so your assumption is correct.

   My assumption was that the net was NOT locked.  So I was wrong.  (I always note when I blow it).

     To be clear, you are saying (or are you saying?):
     a) It does not learn within a single game.
     b) I does not learn across games in a match.
     c) It does not learn across matches or sessions.
     d) It does not learn from repeated dice sequence characteristics or player's play sequences
          ***  I expect you to say this one is not the case: it does, but only when explicitly triggered.
     e)  It only learns when an explicit net update is triggered

       so a combo of d & e would be required to see the characteristics I am asserting.

     f) so, therefore, since i have denoted i have not explicitly triggered any such learning,
        the play should be invariant and not change over time, based on my repeated
       gaming play across matches or sessions.

    Which I note; I m NOT doing (unless there is an options sequence to turn this on
     in the background across matches).

    If in any sense it DOES learn, then this is still a possibility.  But not unless so.

>                  (There is an outside posibility I Have a viral trap
> catching the dice throws covertly)

Allow me to quote from my tutorial:

You miss my explicit point, let me be more explicit:

I HAVE HAD and AM HAVING a viral penetration attack on my laptop as well as against
external resource such as my bank accounts (current ones are down $2500, previous ones of
35 years residency I LOST losing $1500 and going redlined on credit card, checking, and savings fro the attacks).

NOT a trivial skulking hacker: one, or a group: that is half proficient.

(I have 3 decades IS./IT experience, SAG level 4+, I was dealing with MAC (mandatory
access controls) by 1982: the attacks are easy to spot but occur in places I have
no access to rectify; and banks are notorious reluctant to admit the  gaping
security holes they have, or the methods known that are in use  ongoing;
false charges and money changing hands makes money: for the vendors, credit cards,
and fiduciary/holding institutions).

"By far, the most common complaint seen about all backgammon software,
weak or strong, is that it must be cheating to get so lucky. Most of
these complaints stem from a lack of understanding of probabilities,
and how skillful play will affect luck or the possibility of lucky

Repeating it will make the comment no more true or false,
and no less or more applicable to a particular circumstance.

I have a degree in systems analysis and statistics.
And I _am_ aware of such things:

my suggestion would b that you open up your analysis of such events to a
signal triggered Markov chain model, and seek to prove that no
context dependent triggered event  _Can_ exist.

Which you may have a problem doing with PRNG dice.


Probabilities are what rule supreme in backgammon. As there is indeed

Only when _probability_ is actually supreme:

   which is not always the case with backgammon.

   It is only _probably_ the case:

   I) Real dice are not random. There are characteristics present in all dice throw
      sequences that can be made use of: at least to notice them.

       Watch craps table if you disbelieve.  And yes this is unfair throwing.


    II)  Naive players specially can throw the cups unfairly:  by _instinct_
         and _unconsciously_.

               Expert players can and does do this trivially:

                    i) teaching the proper method.
                    ii) players privilege when spotted as intentional or simply as desired.

    III) expert dice rollers can do this intentionally; albeit "II)" above rules
        in all such games.

    IV)  True random sequences are had to come by.

          Those that are are fairly trivial to seed with weeds that are hard to detect
           from the outside after the fact, unless you are a cryptographic expert.

    V)  Non deterministic sources are not necessarily random: they are just not
        deterministic.  Stochastic analysis oftimes shows recognizable patterns:

         so long as these are not _recognizable_ in time to be _utilizable_,
         there is no problem.  However:

               a signal sequence that has
               a 60% chance of being recognized _in_time_
               for a 55% chance to be _triggered_ or _used_
               for a 1-5% increase in chance of overall winning
               in a backgammon game

               on a 1-5 roll recognition length, 1-3 roll trigger sequence, and 1-3 roll usage sequence

        would easily be sufficient to gain a staggering win over any player not seeing them coming

               because of not knowing the rolls being predetermined
               (subsetted from 1/36th chance of any roll at all)

        and if this is only a 1-5% chance of being there to recognize, it is enough for
        any play above expert to almost certainly (in unstable positions especially)

               to gain the match win.

               Against a player (human) who does not or cannot see them.

    V) even fairly thrown human dice are not uniform random:  this is a known fact.

    VI) A true random source can easily be seeded with weeds that are nearly impossible
       for a _human_ to detect: a neural net will pick up on it.  Over millions of plays.

an uncontrollable luck factor, one cannot guarantee a victory or loss
no matter how stacked up the chances are. So, good backgammon strategy
is designed to maximize the good rolls for the playing side, and
minimize the good rolls for the other side. In other words, after the
best play, there will be less good rolls for the other side. If the
other side doesn't realize what is happening, then it will seem like a
never-ending streak of bad luck. It's not; it's the consequence of
good playing."

Not in cube play.  The best gammoners work
to generate board positions that look even
and look stable, but that are not,
to cause the less adroit ones to push the cube
way past what is a stable gain point.

And similarly so in various positions i match or betting play:

   when you are losing knowing HOW
   to take chances is your only realistic chance of winning:

      to push the winning player out of that position.

Now, world class players will sometimes choose to lose a match or series
in order to avoid letting go of "tells" and in order to maximize
the chance of winning the _next_ match or series.

    That is also optimal play.
    But seldom in a betting match when down by large pip cost.

      ( I am way to chicken to engage at 10 an above; I haven't the funds to cover such
        even within classical cube play).

I have had gnubg at 12488 in betting play on two games:

    the penultimate version kept beavering.

Again, I note; I have a viral intrusion problem. SO I do not trust this.

Not as an excuse: gnubg beats me on usual sequences fairly easily:

    I doubt I am more than 1800 on its scale.

          (I would need to maintain two FIBS accounts to prove that:

               one for learning play against players
               one for match/winning play against players.)

      You can see me as royc on FIBS.  _learning_ play.

Bright people are the most easily buffaloed ones in Vegas.

And in the a of gamesmanship strategic tactical analysis of stochastic processes such as

    games of  "chance".



If you really ant to see how expert you are, try this as a random throw generator,
train gnubg on it and see how good your rating is:

     Throw any dice you choose. once
     each time you throw a die, it adds one to the usage count for that roll.
     Next time on next turn you are constrained to use on of the N _least_ used dice.

         N starts at 36-18.  Pick a rule, I suggest 35.
         Each F moves the number N is decreased from (1-35) by 1-D

     F is any sequence you wish I suggest integers to start, and the Fibonacci as a later test.

             Integers: The least used (35,34,33,32,31...) at each successive move.
             Fibonacci: The least used (35,35,34,33,32,31,....) at move moves 1,234,6,9,14...

     Summary form: a decreasing set of probabilistically constrained possible dice.

    I guarantee you gnubg will learn to beat you in this game so badly it will sting.

But I also guarantee you that a human bg novice will have a fair to middlin chance to embarrass you as well.

Roy A. Crabtree
UNC '76 gaa.lifer#11086
Room 207 Studio Plus
123 East McCullough Drive
Charlotte, NC 28262-3306
336-340-1304 (office/home/cell/vmail)
704-510-0108x7404 (voicemail residence)


(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]