🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.chess
Article #1501

book algorithm, Machack IV game

#1501
From: David F. Cox
Date: Wed, 09 Oct 2002 08:16
96 lines
5150 bytes
I am sorry if this is all been said before. It occurred to me many years
ago, after seeing McHack IV in operation at IFIP Edinburgh, around 1968. I
gave up chess decades ago after playing through a Samuel Reheskvy? game,
played at age 8 as one of 40 blind simultaneous games.

There are less than 256 moves possible from any given chess position. One
byte can represent 256 possibilities. So, for any given position, we can
store the best known move in only one byte.

How do we find that byte? We convert the position into a number, and use it
as an array index.

There are zillions of possible positions, how can we store an array that
big?

We can't (yet). So we concentrate on the interesting positions, ones that
are probably reachable, and not obviously a foregone conclusion. We do that
by evaluating a position and coming back with a number which gives the
estimated value of the position. 1 a certain win, 0 a certain loss, .5 a
probable draw. We throw in as many factors as we reasonably can to give an
evaluation to many places of decimals, even though such precision is
meaningless. We multiply this answer by a big number to get an long integer
result, and we use this long integer to identify a byte on a storage media.
That byte will either be zero (ain't been here before) or a byte indicating
which move to selected from the ranked assessment.

To make clear. The computer evaluates a position to determine its value. It
looks at the retrieved byte.It also evaluates all possible moves and ranks
them by value.  If the retrieved value is 0 or 1 it stores 1, and makes its
best assessed move. Otherwise it picks the move related to the ranking. The
byte says 15, it takes what it assesses as its 15th best move.

If the computer loses the game it backtracks to where it is obvious that it
had gone wrong, and increments the byte there to indicate to try the next
move in the list next time.
In this fashion the computer, by playing itself, can easily build and
opening book that runs into the giga region.

Since the evaluation method would have to be extremely poor for the worst
possible assessed move to actually be the best, we can cut down on the
number to consider. If we take it that the best move is somewhere in the top
16, 32 or 64 it gives us spare bits in the byte which could be used for
other purposes. One use which may be essential, is to use these as check
bytes, related to the "where did we come from" position, to eliminate
aliases.

We can obviously check the byte index identifying algorithm against the
biggest database  of chess positions available.

-------------------------------


Machack IV played the human strategy of once it was materially ahead it
would endeavour to swap off and head for the endgame. Unfortunately it was
poor on the endgame. I thought it would perform far better with sacrificial
openings. Fate proved my point.

In order for it to play more quickly the operator would switch down the
look-ahead. In one game this lead to its opponent gaining an early
advantage. I cajoled the operator into upping the look ahead once it became
obvious that the computer was losing. The result was this game, that I love,
despite the obvious deficiencies in play.

1   P-K4   P-K4   (that was how we wrote it back then)
2   P-KB4  P*P
3   N-KB3  P-Q3
4   B-B4   P-KR3
5   P-Q4   P-KN4
6   N-B3   P-KB4
7   O-O    N-QB3
8   R-K1   P*P (K5)
9   R*P    B-K2
10  N-KR4  N-KB3
11  N-Q5   N*R
12  Q-R5   K-KB1
13  N-B6

Black's position appears hopeless. Mate on the move is threatened. But
MacHack IV has stepped up a gear.

13  -         P-Q4
14  KB*P   B-K3
15  B*B    Q*P CH

At this point I clutched the poor wretches arm, and said "You've lost" In
the computers place I would have sacrificed my queen and smother mated with
the knight.The computer has no eye for the spectacular, and does it more
eficiently.

16  B-K3   Q*B Ch
17  K-R1   N-B7 CH
18  K-N1   N-Q8 CH
19  K-R1   Q-K8 Mate

David F. Cox
bigdjiver@netscape.net
Technical Details
Message-ID: <nzRo9.1003$Uh4.35669@newsfep2-win.server.ntli.net>
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!213.56.195.71!fr.usenet-edu.net!usenet-edu.net!proxad.net!proxad.net!newspeer1-gui.server.ntli.net!ntli.net!newsfep2-win.server.ntli.net.POSTED!53ab2750!not-for-mail

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 10d71d,89c73344086c2f38,start
X-Google-Attributes: gid10d71d,public
X-Google-ArrivalTime: 2002-10-09 01:14:14 PST
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!213.56.195.71!fr.usenet-edu.net!usenet-edu.net!proxad.net!proxad.net!newspeer1-gui.server.ntli.net!ntli.net!newsfep2-win.server.ntli.net.POSTED!53ab2750!not-for-mail
From: "David F. Cox" <bigdjiver@netscape.net>
Newsgroups: gnu.chess
Subject: book algorithm, Machack IV game
Lines: 99
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <nzRo9.1003$Uh4.35669@newsfep2-win.server.ntli.net>
Date: Wed, 9 Oct 2002 09:16:42 +0100
NNTP-Posting-Host: 81.26.107.40
X-Complaints-To: abuse@ntlworld.com
X-Trace: newsfep2-win.server.ntli.net 1034151251 81.26.107.40 (Wed, 09 Oct 2002 09:14:11 BST)
NNTP-Posting-Date: Wed, 09 Oct 2002 09:14:11 BST
Organization: ntl Business News Service