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

[Roy A. Crabtree]

You are missing the points I am raising almost enitely;

I will have to repsond in detail later, time pressure s on other track.

 

You need to learn that a program does what it does independent of what anyone THINKS about ot

doing, and oftimes the conceptions ina programmer's head simply do NOT fit what actually DOES occur.

 

This is most especially true in the area of statistical, trandom, and emergent (NNP) programs, whose

properties are NOT well understood as yet; even by those who DO accurately witness what is happening.

 

(Pleae note, audience: since I am only _asserting_ these things, I also have not

 

   vetted, proven, or demonstrated

 

any of the concepts I have outlined:

 

   NO ONE has on any of their argumentata in these discussion.

 

HOWEVER: The behavioral seuqneces I see do NOT match the ASSERTED bwehaviors

that gnubg experts in fact attribute to it.

 

And they DO match what I _do_ hear from witneses that have a more _flexible_
cognitive pattern:

 

   those who in fact do NOT know the program, and DO know _Backgammon_

   (and at times, moresothebetter, do _NOT_ know it);

 

and who _may_ (or may not; to be proven or not, as the case may be, BY EITHER SIDE) in

 

     very specific cases only

 

be

 

     much better witnesses

 

because:

 

    their _observation_ of what actually _does_ happen is NOT predisposed by

 

    their preconception of what _should_ be the case.

 

Note that the verbiage used in rpevious dicussion has _exactly_ that connotation:

 

   The program expert was discussing what the program SHOULD be or do:

 

     NOT what it actually IS or is doing:

 

             by empirical observation.

 

Again, to be vetted or proven.

This is why the naive user is oftimes the best _observer_:

 

       they do not carry preconceptions about themseolves being EXPERTS about a topic

      and do not bias their observations in light of that.

 

BUT: until vetted or proven: my _assertions_ cary exactly the same penalty clause.

 

Unfortunately, experts oftimes do not get this, and go back to detailed descriptinos of

the internals of the program as they understand it without in fact referrin gto the real world performance

or behavior of their field of expertise, and are quite blind to it when it hits them in the face.

 

And getting a contextual shift to see that this is the case is quite difficult.

 

Which is why the real world surprises experts much of the time.

 

More later, gotta handle other affairs.

 

Sorry, Jim: You are missing the points I am raising.

 

You see, the exact same comments are in fac trelevant AND revenant from a forensic point of view for ANY program that "learns":

 

    including those modified over time by programmers to fix or improve them ("learning").

 

Causal feedback loops across the boundary domain of reality to intenal cognition are

 

  co-impactted

 

by these processes.  Otherwise the program would not _learn_ from it.

 

More later.

 

Am I right here?  No tproven, maybe not so:  but if you think that the computer world

does not do this in the human world, ... you will be continually surprised by outcomes.

 

Cheers.

royc.

On 8/21/07, Jim Segrave <address@hidden> wrote:

On Tue 21 Aug 2007 (13:31 -0400), Roy A. Crabtree wrote:
> Some responses; most of what you said I concur with, but NOT most
> of your conclusions.
>
> To reiterate: gnubg is a great result.  Keep on keepin' on.

Thanks.

I have a great deal of trouble actually reading your responses, they
often seem to have sections missing or almost appear to be two
different blocks of text interleaved.

As far as I can tell, you have some serious misapprehensions about
gnubg (and most other bg programs as well.

First gnubg uses three external sources of information:

A table of weights, which determine the behaviour of the neural nets
gnubg uses to evaluate the probable outcome of a game (played without
the cube) given a particular position of the chequers.

A match equity table (MET), which gives the match winning chances for a
player at a given match score. All of the METs provided with gnubg
assume that both players are equally strong. An interested player
could attempt to make a MET for unequal players - I believe Walter
Trice has explored what such a table would be like. I am not aware of
any such tables being available, but if one is, it could be put into a
format such that gnubg could use it.

A bearoff database which gives the probable number of rolls to clear
all a player's pieces off in non-contact positions. As shipped, gnubg
has such a database for all the player's pieces in his
homeboard. Larger tables, allowing the player's pieces to be on more
points are available for download and gnubg can use them. Experiments
indicate that the neural net is so accurate for this type of race that
there is little purpose served in using them.

These are the sole external data sources for gnubg which can cause its
play to be altered.

Gnubg has no provision for updating any of those sources of data - it
can read them, it will never write them.

Gnubg has a small number of neural nets, each optimised for a
particular type of position - racing (non-contact), contact, crashed
(the player's home board is collapsing). It has a smaller neural net
which is generally used to produce a rough and ready estimate of what
the full net will produce. This is used to prune away un-promising
moves to make evaluations faster.

The point of all this is that gnubg's behaviour is set when the above
data sources are attached to the program. Given two machines running
gnubg, as long as both use the same neural net weights, MET and
bearoff database, then both copies will play identically. They will
_always_ play the same way, no matter if they lose 100,000 games in a
row. Gnubg's behaviour is static in that sense. It does not learn, it
does not adapt, it does not get better, it does not get worse.

It does not have some database of neural net responses or whatever you
were trying to suggest in your posting.

It does not choose moves using a neural net.

It does not make cube decisions using a neural net.

The only thing it does with the neural nets is estimate the
probability of the various outcomes given a particular arrangement of
the chequers.

The choice of move is done by examining the nn outputs for the
position resulting from each of the possible legal moves, then for
each of the better ones of those, the possible dice rolls and moves
for the opponent, for each roll, it tests the resulting position again
and calls the neural net for a new estimate. Eventually, it chooses
the move giving the highest equity for itself

Similarly, the cube decision is made by examining all the possible
rolls that could occur and the resulting best position for each roll,
eventually leading to an expected value for the winning/gammon/bg
chances before the dice are rolled.

At no time does gnubg have any information about forthcoming rolls,
even when using one of its own built in random number generators.

There is no code in gnubg to analyze the supplied random numbers to
see if there is some possibly useful statistical bias.

There is no code in gnubg to analyse its opponent's play to allow it
to alter its estimate of the win/gammon/bg/lose/lose gammon/lose bg
chances.

It is static and, given the same dice rolls it will play the same game
forever.

The neural nets can be trained to generate new weights for the various
nets. Training is done using separate software derived from, but not
identical to, gnubg's. Effective training involves rolling out
positions tens and hundreds of thousands of times to get sufficient
information to allow adjusting the weights. Even if gnubg were
adaptive, even the most fanatical player couldn't play enough games to
produce any perceptible change in gnubg's weights, and hence it's
style of play.

In short, gnubg is about as dynamic as your average housebrick.

--
Jim Segrave           address@hidden

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