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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
>
>
>
--
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]
[EMAIL PROTECTED] Forwards only to:
[EMAIL PROTECTED] CC: auto to:
[EMAIL PROTECTED] Be short < 160 chars cuts off; currently
offline
[EMAIL PROTECTED] 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
_______________________________________________
Bug-gnubg mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnubg
