Re: oldie but goody
Posted: Sat Jun 13, 2020 5:36 pm
This is exciting news.
History is unfolding in our very eyes
History is unfolding in our very eyes
One more thing to solve is a book file.Dann Corbit wrote: ↑Sat Jun 13, 2020 5:36 pm This is exciting news.
History is unfolding in our very eyes
Code: Select all
book.f c ******************************************************************
book.f c * *
book.f c * book search the chess library of book moves for a *
book.f c * response to the opponent's last move. in most cases, there *
book.f c * will be severalmoves to choose from. the program will choose *
book.f c * a random move ignoring any 'poor' or '?' type moves that may *
book.f c * be present. this feature provides variety so that it is *
book.f c * more difficult to find an area of weak play and captitalize *
book.f c * on it over and over. due to the structure of the book data *
book.f c * base, this routine will never require over two i/o operations *
book.f c * to find a response making it very effective as a time-saver. *
book.f c * a seperate program is used to construct the library of *
book.f c * moves to keep unnecessary programming code out of the prime *
book.f c * chess playing program. *
book.f c * *
book.f c ******************************************************************
Code: Select all
C * XXXXCCCC PPPPTTTT DDDDDDDD SSSSSSSS *
C * *
C * XXXX = UNUSED *
C * *
C * CCCC = CAPTURED PIECE (0=NONE) *
C * *
C * PPPP = PROMOTION PIECE FOR PAWN PROMOTIONS (0=NONE) *
C * *
C * TTTT = MOVE TYPE AS FOWLOWS: *
C * 1 = NORMAL MOVE *
C * 2 = CA8TLE KING-SIDE *
C * 3 = CASTLE QUEEN-SIDE *
C * 4 = ENPASSANT PAWN CAPTURE *
C * 5 = PAWN PROMOTION (USING PPPP) *
C * *
C * DDDDDDDD = DESTINATION SQUARE *
C * *
C * SSSSSSSS = SOURCE SQUARE *
C * *
C ******************************************************************
Code: Select all
c ******************************************************************
c * *
c * extrct is used to decode the compressed move that is *
c * generated by the various move generators. the move is kept *
c * in the following 23-bit form except when being analyzed: *
c * *
c * mmmcc ctttdd ddddds ssssss *
c * *
c * mmm = moving piece *
c * *
c * ccc = captured piece (0=none) *
c * *
c * ttt = move type as follows: *
c * 0 = normal move *
c * 1 = castle king-side *
c * 2 = castle queen-side *
c * 3 = en passant pawn capture *
c * 4 = pawn promotion to knight *
c * 5 = pawn promotion to bishop *
c * 6 = pawn promotion to rook *
c * 7 = pawn promotion to queen *
c * *
c * ddddddd = destination square *
c * *
c * sssssss = source square *
c * *
c ******************************************************************
Code: Select all
COMPUTATION TIME WAS 3:13
YOUR MOVE, HERC03
S
MOVE: 3 BOOK: 0 EXPECTED: 1
DEPTH: 7 TIME: -24:36 RATIO: 2.4 EVAL: 74
NODES: 632835 EVALS: 334647 LOOKUPS 2X TABLE 100X
RF8-B4 RC1-G5 RB4:C3 RB2:C3 RH7-H6 RG5:F6 RD8:F6
YOUR MOVE, HERC03
D
BLACK
(R) (N) (B) (Q) (K) * + (R)
(P) (P) (P) (P) * (P) (P) (P)
+ * + * (P) (N) + *
* + * + * + * +
+ (B) + :P: :P: * + *
* + :N: + * + * +
:P: :P: :P: * + :P: :P: :P:
:R: + :B: :Q: :K: :B: :N: :R:
WHITE
YOUR MOVE, HERC03
BD3
ELAPSED TIME WAS 1:22
MY MOVE IS C5
COMPUTATION TIME WAS 5:27
YOUR MOVE, HERC03
S
MOVE: 4 BOOK: 0 EXPECTED: 1
DEPTH: 7 TIME: -16:22 RATIO: 1.9 EVAL: 80
NODES: 1220128 EVALS: 561760 LOOKUPS 1X TABLE 100X
RC7-C5 RD4:C5 RB4:C3+ RB2:C3 .....
YOUR MOVE, HERC03
D
BLACK
(R) (N) (B) (Q) (K) * + (R)
(P) (P) * (P) * (P) (P) (P)
+ * + * (P) (N) + *
* + (P) + * + * +
+ (B) + :P: :P: * + *
* + :N: :B: * + * +
:P: :P: :P: * + :P: :P: :P:
:R: + :B: :Q: :K: + :N: :R:
WHITE
YOUR MOVE, HERC03
The R in front of PV moves is an actual bug in the program. It occurs in the OUTPUT subroutine (converts internal data into text for display) where the piece type is retrieved from the BOARD array by using the FROM$ index that is itself extracted from the compressed move. OUTPUT is called by two different subroutines, STATUS and INFORM. STATUS passes a saved copy of the BOARD array where the piece is still located at FROM$. But INFORM passes the live BOARD, where the PV moves are made in turn and so reside at the TO$ index. OUTPUT was only using FROM$ as an index. So the lookup would find a 0 at the FROM$ location because the piece wasn't actually there. In the piece type lookup table, there is no zero index, so I don't know where it was getting the 4, which is the number for the rook (R).mhull wrote: ↑Tue Jul 28, 2020 7:03 am It is playing legal chess at the moment (at least through the first several moves), but not all the features are working. This example is computing at a fixed depth setting of 7. The computation times are accurate and I assume the node counts are also.
This emulator is running an IBM 3033. Back in the day it was rated about 1.5 MIPS (I think). It was a bit faster than the Xerox Sigma 9. On my dated AMD Machine (AMD Phenom II X4 830, 2.8 Ghz), it's clocking around 181 MIPS on one CPU.Code: Select all
COMPUTATION TIME WAS 3:13 YOUR MOVE, HERC03 S MOVE: 3 BOOK: 0 EXPECTED: 1 DEPTH: 7 TIME: -24:36 RATIO: 2.4 EVAL: 74 NODES: 632835 EVALS: 334647 LOOKUPS 2X TABLE 100X RF8-B4 RC1-G5 RB4:C3 RB2:C3 RH7-H6 RG5:F6 RD8:F6 YOUR MOVE, HERC03 D BLACK (R) (N) (B) (Q) (K) * + (R) (P) (P) (P) (P) * (P) (P) (P) + * + * (P) (N) + * * + * + * + * + + (B) + :P: :P: * + * * + :N: + * + * + :P: :P: :P: * + :P: :P: :P: :R: + :B: :Q: :K: :B: :N: :R: WHITE YOUR MOVE, HERC03 BD3 ELAPSED TIME WAS 1:22 MY MOVE IS C5 COMPUTATION TIME WAS 5:27 YOUR MOVE, HERC03 S MOVE: 4 BOOK: 0 EXPECTED: 1 DEPTH: 7 TIME: -16:22 RATIO: 1.9 EVAL: 80 NODES: 1220128 EVALS: 561760 LOOKUPS 1X TABLE 100X RC7-C5 RD4:C5 RB4:C3+ RB2:C3 ..... YOUR MOVE, HERC03 D BLACK (R) (N) (B) (Q) (K) * + (R) (P) (P) * (P) * (P) (P) (P) + * + * (P) (N) + * * + (P) + * + * + + (B) + :P: :P: * + * * + :N: :B: * + * + :P: :P: :P: * + :P: :P: :P: :R: + :B: :Q: :K: + :N: :R: WHITE YOUR MOVE, HERC03
The PV seems to have an R in front of each move for some reason.
Code: Select all
define file 3(5000,40,u,iav)
.
.
c------------------------------< get the pointer to the record with
c------------------------------< the computer's possible replies.
key=mod(key,10000)
...
read(3'key)(moves(i),i=1,40)
.
.
c------------------------------< set-up for the next match.
key=key*10000+moves(which+20)
Argh. Also, in the middle of this code:mhull wrote: ↑Tue Sep 15, 2020 7:21 pm I have some questions about the book structure in Blitz.
The book file structure is setup with uniform records of 40, 32-bit words each. Each record is padded with words initialized to zero. Words 1-20 contain up-to 20 moves in compressed move format. For each move, a corresponding hash value is also created. For example, a move in word 4 would have a corresponding position hash in word 24. Unused words remain padded with values of zero.
I have included the relevant code segments from BOOK.F. A book record is loaded into the array MOVES. The first KEY value is 1 on move 1 of the game. Subsequent KEY values replace 1 with the corresponding hash value from MOVES(which+20) where WHICH is the nth compressed move.1) Am I understanding the book file correctly?Code: Select all
define file 3(5000,40,u,iav) . . c------------------------------< get the pointer to the record with c------------------------------< the computer's possible replies. key=mod(key,10000) ... read(3'key)(moves(i),i=1,40) . . c------------------------------< set-up for the next match. key=key*10000+moves(which+20)
2) Shouldn't the record count in the "define file" statement (5000) be the same as the modulus parameter (10000)? (The DEFINE FILE statement was actually commented out. It was reactivated for testing.)
3) The original book-maker code isn't available. Would it have used the same hashing function used for the transposition table?
Code: Select all
key=moves(i+20)
if(key .eq. 0) go to 3
c
c------------------------------< read in the record with the program's
c------------------------------< possible replise to the last human
c------------------------------< move and chose one of them. the
5 continue
read(3'key)(moves(i),i=1,40)