Sane numbers
Martin Borriss
Although I usually don't like to throw with numbers,
here are some. A short while ago I asked for some comments
regarding the re-implementation of my move generator.
When implementing it I discovered that a lot of my thoughts
were wrong (regarding separate piecelists for separate pieces
etc).
Currently it is presumably a pretty generic implementation, using
piecelists (separate for pieces and pawns, Tom Kerrigan referred to
them as 'gnu-style', I didn't check this there). The generator itself
is offset-based (16x8 board, uses 0x88 of course). I want to
try an 'nextpos/nextdir' type if I find time and feel like it.
As hardware I currently use an AMD X5 (486/133, rated P75), Tests were
done under DOS, compiled with Borland C 3.1 with no particular
optimization. Testpositions are the initial position and BK1-10.
The movegen itself generates between 750k and 2000k moves per second
which means nothing. As a rule, it goes faster in open positions. Goes
slowest in closed positions with many pieces (also initial position).
The whole cycle:
1. generate_moves in a given position (pseudolegal)
2. for all moves: make_move; undo_move (legal moves)
does 60K-100K moves depending on the position, of course.
It would run a _little_ faster with no asserts and stack overflow tests,
no standard stack frames, everything inline etc. I didn't look at the
assembly output yet.
Please comment on this. I'd like to hear something like:
1) Please re-think your strategy ;)
2) Sounds ok, you can work with this, but twice as fast is very
possible
3) Leave it at this, you won't make it much better probably and
it is important anyway.
4) Wow, thats FAST! (I know that it isn't since I ran into Tom
yesterday on ICC)
I think its not worth to spend to much effort into the movegen, I'd like
to look into the make_move and undo_move functions again.
Curious to see how it runs under Linux here. I'd like to play with
different sizes for important data entities to verify the pentium
performance hit for wrong data sizes in the correct code segment (or
vice versa), aka prefixed opcodes.
Martin
Tom Kerrigan
It's almost 4 AM here so I'm not thinking very clearly, but what you might want to
look into is doing the minimum work necessary in makemove to run in_check, and
then if the move is illegal, you didn't spend too much time making it or taking it
back. This is a semi-cool thing that I do in my makemove.
The only other thing I can think of right now is to not check the en passant
square when you're generating pawn moves. This leads to many silly tests. Instead,
after you generate all your moves, check to see if the en passant square is set.
If so, check the appropriate squares for pawns and then generate the moves. As I
recall, this saved me almost 10%.
Oh yeah, you might also want to save the hash key in the array you keep to take
moves back, so you don't wind up doing a lot of XORing in takeback. This makes
things slower in complicated positions with lots of checks because you're saving
the hash key for what turns out to be a false alarm, but I've found that there's
an overall gain... in my program, at least... :)
Speaking of numbers, the figure I quoted on ICC yesterday was from when I was
working on this almost a year ago (150k gen/makemove/takeback on a 486/33) so I'll
try to get some new numbers and post them tomorrow.
Ugh... need sleep now... :)
Cheers,
Tom
_______________________________________________________________________________
Tom Kerrigan kerr...@frii.com O-
(some long fortune that i deleted to save bandwidth... sorry to all my .sig fans)
Robert Hyatt
Martin Borriss (mb...@irz.inf.tu-dresden.de) wrote:
:
: Although I usually don't like to throw with numbers,
Two comments:
(1) it's difficult to compare what you posted to anybody else. A lot depends
on what you put into MakeMove() and UnmakeMove(). If you do things there that
save time in Evaluate(), then that will slow MakeMove() down, but speed up
Evaluate() which confuses comparisons.
(2) comparing NPS values is also "iffy" because it's not a useful measure of
a program's strength. If you take your program, and modify it so it's 25%
faster, without removing anything, then it'll play better. But to compare
NPS with someone else is likely to be useless.
Time-to-solution is the most useful way to compare two programs either tactically
or positionally.
Bob
Robert Hyatt
Tom Kerrigan (kerr...@frii.com) wrote:
: It's almost 4 AM here so I'm not thinking very clearly, but what you might want to
: then if the move is illegal, you didn't spend too much time making it or taking it
: back. This is a semi-cool thing that I do in my makemove.
This is not the fastest thing in the world to do. Since nearly all moves are
legal, except in certain types of problems, you wind up checking for legality
when it's not needed. In Cray Blitz and Crafty, I use capturing the king at
the next ply as an indicator that the move at the current ply is illegal.
Since most are not illegal, I capture the king few times, and the overall
savings is measurable.
:
: The only other thing I can think of right now is to not check the en passant
: square when you're generating pawn moves. This leads to many silly tests. Instead,
: after you generate all your moves, check to see if the en passant square is set.
: If so, check the appropriate squares for pawns and then generate the moves. As I
: recall, this saved me almost 10%.
:
: Oh yeah, you might also want to save the hash key in the array you keep to take
: moves back, so you don't wind up doing a lot of XORing in takeback. This makes
: things slower in complicated positions with lots of checks because you're saving
: the hash key for what turns out to be a false alarm, but I've found that there's
: an overall gain... in my program, at least... :)
About 6 months ago I got rid of this. Particularly on the P6, this extra memory
reference to load the old hash key from an array is way slower than the
exclusive-or instructions to "un-update" the hash key. PC's have terrible
memory bandwidth, terrible memory latency, but very fast instruction execution
rates. Play to the strength of the machine, not it's most glaring weakness.
:
: Speaking of numbers, the figure I quoted on ICC yesterday was from when I was
: working on this almost a year ago (150k gen/makemove/takeback on a 486/33) so I'll
Crafty hits around 650,000 on the P6.
: try to get some new numbers and post them tomorrow.
Marcel Nijman
Thanks,
Marcel
--
ir. Marcel J. Nijman
Department of Medical Physics and Biophysics, University of Nijmegen
Geert Grooteplein 21, CPK1 231, NL 6525 EZ Nijmegen, The Netherlands
mar...@mbfys.kun.nl http://www.mbfys.kun.nl/~marcel/
Language shapes the way we think and determines what we can think about.
-- B.L. Whorf
Tom Kerrigan
>legal, except in certain types of problems, you wind up checking for legality
>when it's not needed. In Cray Blitz and Crafty, I use capturing the king at
>the next ply as an indicator that the move at the current ply is illegal.
>Since most are not illegal, I capture the king few times, and the overall
>savings is measurable.
Please don't assume that this trick works for everybody. I decided to code it a
long time ago, but the way I keep piece lists forced me to write quite a bit of
"extra" code and the end result was slower than what I'm doing now.
Cheers,
Tom
_______________________________________________________________________________
Tom Kerrigan kerr...@frii.com O-
Reality is just a convenient measure of complexity.
-- Alvy Ray Smith
Robert Hyatt
: >This is not the fastest thing in the world to do. Since nearly all moves are
: >legal, except in certain types of problems, you wind up checking for legality
: >when it's not needed. In Cray Blitz and Crafty, I use capturing the king at
: >the next ply as an indicator that the move at the current ply is illegal.
: >Since most are not illegal, I capture the king few times, and the overall
: >savings is measurable.
:
: Please don't assume that this trick works for everybody. I decided to code it a
: long time ago, but the way I keep piece lists forced me to write quite a bit of
: "extra" code and the end result was slower than what I'm doing now.
Then that's likely a "red flag" you should look at. It's faster for Bruce, who's
faster than you. It's faster for me, and I'm slower than you, It's faster for
Cray Blitz who's faster than anyone but Deep Blue. Mark Lefler reported that it
was about 20% faster in Now as well. If it's not faster for you, you likely have
some underlying inefficiency tucked away. Since most moves are legal (don't test
the change on forced mate positions of course, it might be slower there), avoiding
any sort of "InCheck" test has to be more efficient. If it's not for you, I'd
spend time figuring out why. Sounds like something's wrong somehwere...
BTW, I don't see how the piece list would be a problem, because I had one in Cray
Blitz. The *only* test needed is to generate captures, and if one is capturing a
king, return some sort of illegal move indicator. This idea doesn't change anything
else at all.
Robert Hyatt
: Can anybody please explain in a few sentences what the 0x88 approach is?
:
: Thanks,
: Marcel
:
:
Simply stated: the chess board is made up of 8 rows of 16 squares per row.
the first 8 squares of each row are *real* chessboard squares. the remaining
8 are unused.
notice that the square numbers of legit squares are of the form 0X00 - 0X77.
Any square that has either of the 0X88 bits set is illegal. This lets you add an
offset for a bishop move, for example and detect whether you are now on an
illegal rank or file. For example, starting at square 00, you at 17 decimel or
0X11 to this square to get the next diagonal square in the "11" direction.
This produces 00 11 22 33 44 55 66 77. when you add again, you get 0X88 which
is off the board.
if you start at square 02, you get 02 13 24 35 46 57 68 and notice that 68 has
one of the "8" bits set, indicating you went off the board. this works for
both addition and subtraction, and lets you test two conditions with one if-test:
"is this rank legal; is this file legal;"
Been around a long long time. I first used it in 1979 or so, and got the idea
from someone else, likely the Coko guys or Chaos, or whomever.
It's good for PC's, not the best for machines that support vector loads however,
so we canned it about 2 years after moving to the Cray when we studied faster
ways to generage moves on a vector machine.
Bob
Chris Whittington
>
> >This is not the fastest thing in the world to do. Since nearly all moves are
> >legal, except in certain types of problems, you wind up checking for legality
> >when it's not needed. In Cray Blitz and Crafty, I use capturing the king at
> >the next ply as an indicator that the move at the current ply is illegal.
> >Since most are not illegal, I capture the king few times, and the overall
> >savings is measurable.
>
> Please don't assume that this trick works for everybody. I decided to code it a
> long time ago, but the way I keep piece lists forced me to write quite a bit of
> "extra" code and the end result was slower than what I'm doing now.
>
> Tom
>
Fast, slow, fast, fast, slow - shuffle round the dance floor.
Chess knowledge would give you a new tune to dance to.
And don't say we have chess knowledge, because all these threads
going on and on about speed, and speed tricks indicate that too
many programmers on r.g.c.c are solely concerned with speed, and
pay lip-service to the knowledge component.
It would be good if we went beyond these trivial technical
questions of speed and discussed the chess domain side of things.
Hmm ?
Chris Whittington
Joseph McCaughan contra
:Bob
Oh - this is a "totally" cool concept. I'm a newbie chess
programmer and this would save me all kinds of
"jumping-thru-hoops" in my program.
I have a Unix/Bourne Shell driven program called Shiloh.
(I know - it sounds ridiculous but it plays pretty much
legal chess).
I'm also Shiloh (the human version) on FICS BTW.
Some stats on Shiloh:
386/4MB
Unix SVR2
20 moves/hour (yes per hour... :)
Uses /bin/sh, grep, awk, sed and associated utilities.
Less than 1% C language.
Shiloh:
1) Uses the bitmapped approach. (Thanks Dr. Hyatt)
2) Uses several tables ( move tables, piece value tables etc.)
3) Understands "absolute" pins over the king.
4) Does not understand pins over anything else.
5) Knows the 3 ways to get out of check,
(take checker, block checker, move out).
6) Understand draw by repetition.
7) Understands checkmate (see 5) above.)
8) Is probably rated about... maybe 6-700 or so :) maybe 4-500 ELO :)
9) other simple stuff...
Of course I was elated when performance jumped from
~6 moves/hour on a 286/1MB to about 20-24 moves/hour
on the 386/4MB...
Wish it was on the net... I could take some of
you guys on.... :)
--Joe
Joe McCaughan / A man there was, and they called him mad,
jmc...@hposl61.cup.hp.com \ The more he gave, the more he had.
Phone: (408) 447-7892 /
\ John Bunyan
Bruce Moreland
>[snip]
>
>It would be good if we went beyond these trivial technical
>questions of speed and discussed the chess domain side of things.
>Hmm ?
You are welcome to start a thread. If you do, I'm sure lots of people will respond.
I don't know how to begin a discussion of chess knowledge, because my own experience
with chess knowledge has to do with things that I can hash, very simple second-order
piece evaluation terms, and king safety. I would like to take part is such a
discussion though.
Perhaps you can start it off by telling us how you use knowledge in CST: what kind of
knowledge you collect, where you collect it, how it manifests in the eval function, how
you use it to guide the search, and how you prove that a knowledge-term is worth the
time spent computing it.
If you do this, I think I know enough chess to understand and to make a constructive
response, but if I don't then certainly Martin Borriss does.
bruce
--
The opinions expressed in this message are my own personal views
and do not reflect the official views of Microsoft Corporation.
MANOHARARAJAH VALAVAN
I forgot to mention that the machine that I quoted the numbers for is a P66.
In article <DtMyo...@ecf.toronto.edu>,
MANOHARARAJAH VALAVAN <man...@ecf.toronto.edu> wrote:
>In article <4qqs4p$e...@irz301.inf.tu-dresden.de>,
>Martin Borriss <mb...@irz.inf.tu-dresden.de> wrote:
>>
>>Although I usually don't like to throw with numbers,
>>here are some. A short while ago I asked for some comments
>>regarding the re-implementation of my move generator.
>>
>>When implementing it I discovered that a lot of my thoughts
>>were wrong (regarding separate piecelists for separate pieces
>>etc).
>>Currently it is presumably a pretty generic implementation, using
>>piecelists (separate for pieces and pawns, Tom Kerrigan referred to
>>them as 'gnu-style', I didn't check this there). The generator itself
>>is offset-based (16x8 board, uses 0x88 of course). I want to
>>try an 'nextpos/nextdir' type if I find time and feel like it.
>>
>>As hardware I currently use an AMD X5 (486/133, rated P75), Tests were
>>done under DOS, compiled with Borland C 3.1 with no particular
>>optimization. Testpositions are the initial position and BK1-10.
>
>I would suggest using a different compiler. Get GCC, it is free and optimizes
>real well ( from my experience, it seems to be on par with Watcom ).
>
>>
>>The movegen itself generates between 750k and 2000k moves per second
>>which means nothing. As a rule, it goes faster in open positions. Goes
>>slowest in closed positions with many pieces (also initial position).
>
>I use two piecelists: one for black pieces and one for white (no separation
>between pieces and pawns). For move generation alone, I get around 1000k moves
>in the opening position. It can easily do 2500+k in open positions.
>Note that I am also using 0x88 approach, and just use a simple offset
>generator. I don't think the 'nextpos/nextdir' stuff (like in GNU) is much
>faster than the 0x88 stuff.
>
>I remember using the 'nextpos/nextdir' stuff before - I didn't like it too
>much (if I remember correctly, I found the regular offset+0x88 stuff much
>more faster).
>
>>
>>The whole cycle:
>> 1. generate_moves in a given position (pseudolegal)
>> 2. for all moves: make_move; undo_move (legal moves)
>>
>>does 60K-100K moves depending on the position, of course.
>>
>
>If I do a generate,make,verify legality and undo, I can pull off around
>160k moves a second in the opening position (much more higher for open
>positions).
>
>If I do the same as above but ignore legality testing, I can pull off around
>360k moves a second.
>
>>It would run a _little_ faster with no asserts and stack overflow tests,
>>no standard stack frames, everything inline etc. I didn't look at the
>>assembly output yet.
>>
>>Please comment on this. I'd like to hear something like:
>>1) Please re-think your strategy ;)
>>2) Sounds ok, you can work with this, but twice as fast is very
>>possible
>>3) Leave it at this, you won't make it much better probably and
>>it is important anyway.
>>4) Wow, thats FAST! (I know that it isn't since I ran into Tom
>> yesterday on ICC)
>>
>
>Your strategy seems ok... I have tried several different types of move
>generators and representations in the past (including bitboard), I liked the
>0x88 approach the best. I think you can get some more juice out of the
>move generator, make() and unmake() routines.
>
>>I think its not worth to spend to much effort into the movegen, I'd like
>>to look into the make_move and undo_move functions again.
>>
>>Curious to see how it runs under Linux here. I'd like to play with
>>different sizes for important data entities to verify the pentium
>>performance hit for wrong data sizes in the correct code segment (or
>>vice versa), aka prefixed opcodes.
>>
>>
>>Martin
>>
>>--
>>Martin....@inf.tu-dresden.de
>
>
>--
>-------------------------------------------------------------------------------
> man...@ecf.utoronto.ca | 3rd year Comp Eng., University of Toronto
> Valavan Manohararajah |
>-------------------------------------------------------------------------------
--
-------------------------------------------------------------------------------
man...@ecf.utoronto.ca | 3rd year Comp Eng., University of Toronto
Valavan Manohararajah |
-------------------------------------------------------------------------------
Tom Kerrigan
>faster than you. It's faster for me, and I'm slower than you, It's faster for
>Cray Blitz who's faster than anyone but Deep Blue. Mark Lefler reported that it
>was about 20% faster in Now as well. If it's not faster for you, you likely have
>some underlying inefficiency tucked away. Since most moves are legal (don't test
If I gave the impression that this is some sort of bug, I'm sorry, because I know
exactly what the problem is and I don't really need to investigate anything. It's
just a sort of design flaw that would take almost a complete rewrite to fix, and I
don't care to do this for a performance gain of 20% that may or may not happen
with my particular program. I don't care to explain this flaw here, but please
don't tell me it's a bug, or something I need to look at.
Cheers,
Tom
_______________________________________________________________________________
Tom Kerrigan kerr...@frii.com O-
"The only real way to look younger is not to be born so soon."
-- Charles Schulz, "Things I've Had to Learn Over and
Over and Over"
Marcel Nijman
>
> Marcel Nijman (mar...@mbfys.kun.nl) wrote:
> : Can anybody please explain in a few sentences what the 0x88 approach is?
> :
> : Thanks,
> : Marcel
> :
> :
>
[explaination deleted]
I don't really see why this should be faster than doing something like
the following:
i = rook_vertical_index[sq0];
while (TRUE)
{ sq1 = rook_vertical[i];
if (sq1 == END_MARKER)
break;
if (color(sq1) != my_color)
add_move(sq0, sq1);
if (board[sq1] != EMPTY)
break;
i++;
}
where `rook_vertical_index[sq0]' is the offset for the array
`rook_vertical' where the squares are stored that can be reached from
sq0.
To me, both approaches seem to be equally efficient.
Marcel
--
ir. Marcel J. Nijman
Department of Medical Physics and Biophysics, University of Nijmegen
Geert Grooteplein 21, CPK1 231, NL 6525 EZ Nijmegen, The Netherlands
mar...@mbfys.kun.nl http://www.mbfys.kun.nl/~marcel/
The paperless office is about as likely as the paperless toilet.
-- Jay Curry
Martin Borriss
Thanks to all people who replied.
Summarizing:
1) Testing is needed whether to check for legality in make_move or within
the next ply (movegen) (discussed by Bob, Bruce and Tom).
2) Some little things mentioned by Tom:
a) Do as little before in_check in make_move (if we chose this
approach) as we can.
b) Check for en passant moves only once, not for each pawn.
3) Chris is more interested in the 'art of evaluation' while this is only
handycraft ;)
In article <DtMyo...@ecf.toronto.edu>, man...@ecf.toronto.edu (MANOHARARAJAH VALAVAN) writes:
> I would suggest using a different compiler. Get GCC, it is free and optimizes
> real well ( from my experience, it seems to be on par with Watcom ).
>
That is the easy way out. I certainly know that the Borland compiler optimizes
much worse than most other.
> I remember using the 'nextpos/nextdir' stuff before - I didn't like it too
> much (if I remember correctly, I found the regular offset+0x88 stuff much
> more faster).
>
Interesting to hear. Would have thought that 'offsetting' would be equally
good at maximum, but didn't know how equal.
> >
> >The whole cycle:
> > 1. generate_moves in a given position (pseudolegal)
> > 2. for all moves: make_move; undo_move (legal moves)
> >
> >does 60K-100K moves depending on the position, of course.
> >
>
> If I do a generate,make,verify legality and undo, I can pull off around
> 160k moves a second in the opening position (much more higher for open
> positions).
>
> If I do the same as above but ignore legality testing, I can pull off around
> 360k moves a second.
>
Martin
Martin Borriss
In article <31D2786E...@mbfys.kun.nl>, Marcel Nijman <mar...@mbfys.kun.nl> writes:
> Can anybody please explain in a few sentences what the 0x88 approach is?
>
(Another) really good explanation was made by Bruce Moreland a short
while ago in this group.
In short, he pointed out that the two main advantages are:
1) Easy and fast movegeneration ( when did you run over the edge of the board?)
2) 16 x 8 board allows for easily relating two squares to each other (e.g.,
are they one diagonal, a knights jump away etc)
It is worth to get a hold of this post.
Martin
Urban Koistinen
: > :
: > : Thanks,
: > : Marcel
: > :
: > :
: >
: [explaination deleted]
: I don't really see why this should be faster than doing something like
: the following:
: i = rook_vertical_index[sq0];
: while (TRUE)
: { sq1 = rook_vertical[i];
table lookup is usually slower than adding a constant
: if (sq1 == END_MARKER)
: break;
This is only a little faster if any than
if (sq&0x88) break;
: if (color(sq1) != my_color)
: add_move(sq0, sq1);
This is a lookup, why not color[sq1]?
: if (board[sq1] != EMPTY)
: break;
lookup
: i++;
: }
: where `rook_vertical_index[sq0]' is the offset for the array
: `rook_vertical' where the squares are stored that can be reached from
: sq0.
: To me, both approaches seem to be equally efficient.
Reading from an array one extra time makes your way slower.
I guess you could make it one read of 8 bytes to speed it up.
Here is my way before I started using rotated bitmaps:
i = colorborder[sq0]; /* same for all directions */
sq1 = sq0;
while(TRUE) {
sq1 += 010;
if (i&(BORDER_UP_BIT | OCCUPIED))
break;
add_move(sq0, sq1);
i = colorborder[sq1];
}
if (!(i&(BORDER_UP_BIT | OWNCOLOR)))
add_capture(sq0, sq1);
The reason this is faster is that you do the border
and occupied test with one operation instead of two
and the capture test outside of the loop.
Each entry in the colorborder[64] table contain the bits:
BORDER_UP_BIT - set for rank 8
BORDER_DOWN_BIT - set for rank 1
BORDER_LEFT_BIT - set for file A
BORDER_RIGHT_BIT - set for file H
EMPTY_BIT - set if square is empty
WHITE_BIT - set if square is occupied by white piece
BLACK_BIT - set if square is occupied by black piece
OCCUPIED = WHITE_BIT | BLACK_BIT
The bad thing is that it adds the cost of updating
the colorborder table to makemove().
Marking captures when generating them might make up
for that cost.
Robert Hyatt
: >Then that's likely a "red flag" you should look at. It's faster for Bruce, who's
: >faster than you. It's faster for me, and I'm slower than you, It's faster for
: >Cray Blitz who's faster than anyone but Deep Blue. Mark Lefler reported that it
: >was about 20% faster in Now as well. If it's not faster for you, you likely have
: >some underlying inefficiency tucked away. Since most moves are legal (don't test
:
: If I gave the impression that this is some sort of bug, I'm sorry, because I know
: exactly what the problem is and I don't really need to investigate anything. It's
: just a sort of design flaw that would take almost a complete rewrite to fix, and I
: don't care to do this for a performance gain of 20% that may or may not happen
: with my particular program. I don't care to explain this flaw here, but please
: don't tell me it's a bug, or something I need to look at.
Bug, design flaw, inefficiency. All are basically the same thing to a chess
program. Of course you don't have to fix anything you don't want to, the
mind-police has not yet become a reality. However, if there's a 25% gain
available somewhere, I'm going after it sooner or later, because that is a
speed advantage I'm not willing to give up, assuming it doesn't hurt somewhere
else (such as in the eval.) I'd hate to count how many times basic algorithms
have been re-done in Crafty. Rotated bitmaps come to mind.
Robert Hyatt
: Robert Hyatt wrote:
: >
: > Marcel Nijman (mar...@mbfys.kun.nl) wrote:
: > : Can anybody please explain in a few sentences what the 0x88 approach is?
: > :
: > : Thanks,
: > : Marcel
: > :
: > :
: >
:
: [explaination deleted]
:
: I don't really see why this should be faster than doing something like
: the following:
:
:
: i = rook_vertical_index[sq0];
: while (TRUE)
: { sq1 = rook_vertical[i];
: break;
: add_move(sq0, sq1);
: break;
: }
:
Easy to explain. your line, sq1= ..., results in a memory fetch, after the
address arithmetic to calculate the address of rook_vertical is done. With
X88, after calculating the address, you are *done*. The memory reference is
the killer. Note also that you took the easy case of only moving along a
file. For a bishop, it steps along a rank and file at the same time so you
have to check *both* before you know the square is illegal.
One more thing... you step through rook_vertical, but you also have to step
through the chess board itself to make sure the rook is not blocked in that
direction for each iteration. You end up with multiple memory references
per iteration, where the X88 algorithm does exactly one.
:
: where `rook_vertical_index[sq0]' is the offset for the array
: `rook_vertical' where the squares are stored that can be reached from
: sq0.
:
: To me, both approaches seem to be equally efficient.
:
: Marcel
Chris Whittington
>
> >Then that's likely a "red flag" you should look at. It's faster for Bruce, who's
> >faster than you. It's faster for me, and I'm slower than you, It's faster for
> >Cray Blitz who's faster than anyone but Deep Blue. Mark Lefler reported that it
> >was about 20% faster in Now as well. If it's not faster for you, you likely have
> >some underlying inefficiency tucked away. Since most moves are legal (don't test
>
> If I gave the impression that this is some sort of bug, I'm sorry, because I know
> exactly what the problem is and I don't really need to investigate anything.
There are bugs and there are really serious bugs.
Really serious bugs are the ones that programmers say 'this isn't
a bug, I know what the problem is and I don't need to investigate' :)
Really serious bugs are usually still around 3 months (years) later.
I know, I have lots of them.
Chris Whittington
> It's
> just a sort of design flaw that would take almost a complete rewrite to fix, and I
> don't care to do this for a performance gain of 20% that may or may not happen
> with my particular program. I don't care to explain this flaw here, but please
> don't tell me it's a bug, or something I need to look at.
>
Chris Whittington
>
> In article <83590724...@cpsoft.demon.co.uk>, chr...@cpsoft.demon.co.uk says...
> >[snip]
> >
> >It would be good if we went beyond these trivial technical
> >questions of speed and discussed the chess domain side of things.
> >Hmm ?
>
> You are welcome to start a thread. If you do, I'm sure lots of people will respond.
>
> I don't know how to begin a discussion of chess knowledge, because my own experience
> with chess knowledge has to do with things that I can hash, very simple second-order
> piece evaluation terms, and king safety. I would like to take part is such a
> discussion though.
>
> Perhaps you can start it off by telling us how you use knowledge in CST: what kind of
> knowledge you collect, where you collect it, how it manifests in the eval function, how
> you use it to guide the search, and how you prove that a knowledge-term is worth the
> time spent computing it.
Briefly:
The evaluation function is responsible for making pruning, extension
and candidate move decisions.
Since the program runs at only 1800 n/s on a P90, the forward pruning
decisions are very important, and, if CST gets it wrong, it will
be crushed. So the eval looks for *everything* I can think of.
Every single tactical theme possible is covered (almost).
Of course, it is not possible to be totally accurate in these
calculations, sometimes there are too many pins and other complexities,
but CST tries.
When I first got into serious chess programming, and studied the
main lines of many programs, it amazed me how *little* they knew.
Seriously little, and, of course, some are worse than others.
Of course, again, they rely on the search to stay out of trouble and
find combinations.
I first started playing chess in a chess cafe in London (since closed
down). It was in a German/Central European/Jewish WWII refugee area, and full
of old central european chess players. They had a word for weak players,
Patzer, this meant not a total beginner, but someone who knew enough
not to leave pieces en prise, not to leave his king to be mated, not
to leave pieces in nasty pins and so on.
It seemed to me, and despite the many claims that knowledge had been
tried and failed, that it must be possible to program an evaluation
function to understand at the level of the patzer above.
The patzer knowledge could be used to guide and prune the search, and
the search (shallower than with faster programs) could be relyed on
to pick up stuff missed by the evaluation patzer.
Also, I came to realise that with a much heavier eval knowledge
component, it was possible to become highly speculative in the
evaluation function. CST, internally, 'wins' material before it is
realistically won, 'mates' its opponent before it is realistically
mating. Often it gets it wrong, often it gets it right - but the result
is a fantastically exciting and dynamic style of play. Just about everyday
I get a thrill/heart attack from some manic game on the autoplayers,
where CST seems to be playing madness, pieces hanging everywhere, mating
attacks for both sides. CST says +10.00 pawns, opponent says +2.00
pawns - it takes maybe 10 half moves for the situation to resolve.
Two points:
1. End users at this stage think I'm talking rubbish and their
favourite program's evaluation function knows plenty. I had an email
the other day from someone alleging that a certain PC program was
worth 2000 ELO evaluation function alone.
2. Bob Hyatt's line is that my approach is just an extension on the
scale of knowledge in the eval versus knowledge in the search. He
uses the 'cylinder' analogy.
I claim that when the evaluation function is knowledge packed, and
this knowledge is used for search guidance, and for speculation, that
*qualitative* differences emerge between this and the classical style
programs.
So, I'm not claiming that I do anything special. Simply that no-one
else has stuck long enough at this approach to make it work.
And, lastly, programs are pretty good now, we have much program space
in PC's (it not like there's only 64K for code anymore). PC's are fast
so we get away with doing much code executions. Programs don't need
to be bare materialists - there's much scope for giving them particular
play styles. CST is designed (has emerged) to play in the style of Tal,
and it does.
Chris Whittington
Urban Koistinen
: : the following:
: :
: :
: : i = rook_vertical_index[sq0];
: : while (TRUE)
: : { sq1 = rook_vertical[i];
: : if (sq1 == END_MARKER)
: : break;
: : if (color(sq1) != my_color)
: : add_move(sq0, sq1);
: : if (board[sq1] != EMPTY)
: : break;
: : i++;
: : }
: :
: Easy to explain. your line, sq1= ..., results in a memory fetch, after the
: address arithmetic to calculate the address of rook_vertical is done. With
: X88, after calculating the address, you are *done*. The memory reference is
: the killer.
: Note also that you took the easy case of only moving along a
: file. For a bishop, it steps along a rank and file at the same time so you
: have to check *both* before you know the square is illegal.
Read the source Bob!
He is reading a precalculated array.
Bishop and rook moves are pretty much the same then.
Robert Hyatt
I did. However, he's doing a memory fetch to detect off the board. X88
eliminates that as I mentioned. It is *not* a huge savings, but it is a
measurable one.
Bruce Moreland
>
>If I gave the impression that this is some sort of bug, I'm sorry, because I know
>don't care to do this for a performance gain of 20% that may or may not happen
>with my particular program. I don't care to explain this flaw here, but please
>don't tell me it's a bug, or something I need to look at.
Won't do a complete rewrite for 20%? Wimp! :-)
bruce
Bruce Moreland
e...@aristotle.algonet.se says...
>i = colorborder[sq0]; /* same for all directions */
>sq1 = sq0;
>while(TRUE) {
> sq1 += 010;
> if (i&(BORDER_UP_BIT | OCCUPIED))
> break;
> add_move(sq0, sq1);
> i = colorborder[sq1];
>}
I didn't know that it is faster to add 8 to something in
octal than in decimal.
Thanks for the tip :-)
bruce
Peter W. Gillgasch
[ snip ]
> There are bugs and there are really serious bugs.
There are bug, really serious bugs and there are f*ing bugs.
> Really serious bugs are the ones that programmers say 'this isn't
> a bug, I know what the problem is and I don't need to investigate' :)
That's not a bug, that is a design error.
> Really serious bugs are usually still around 3 months (years) later.
Those are those that don't crash. When I write a chess engine 60% of the
code are assert macros and test facilities.
> I know, I have lots of them.
We all do. Chess programming is darned complex...
-- Peter
Peter W. Gillgasch
*not* intend to put down Chris. I am just a member of another tribe and
as such I have different opinions. I may make some statement that could
be misinterpreted as patronizing but those are intended to get the
discussion "to the point" somewhat faster. In other words leave the
flame-thrower at home.
I am making some comments just in case you haven't read too much on the
history of computer chess to make following the discussion somewhat
easier for all the readers.
Chris Whittington <chr...@cpsoft.demon.co.uk> wrote:
> brucemo (Bruce Moreland) wrote:
> > In article
> <83590724...@cpsoft.demon.co.uk>, chr...@cpsoft.demon.co.uk
> says...
> >It would be good if we went beyond these trivial technical
> >questions of speed and discussed the chess domain side of
> things.
I disagree on your "trivial" qualification. Let's have a deal. You stop
to pick at each chance you get on the "speed demon mentality" and I try
to take you seriously albeit the current implementation of your ideas is
clearly having some problems in being competetive. Basically I want to
say that you are pretty much alone with your ideas (albeit they are
interesting) and up to now you have failed to demonstrate that they are
making sense so please stop sniping from the periphery. Thanks.
[ snip ]
> Briefly:
> The evaluation function is responsible for making pruning, extension
> and candidate move decisions.
Sounds like the typical 60ties design. For the folks that read this that
do not know about the history:
In the early years it was assumed that the brute force method (AKA
Shannon A strategy) is futile because of the combinatorical explosion.
Hence the chess programmers tried to forward prune moves in the game
tree with the help of the evaluation function and some additional static
anylysis that detects pins/forks etc. The moves that are finally
included in the game tree were selected using a "plausible move
generator" that is basically a move generator augmented with the methods
mentioned.
> Since the program runs at only 1800 n/s on a P90, the forward pruning
> decisions are very important, and, if CST gets it wrong, it will
> be crushed. So the eval looks for *everything* I can think of.
> Every single tactical theme possible is covered (almost).
As I mentioned in an earlier post those problems lead two bright guys
(Slate & Atkin from the Northwestern University Chess Program) to the
idea to do away with the plausible move generator and forward pruning
stuff in general. Much to their surprise the program was searching the
game tree to the same depth as the old Shannon B strategy program since
the program was more efficient (the plausible move generator took a lot
of time to execute). In other words the program was looking as deep as
the selective program but it was no longer haunted by the oversights of
static forward pruning. From that time on Shannon A programs dominated
the world of computer chess and pure Shannon B programs died.
So you are facing similar problems like the plausible move generator
programs of that time.
One question. If you say that the eval "looks for *everything* I can
think of" what is the difference in applying "brute force" to a game
tree to applying it to all kinds of evaluation features ?
> Of course, it is not possible to be totally accurate in these
> calculations, sometimes there are too many pins and other complexities,
> but CST tries.
>
> When I first got into serious chess programming, and studied the main
> lines of many programs, it amazed me how *little* they knew. Seriously
> little, and, of course, some are worse than others. Of course, again, they
> rely on the search to stay out of trouble and find combinations.
Yes. It is purely a tradeoff decision. A searcher that knows about
material detects pins, forks etc on its own. No need for knowledge here
since one concept (material) is converted by the search into another one
(fork).
[ snip ]
> Also, I came to realise that with a much heavier eval knowledge
> component, it was possible to become highly speculative in the
> evaluation function. CST, internally, 'wins' material before it is
> realistically won, 'mates' its opponent before it is realistically
> mating.
This is certainly doable but as you noted (see next paragraph) this is a
dangerous concept if the implementation is not 100% right in all cases.
It is that point that makes me think that your concept is basically
doomed.
> Often it gets it wrong, often it gets it right - but the result is a
> fantastically exciting and dynamic style of play. Just about everyday I
> get a thrill/heart attack from some manic game on the autoplayers, where
> CST seems to be playing madness, pieces hanging everywhere, mating attacks
> for both sides. CST says +10.00 pawns, opponent says +2.00 pawns - it
> takes maybe 10 half moves for the situation to resolve.
>
> Two points:
>
> 1. End users at this stage think I'm talking rubbish and their favourite
> program's evaluation function knows plenty. I had an email the other day
> from someone alleging that a certain PC program was worth 2000 ELO
> evaluation function alone.
No evaluation function is worth 2000 ELO. A combination of search and
knowledge should be worth at least 2000 ELO (otherwise the programmer is
in the wrong business).
> 2. Bob Hyatt's line is that my approach is just an extension on the
> scale of knowledge in the eval versus knowledge in the search. He
> uses the 'cylinder' analogy.
Search and knowledge can be equivalent. The old "I don't care why it is
strong" claim of mine, you know. Knowledge gets interesting if it does
express a concept that can be found by search alone and that does not
influence existing parts of knowledge. Knowledge that fails in this
points is simply a waste of execution time.
It would be much more interesting if you would work on identifying such
knowledge and its implementation instead of dealing with tactical
concepts that are solved by a brute force search. In other words why
don't you work on *chess knowledge* instead of working on "trivial
things" like tactical accuracy ?
I feel that such work would be much more rewarding for your own program
as well as for computer chess in general.
> I claim that when the evaluation function is knowledge packed, and
> this knowledge is used for search guidance, and for speculation, that
> *qualitative* differences emerge between this and the classical style
> programs.
Yes. I am really trying hard to suppress a sardonic smile but I fail...
> So, I'm not claiming that I do anything special. Simply that no-one
> else has stuck long enough at this approach to make it work.
To be frank I am a bit surprised by your post since there is nothing new
in this idea. It looks to me that you are still simply living in the
60ties and you are still fighting with the problems the chess
programmers had in the 60ties. I have a hard time to understand why you
don't move on to the 70ties but this is your life.
> And, lastly, programs are pretty good now, we have much program space
> in PC's (it not like there's only 64K for code anymore).
Big oversight here. I know that this is of little interest for you but
making a program as small and lean as possible is a big win in itself.
On workstations & PeeCees you gain speed because your program can run
exclusively from the 1st level cache. On even smaller machines you may
have nothing more than 64 K for the program etc.
[ snip ]
-- Peter
Martin Borriss
In article <4qvlk1$l...@europa.frii.com>, kerr...@frii.com (Tom Kerrigan) writes:
> If I gave the impression that this is some sort of bug, I'm sorry, because I know
> exactly what the problem is and I don't really need to investigate anything. It's
> just a sort of design flaw that would take almost a complete rewrite to fix, and I
> don't care to do this for a performance gain of 20% that may or may not happen
> with my particular program. I don't care to explain this flaw here, but please
> don't tell me it's a bug, or something I need to look at.
>
As I understood the comment Bob Hyatt was just hinting at a possible source
for improvement in an objective way. There is another thread where you are
very picky about political correctness...
This was just to justify the followup.
Ok, I just wanted to report that a first compile under Linux with gcc 2.7.2
gave me on a P133 220k - 400k generate/make/undo cycles. So, for me
the matter is closed. It will go a little slower (no hash key updates
currently included) when complete, although there is still room for
optimization.
You probably don't want to know how 'fast' the old generator was. Neither
do I ;) - but the program reached almost 2200 in Blitz...
Martin
Robert Hyatt
: Interesting thread. Before you read any further please note that I do
Blitz v4 (circa 1977) was a highly selective program. It had over 50,000
lines of code in the forward pruning code alone. It also had some very
clever code that would let the search progress, discover a tactical nuance,
and then find a defense to that tactic. It worked well, and found some
truly brilliant tactical things. It also made some truly brilliant
positional gaffes and an occasional gross tactical blunder. Around 1978
after having seen chess 4.0 first-hand at the ACM event in Houston, and
then Duchess at the WCCC in Toronto in 1977 (Duchess went full-width in
time to use the new program in 1977 and did quite well there), Blitz v5
was born and it, too, was full-width. And it played better with 10,000
lines of code that V4 did with some 120,000 lines. It was nice to not
have to have code for every special tactical case, because I was continually
adding special cases. The new code treated all of these cases with a good
dose of speed, and it played better. *much* better. That's not to say
that we haven't come a long way. Check extensions, recapture extensions,
singular extensions, one-reply extensions, etc... have all helped current
programs to look deeper when they should, although they still fall short
in some positions. This can slowly be solved.
However, there are *some* chess considerations that search is not ever
going to solve. The last two DB/Kasparov games illustrate such points.
Handling such positions needs more. *much* more. However, I don't subscribe
to Chris's postulate that a brute-force program can't do this. It seems to
me that knowledge and search can be two separate issues, at least for a
few more years. I agree that eventually knowledge must guide the search
as the knowledge becomes more sophisticated. However, even that can be
done with brute-force. I'm not convinced the two things are incompatible
yet.
:
: So you are facing similar problems like the plausible move generator
: programs of that time.
:
: One question. If you say that the eval "looks for *everything* I can
: think of" what is the difference in applying "brute force" to a game
: tree to applying it to all kinds of evaluation features ?
Exactly the point. I've made that statement many times. If you do good
forward pruning, you are likely going to expend just as much work pruning
the moves that you would if you actually searched the moves. Otherwise
your program is going to make blunders.
:
: > Of course, it is not possible to be totally accurate in these
: > calculations, sometimes there are too many pins and other complexities,
: > but CST tries.
: >
: > When I first got into serious chess programming, and studied the main
: > lines of many programs, it amazed me how *little* they knew. Seriously
: > little, and, of course, some are worse than others. Of course, again, they
: > rely on the search to stay out of trouble and find combinations.
:
: Yes. It is purely a tradeoff decision. A searcher that knows about
: material detects pins, forks etc on its own. No need for knowledge here
: since one concept (material) is converted by the search into another one
: (fork).
:
: [ snip ]
:
: > Also, I came to realise that with a much heavier eval knowledge
: > component, it was possible to become highly speculative in the
: > evaluation function. CST, internally, 'wins' material before it is
: > realistically won, 'mates' its opponent before it is realistically
: > mating.
:
: This is certainly doable but as you noted (see next paragraph) this is a
: dangerous concept if the implementation is not 100% right in all cases.
: It is that point that makes me think that your concept is basically
: doomed.
I see this all the time in Crafty, and I don't think it's particularly
unique. How many have watched crafty playing, see the eval at +1.5, and
count pieces/pawns and get "even"??? I won't pretend to believe that it's
always right, but a brute-force program can play this game just as well as
a selective searcher. I have lots of positional terms that exceed a pawn,
and a few that exceed a rook. So far, it seems to work ok... but lots of
work and lots more ideas are still needed.
:
: > Often it gets it wrong, often it gets it right - but the result is a
: > fantastically exciting and dynamic style of play. Just about everyday I
: > get a thrill/heart attack from some manic game on the autoplayers, where
: > CST seems to be playing madness, pieces hanging everywhere, mating attacks
: > for both sides. CST says +10.00 pawns, opponent says +2.00 pawns - it
: > takes maybe 10 half moves for the situation to resolve.
Happens all the time on ICC between Crafty and Fritz, between Crafty and
Genius, between Crafty and IM's, between Crafty and GM's... you get the
drift. One serious issue that I've mentioned before is that Crafty is pretty
"speculative" in it's style. Against humans it attacks well sometimes, and
finds interesting ways to keep the game exciting. Against programs it is
often *too* exciting.
: >
: > Two points:
: >
: > 1. End users at this stage think I'm talking rubbish and their favourite
: > program's evaluation function knows plenty. I had an email the other day
: > from someone alleging that a certain PC program was worth 2000 ELO
: > evaluation function alone.
:
: No evaluation function is worth 2000 ELO. A combination of search and
: knowledge should be worth at least 2000 ELO (otherwise the programmer is
: in the wrong business).
:
: > 2. Bob Hyatt's line is that my approach is just an extension on the
: > scale of knowledge in the eval versus knowledge in the search. He
: > uses the 'cylinder' analogy.
:
: Search and knowledge can be equivalent. The old "I don't care why it is
: strong" claim of mine, you know. Knowledge gets interesting if it does
: express a concept that can be found by search alone and that does not
: influence existing parts of knowledge. Knowledge that fails in this
: points is simply a waste of execution time.
Excellent point. If search can resolve something faster/more accurately/
easier than knowledge, then that's the right domain to tackle the issue in.
There are lots of ideas, however, that don't fit search. One example is
two connected passed pawns on the 6th. In the right circumstances they
are worth more than a rook. In others they are worth two pawns. Search
is rarely going to figure out which is which. Crafty's eval makes a good
start at this. If you analyze the typical computer's games, I'd bet that
this issue is important in maybe 1 out of 100 games. In Crafty, I'd bet
I see it in 1 out of 25. Because it "knows" about the possibilities...
not because it searches the possibilities, although I wish I could do it
with search.
:
: It would be much more interesting if you would work on identifying such
: knowledge and its implementation instead of dealing with tactical
: concepts that are solved by a brute force search. In other words why
: don't you work on *chess knowledge* instead of working on "trivial
: things" like tactical accuracy ?
:
: I feel that such work would be much more rewarding for your own program
: as well as for computer chess in general.
:
: > I claim that when the evaluation function is knowledge packed, and
: > this knowledge is used for search guidance, and for speculation, that
: > *qualitative* differences emerge between this and the classical style
: > programs.
Quite possible. However, the unanswered question is can your approach
actually produce something that a good search + eval program can't? I
have always hoped that such an approach would work. I've generally found
(so far) that the fast approach produces similar quality with fewer mistakes.
one principle of software engineering is the bigger the code, but more bugs
lurk within. That was what I saw in Blitz v4, and I saw that reduce in v5.
Something that would be nice to have happen is for everyone to share ideas
where eval produces better results than search and vice versa. It would
likely improve the rate of progress in computer chess in general. The current
aura of secrecy means everyone either re-invents the wheel, or some wheels
never get invented at all in some programs. I'd bet the the union of all
the knowledge in all the programs, and all the search tricks in all the
programs represents a really significant amount of work, and would be able
to play significantly stronger than any current program. Alas, we'll likely
never know, of course.
:
: Yes. I am really trying hard to suppress a sardonic smile but I fail...
:
: > So, I'm not claiming that I do anything special. Simply that no-one
: > else has stuck long enough at this approach to make it work.
I stuck with it for 7-8 years of course, but eventually moved to search
methods that were (at the time, at least) more accurate. maybe the tide
will turn one day...
:
: To be frank I am a bit surprised by your post since there is nothing new
Ed Schroder
>Chris Whittington <chr...@cpsoft.demon.co.uk> wrote:
[ snip ]
> Briefly:
> The evaluation function is responsible for making pruning, extension
> and candidate move decisions.
:Sounds like the typical 60ties design.
REBEL (in general) does the same as CST.
There is no need to do a nullmove since all info comes from the
evaluation function and doing a nullmove would be a waste of time
for Rebel.
Old fashioned?
Maybe, but I am pretty satisfied with the system even after 16 years.
[ snip ]
> Also, I came to realise that with a much heavier eval knowledge
> component, it was possible to become highly speculative in the
> evaluation function. CST, internally, 'wins' material before it is
> realistically won, 'mates' its opponent before it is realistically
> mating.
:This is certainly doable but as you noted (see next paragraph) this is a
:dangerous concept if the implementation is not 100% right in all cases.
:It is that point that makes me think that your concept is basically
:doomed.
In the past I have experimented in this area too, resulting in fantastic
attack games but also hopeless losses. Finally I have chosen for the
balance, meaning for example that if Rebel sacrifices a pawn it should
a correct sacrifice in at least 95% of the cases.
Speculative play: Dangerous? Yes , Doomed? No
[ snip ]
:No evaluation function is worth 2000 ELO. A combination of search and
:knowledge should be worth at least 2000 ELO (otherwise the programmer is
:in the wrong business).
I agree.
I think Chris meant that if you put the program on LEVEL PLY=1 the
program will play on a rating of 2000. This would prove that the programs
evaluation function is 2000 ELO points.
I don't know such a program and I doubt if such a program exists (1 ply,
no extensions, only Q-search)
[ snip ]
:To be frank I am a bit surprised by your post since there is nothing new
:in this idea. It looks to me that you are still simply living in the
:60ties and you are still fighting with the problems the chess
:programmers had in the 60ties. I have a hard time to understand why you
:don't move on to the 70ties but this is your life.
Disagree.
Sure, the basic ideas are old fashioned, but through the years the
ideas are improved and fine tuned. Others stopped looking for new ways,
I am in favor for the old approach and I am (mostly!) happy with it.
- Ed Schroder -
Jackie Meyer
Marcel Nijman <mar...@mbfys.kun.nl> wrote:
>Robert Hyatt wrote:
>> Marcel Nijman (mar...@mbfys.kun.nl) wrote:
>> : Can anybody please explain in a few sentences what the 0x88 approach is?
>[explaination deleted]
[Use 16x8 board. Check for off board with one test.]
>I don't really see why this should be faster than doing something like
>the following:
>i = rook_vertical_index[sq0];
>while (TRUE)
>{ sq1 = rook_vertical[i];
> if (sq1 == END_MARKER)
> break;
> if (color(sq1) != my_color)
> add_move(sq0, sq1);
> if (board[sq1] != EMPTY)
> break;
> i++;
>}
If you do this, then you might as well eliminate the test for the end
marker by using the 10x12 board. Then you just have to check sq1 for
a piece of your color to detect the edge of the board.
>where `rook_vertical_index[sq0]' is the offset for the array
>`rook_vertical' where the squares are stored that can be reached from
>sq0.
>To me, both approaches seem to be equally efficient.
Or inefficient. All this stuff is machine specific anyway, so...
Besides, we're all maintaining multiple board/piece representations,
so we can speed up the evaluation functions - right?
Regards,
Jackie.
Tom Kerrigan
nothing today. I think of my program as brute force, but the depth I use the
evaluation function score at is totally up for grabs, because of null move and all
the extensions I use. I don't even think the epitome of the brute force searcher,
CHESS 4.0, was really brute force, seeing as it had check extensions. Now look at
today's selective programs and find one that doesn't use brute force somewhere. As
I understand it, the truly selective programs (MacHack, maybe?) simply couldn't
solve certain problems given all the time in the universe because they pruned the
correct move. Not the case today: think of a problem that a modern program can't
solve given an infinite amount of time...
With this in mind, it seems that Peter and Chris are not living in different
decades and their programs aren't totally different. They just disagree on where
to put the knowledge. For this reason, I suggest all talk of which program will be
the world champion be dropped.
Cheers,
Tom
_______________________________________________________________________________
Tom Kerrigan kerr...@frii.com O-
In Seattle, Washington, it is illegal to carry a concealed weapon that
is over six feet in length.
Chris Whittington
>
> Take a step back and you see that "brute force" and "selective search" mean
> nothing today. I think of my program as brute force, but the depth I use the
> evaluation function score at is totally up for grabs, because of null move and all
> the extensions I use.
The pruning is 'tapered-forward'.
Going backwards (towards the root), there's little point in pruning
with great fineness - or, nearer to the root, even selective
programs are probably full-width.
'truly' selective would just be too politically correct.
> I don't even think the epitome of the brute force searcher,
> CHESS 4.0, was really brute force, seeing as it had check extensions. Now look at
> today's selective programs and find one that doesn't use brute force somewhere. As
> I understand it, the truly selective programs (MacHack, maybe?) simply couldn't
> solve certain problems given all the time in the universe because they pruned the
> correct move. Not the case today: think of a problem that a modern program can't
> solve given an infinite amount of time...
Er, infinite time, not available, I'm afraid.
>
> With this in mind, it seems that Peter and Chris are not living in different
> decades and their programs aren't totally different. They just disagree on where
> to put the knowledge.
No way am I living in the same decade, continent, world as Gillgasch.
Long may the fragmentation continue :)
> For this reason, I suggest all talk of which program will be
> the world champion be dropped.
>
I thought we were talking about general method, no ?
Chris Whittington
>
> Cheers,
> Tom
>
Chris Whittington
No deal. I reserve the right to say what I think.
You can take me seriously or not, its up to you, but:
(a) taking me seriously wouldn't be your style
(b) it would probably be the kiss of death :)
Alone, minority of one, no problem. I can still be right and you
all wrong. Alternatively, it may just be that the language is not
yet developed for communication to succeed.
There's been a lot of simple, and endless, repetition of position
statements associated with these threads to indicate to me that
the problem is more one of understanding than anything else.
From the *university*, oohh, well they *must* be right then, innit ?
Peter, you give yourself away, for you there are two kinds of
knowledge:
(i) that which comes in acceptable packaging (university, bright guys)
(ii) and that which doesn't
As you say, this means that you don't begin to take type (ii)
knowledge seriously. You can stay in your world if you like, no
problem.
>
> So you are facing similar problems like the plausible move generator
> programs of that time.
>
No, plausible move generation is successful (relatively),
Problem is planning for all situations. Eg. problem is evaluation,
since for CST evaluation is all. Another problem is bugs,
much code=much bugs. But its getting close.
> One question. If you say that the eval "looks for *everything* I can
> think of" what is the difference in applying "brute force" to a game
> tree to applying it to all kinds of evaluation features ?
1. Brute force (or material based search, we'll say) couldn't cope.
i) not all knowledge can emerge from m-b-s
ii) other knowledge won't emerge from m-b-s within the
available search-space.
2. As we both know, some combinational-base knowledge emerges from
m-b-s. This knowledge is not uniform over the tree, it doesn't
exist at all at the leaf nodes, and it exists maximally at the
root.
An eval-intelligence based program has its knowledge spread uniformly
throughout the tree.
So what, I hear you say. Well, this means that m-b-s main lines
become increasingly knowledge-free with depth. Since the program
plan is to move towards the final moves in the main line, m-b-s
has a fundamental 'lack-of-sensible-plan' problem. This is another
way of saying "it's materialist", all it knows is to eat your
material if you blunder.
It also means that m-b-s in unable to register whether it is about
to fall into a hole at the horizon, or, worse, before the horizon.
Reason: m-b-s has difficuties recognising holes near leaf nodes
because it lacks knowledge near leaf nodes.
So m-b-s spends 99.9999999...999% of its time evaluating nonsensical
positions, and, worse, its evaluations of most of these positions
(those near and at the leaves) are seriously defective. m-b-s cannot
rely on its own evaluation function.
Unable to rely on its own evaluation function, it can't forward
prune, so its branching factor is higher than it need be.
Compare to the intelligent evaluation function.
i) can rely on its evaluation, so can prune forward - result
better branching factor.
ii) can detect holes much better, and create plans to deal with
them - extend, evaluate etc.
iii) can plan to move towards the positions indicated by the
main line, since these are evaluated sensible.
iv) can become speculative, enough 'facts' are known
at evaluation time.
3. m-b-s knowledge is combinatorial only. If the combination doesn't
take place within the available search space, then for m-b-s it doesn't
exist. In other words it only knows what it can resolve, when it
resolves it.
Intelligent eval knows all, all the time, wherever in the search it is.
>
> > Of course, it is not possible to be totally accurate in these
> > calculations, sometimes there are too many pins and other complexities,
> > but CST tries.
> >
> > When I first got into serious chess programming, and studied the main
> > lines of many programs, it amazed me how *little* they knew. Seriously
> > little, and, of course, some are worse than others. Of course, again, they
> > rely on the search to stay out of trouble and find combinations.
>
> Yes. It is purely a tradeoff decision. A searcher that knows about
> material detects pins, forks etc on its own. No need for knowledge here
> since one concept (material) is converted by the search into another one
> (fork).
As previously stated, not all knowledge can emerge from search within
the available search space. Some can, but not all.
Also, some tactical themes may not resolve, or need to resolve, but
their existence, or threat, is of consequence. m-b-s only knows
about such tactical themes if they combinatorially resolve into some
material change.
Intelligent evaluation can know they exist; importantly know that if
they exist in combination (eg multiple threats), that this is a
situation worth aiming for. m-b-s simply doesn't have this knowledge
type.
>
> [ snip ]
>
> > Also, I came to realise that with a much heavier eval knowledge
> > component, it was possible to become highly speculative in the
> > evaluation function. CST, internally, 'wins' material before it is
> > realistically won, 'mates' its opponent before it is realistically
> > mating.
>
> This is certainly doable but as you noted (see next paragraph) this is a
> dangerous concept if the implementation is not 100% right in all cases.
> It is that point that makes me think that your concept is basically
> doomed.
Yup, its dangerous.
Yup, that's the idea.
For materialists: if we launch into 100 dangerous situations, and
come out the other side, better, in 51 of them, it was worth it.
Is the counting simple enough ? :)
>
> > Often it gets it wrong, often it gets it right - but the result is a
> > fantastically exciting and dynamic style of play. Just about everyday I
> > get a thrill/heart attack from some manic game on the autoplayers, where
> > CST seems to be playing madness, pieces hanging everywhere, mating attacks
> > for both sides. CST says +10.00 pawns, opponent says +2.00 pawns - it
> > takes maybe 10 half moves for the situation to resolve.
> >
> > Two points:
> >
> > 1. End users at this stage think I'm talking rubbish and their favourite
> > program's evaluation function knows plenty. I had an email the other day
> > from someone alleging that a certain PC program was worth 2000 ELO
> > evaluation function alone.
>
> No evaluation function is worth 2000 ELO. A combination of search and
> knowledge should be worth at least 2000 ELO (otherwise the programmer is
> in the wrong business).
Pleased you agree.
>
> > 2. Bob Hyatt's line is that my approach is just an extension on the
> > scale of knowledge in the eval versus knowledge in the search. He
> > uses the 'cylinder' analogy.
>
> Search and knowledge can be equivalent. The old "I don't care why it is
> strong" claim of mine, you know. Knowledge gets interesting if it does
> express a concept that can be found by search alone and that does not
> influence existing parts of knowledge. Knowledge that fails in this
> points is simply a waste of execution time.
Poor processor, my heart bleeds :)
More seriously, I agree that search and knowledge *can* be equivalent.
But, oh, read back, I'm not going to repeat ...
>
> It would be much more interesting if you would work on identifying such
> knowledge and its implementation instead of dealing with tactical
> concepts that are solved by a brute force search. In other words why
> don't you work on *chess knowledge* instead of working on "trivial
> things" like tactical accuracy ?
>
> I feel that such work would be much more rewarding for your own program
> as well as for computer chess in general.
Thanks for the tip :)
But, you don't understand. tactical accuracy is not what I'm after -
I can't achieve it anyway - tactical mania would be a better
description.
Tactical themes are positional, if treated in the right way. See back
to comments on *resolution* of tactical threats. (they don't need to
resolve to be highly important, but m-b-s doesn't know that).
>
> > I claim that when the evaluation function is knowledge packed, and
> > this knowledge is used for search guidance, and for speculation, that
> > *qualitative* differences emerge between this and the classical style
> > programs.
>
> Yes. I am really trying hard to suppress a sardonic smile but I fail...
>
Yes, I understand..
I'm on the other side of the looking-glass. You are not going
to change your belief in your way, it's not my task to persuade you.
> > So, I'm not claiming that I do anything special. Simply that no-one
> > else has stuck long enough at this approach to make it work.
>
> To be frank I am a bit surprised by your post since there is nothing new
> in this idea. It looks to me that you are still simply living in the
> 60ties and you are still fighting with the problems the chess
> programmers had in the 60ties. I have a hard time to understand why you
> don't move on to the 70ties but this is your life.
Pah.
You're enough of a philosopher to know that the number of new ideas
this century can be counted on the fingers of one hand.
Most 'new' ideas are re-workings of old ones. Old stuff put together
in a new way. An old idea, that becomes realisable through external
changes, in technology or whatever.
Come on, you were doing well, this 50ies, 60ies stuff lets you down.
>
> > And, lastly, programs are pretty good now, we have much program space
> > in PC's (it not like there's only 64K for code anymore).
>
> Big oversight here. I know that this is of little interest for you but
> making a program as small and lean as possible is a big win in itself.
> On workstations & PeeCees you gain speed because your program can run
> exclusively from the 1st level cache. On even smaller machines you may
> have nothing more than 64 K for the program etc.
>
Oh, dear. Descent into cheap-cheap cliches. Big oversight, pah !
Deeply minor point, that has little relevance.
> [ snip ]
>
> -- Peter
Der Weg ist das Ziel, Peter, der Weg *ist* das Ziel.
Chris Whittington
Peter W. Gillgasch
> gil...@ilk.com (Peter W. Gillgasch) wrote:
[ snip ]
> No deal. I reserve the right to say what I think.
I just wanted to avoid that I ask myself the following question:
"Ah another Whittington post. Will he just snipe or is it interesting?"
If you think about it you *never* see a post that says something like
this: "Oh guys, another chess specific knowledge issue. Can we move on
to discuss something really important like making a program really
fast?"
OTOH if you exchange the themes in the hypothetical sentence above then
this would be a "typical" Whittington question.
> You can take me seriously or not, its up to you, but:
> (a) taking me seriously wouldn't be your style
So you know me that well, hm?
> (b) it would probably be the kiss of death :)
>
> Alone, minority of one, no problem. I can still be right and you
> all wrong.
Sure. Or the other way round (which is somehow more likely).
> Alternatively, it may just be that the language is not
> yet developed for communication to succeed.
> There's been a lot of simple, and endless, repetition of position
> statements associated with these threads to indicate to me that
> the problem is more one of understanding than anything else.
I don't think so. I just wanted to begin a discussion about your ideas
in a more detailed fashion. I therefore repeated some points on which
you could comment to get the discussion going. If you now conclude that
anybody is trying to convince you or is just repeating boring matters of
belief then I am sorry.
[ snip ]
> > As I mentioned in an earlier post those problems lead two bright guys
> > (Slate & Atkin from the Northwestern University Chess Program) to the
[ snip ]
> From the *university*, oohh, well they *must* be right then, innit ?
>
> Peter, you give yourself away, for you there are two kinds of
> knowledge:
> (i) that which comes in acceptable packaging (university, bright guys)
> (ii) and that which doesn't
This just tells that you don't know me as well. Show me an university
project and I show you something that is sub-optimal to say the least :)
> As you say, this means that you don't begin to take type (ii)
> knowledge seriously. You can stay in your world if you like, no
> problem.
Now what I really hate is people telling me what I am thinking... Your
arrogance is going on my nerves.
[ snip ]
> Problem is planning for all situations. Eg. problem is evaluation,
> since for CST evaluation is all. Another problem is bugs,
> much code=much bugs. But its getting close.
That is the reason why I stated that I believe that your approach is
"doomed". Complexity and correctness are not really good friends.
[ snip ]
> 1. Brute force (or material based search, we'll say) couldn't cope.
[I snip this just to fool my newsreader, sorry]
> An eval-intelligence based program has its knowledge spread uniformly
> throughout the tree.
That's a good explanation. Thanks.
> So what, I hear you say. Well, this means that m-b-s main lines
[ again ]
> because it lacks knowledge near leaf nodes.
Or search depth since knowledge and search are interchangable.
> So m-b-s spends 99.9999999...999% of its time evaluating nonsensical
[ and again ]
> Intelligent eval knows all, all the time, wherever in the search it is.
I cannot see the difference between a full width program that is
equipped with a very complex evaluation function at terminal nodes with
the exception of the forward pruning stuff (which is of course
important).
[ snip ]
> Also, some tactical themes may not resolve, or need to resolve, but
> their existence, or threat, is of consequence. m-b-s only knows
> about such tactical themes if they combinatorially resolve into some
> material change.
Agreed.
> Intelligent evaluation can know they exist; importantly know that if
> they exist in combination (eg multiple threats), that this is a
> situation worth aiming for. m-b-s simply doesn't have this knowledge
> type.
[ snip ]
> Yup, its dangerous.
> Yup, that's the idea.
>
> For materialists: if we launch into 100 dangerous situations, and
> come out the other side, better, in 51 of them, it was worth it.
>
> Is the counting simple enough ? :)
Not really since you need something to compare with. If a "materialist"
program comes out in 70 of them (possibly by being a "coward" and not
playing into the dangerous situation)....
[ snip ]
> > Search and knowledge can be equivalent. The old "I don't care why it is
> > strong" claim of mine, you know. Knowledge gets interesting if it does
> > express a concept that can be found by search alone and that does not
Typo here. Intended to say "can't be found" of course.
> > influence existing parts of knowledge. Knowledge that fails in this
> > points is simply a waste of execution time.
>
> Poor processor, my heart bleeds :)
Now c'mon.
[ snip ]
> > I feel that such work would be much more rewarding for your own program
> > as well as for computer chess in general.
>
> Thanks for the tip :)
Welcome.
[ snip ]
> > Yes. I am really trying hard to suppress a sardonic smile but I fail...
>
> Yes, I understand..
>
> I'm on the other side of the looking-glass. You are not going
> to change your belief in your way, it's not my task to persuade you.
Nor is it mine to persuade you.
[ snip ]
> Come on, you were doing well, this 50ies, 60ies stuff lets you down.
I was just trying to get you into discussing one of my main objections
that I expressed in an earlier post. All the guys that tried "human
style" programs tried "materialist" programs later and never returned.
Assuming that you believe that you can evaluate pretty good why don't
you try this as well instead of taking the hard chess specific way of
searching?
[ snip ]
> Oh, dear. Descent into cheap-cheap cliches. Big oversight, pah !
> Deeply minor point, that has little relevance.
I see. You have no idea what you are toying with (in terms of the
machine you are using). I am not surprised that you get a huge speedup
on the P6. Well... Since this is a deeply minor point it is obvious that
you will not like the answer... You should work in an university
environment with a couple of megabytes to waste :)
[ snip ]
> Der Weg ist das Ziel, Peter, der Weg *ist* das Ziel.
Esoteric hogwash.
Ok, walk through the darkness alone. While this post and this thread was
interesting I feel that you and your following are not able to have a
serious discussion and exhibit a striking amount of arrogance and
fanatism.
I do not intend to discuss this further.
-- Peter
Robert Hyatt
C'mon. You are either being provocative or are ignorant to the point of
being an embarassment to your parents. Ever talked to Slate? Most of us
have. Know anything about him when he was doing chess 4.x? Thought so.
He wasn't ever a "faculty" member, so far as I know. He was a student, and
later worked in the computer center. What's that got to do with (a) his
intelligence and (b) his capabilities? If you have a hard-on for university
types, you ought to take that discussion to alt.dickheads or something. I'd
turn this around and say that most interesting breakthroughs *did* come from
research universities. Not all, but certainly *most*. And it has nothing to
do with this discussion. Good ideas are good, bad ideas are bad, regardless
of the source. So let's drop the university bashing, US bashing, Germany
bashing, etc... and keep the discussion on computer chess. The name of the
newsgroup has something to do with the latter, but not the former.
:
:
: >
: > So you are facing similar problems like the plausible move generator
: > programs of that time.
: >
:
: No, plausible move generation is successful (relatively),
:
: Problem is planning for all situations. Eg. problem is evaluation,
: since for CST evaluation is all. Another problem is bugs,
: much code=much bugs. But its getting close.
As I mentioned before, this is one good reason for the success of the
current search-driven chess programs. Smaller code = fewer bugs = better
play (fewer blunders.) Personally, I hope you or someone else succeeds,
because I don't think search alone is enough to play at the very highest
level. It's easy to bloat the evaluation in Crafty, but measuring how a
change performs is difficult. Some changes make Crafty play slower but
better, others make it faster and better, others make it play worse against
fast search programs but better against humans, etc. With lots of goals,
it's difficult.
:
: > One question. If you say that the eval "looks for *everything* I can
: > think of" what is the difference in applying "brute force" to a game
: > tree to applying it to all kinds of evaluation features ?
:
: 1. Brute force (or material based search, we'll say) couldn't cope.
: i) not all knowledge can emerge from m-b-s
: ii) other knowledge won't emerge from m-b-s within the
: available search-space.
:
: 2. As we both know, some combinational-base knowledge emerges from
: m-b-s. This knowledge is not uniform over the tree, it doesn't
: exist at all at the leaf nodes, and it exists maximally at the
: root.
:
: An eval-intelligence based program has its knowledge spread uniformly
: throughout the tree.
Not exactly, otherwise you wouldn't be doing the search, eh? I can visualize
three types of programs: (1) fast search, poor eval; (2) *no* search, complex
eval and (3) something in between. I don't classify any current program except
maybe Fritz in (1), and I don't know of any program that fits in (3). Everyone
else seems to be kissing cousins stuck in (2).
:
: So what, I hear you say. Well, this means that m-b-s main lines
: become increasingly knowledge-free with depth. Since the program
: plan is to move towards the final moves in the main line, m-b-s
: has a fundamental 'lack-of-sensible-plan' problem. This is another
: way of saying "it's materialist", all it knows is to eat your
: material if you blunder.
Not always. I can show you lots of games that Crafty plays where it knows
that to take a pawn is bad, even though the search doesn't reveal why. I
could show you a game against WchessX last night where wchess though the game
was even, Crafty thought it was +4.5, due to some endgame knowledge it uses,
even when in a R+B+P's ending. Turned out that in this game, it was right.
In other games, it's been wrong. That doesn't sound like a completely
materialistic program. I'd suspect Fritz will take a pawn when it's offered,
and will most likely escape the consequences due to its fast search. Against
a top-level player, it'd get thrashed for doing so of course.
:
: It also means that m-b-s in unable to register whether it is about
: to fall into a hole at the horizon, or, worse, before the horizon.
: Reason: m-b-s has difficuties recognising holes near leaf nodes
: because it lacks knowledge near leaf nodes.
:
: So m-b-s spends 99.9999999...999% of its time evaluating nonsensical
: positions, and, worse, its evaluations of most of these positions
: (those near and at the leaves) are seriously defective. m-b-s cannot
: rely on its own evaluation function.
Exactly why we do the search part. However, as I said, I'm under the
impression you are doing a search too. This implies that your eval also
can't cope with things?
:
: Unable to rely on its own evaluation function, it can't forward
: prune, so its branching factor is higher than it need be.
:
: Compare to the intelligent evaluation function.
: i) can rely on its evaluation, so can prune forward - result
: better branching factor.
and blunders of course.
: ii) can detect holes much better, and create plans to deal with
: them - extend, evaluate etc.
Why can't any program do this?
: iii) can plan to move towards the positions indicated by the
: main line, since these are evaluated sensible.
Ditto this.
: iv) can become speculative, enough 'facts' are known
: at evaluation time.
and this. I see wchessx play speculative moves. I see Crafty do almost too
many speculative moves. I don't see the difference between what you claim to
do and what others claim to do, except for details...
:
: 3. m-b-s knowledge is combinatorial only. If the combination doesn't
: take place within the available search space, then for m-b-s it doesn't
: exist. In other words it only knows what it can resolve, when it
: resolves it.
: Intelligent eval knows all, all the time, wherever in the search it is.
One simple thing I discussed a while back was Bxa7 types moves, where b6 traps
the bishop. I know how to evaluate this, and most of the time Crafty does it
right. On occasion, it fails and simply loses a pawn. To make it better requires
more time in the search. or more time in the eval analysis. The former is
easier to make correct at present. The latter produces big code with lots
of bugs.
:
: >
: > > Of course, it is not possible to be totally accurate in these
Tom Kerrigan
>> the world champion be dropped.
>>
>
>I thought we were talking about general method, no ?
Are we? Huh. I seem to recall you saying a Peter-ish program will never beat
Kasparov. Maybe this was to a different thread.
Cheers,
Tom
_______________________________________________________________________________
Tom Kerrigan kerr...@frii.com O-
Justice, n.:
A decision in your favor.
Chris Whittington
You are way out of line.
There is no bashing of Slate or universities. Read again.
The point was relating to the *packaging* of knowledge. You are not
so young as to have not come across this phenomenon.
If the knowledge comes in the 'right', packaging it gets accepted,
otherwise it's deeply suspected.
I was alleging that Peter's acceptable packaging is
university/bright guy, and he assumes I don't fit his
requirement.
Where's the Slate/university bashing ? Hmmm ?
Pause next time please, before using such intemperate language.
Believe me, I have no problems with 'university types' (I've been through
the system three times to date) other than a suspicion that scientific
acedemia does tend to only respect 'facts' and 'theories' that come
from other bits of acedemia. But we know this, I needn't elaborate.
BTW I don't bash germans either. My ex-wife is German, two of my
children are half-german, my girlfriend is german. I like them.
> :
> :
> : >
> : > So you are facing similar problems like the plausible move generator
> : > programs of that time.
> : >
> :
> : No, plausible move generation is successful (relatively),
> :
> : Problem is planning for all situations. Eg. problem is evaluation,
> : since for CST evaluation is all. Another problem is bugs,
> : much code=much bugs. But its getting close.
>
> As I mentioned before, this is one good reason for the success of the
> current search-driven chess programs. Smaller code = fewer bugs = better
> play (fewer blunders.) Personally, I hope you or someone else succeeds,
> because I don't think search alone is enough to play at the very highest
> level.
Thank you - and ultimately, I'm not saying much more than that. Search
isn't enough at the top level - I'm developing and believing in, and
putting forward the type of evaluation process that (I believe) will
be enough (together with deep search) and, not necessarily by me
personally, to scrunch Mr K.
The Tal approach says "steer the game towards
chaotic situations, and then 15-20 plies of search will be enough,
for much of the time". The human defence to this will be to stay clear
of chaos, and they may be able to do this; but a chaos steerer, with
sac-ing capability, and 15-20 plies to try and move to chaos in, is
likely to present a big problem.
For this approach to work, you need an evaluation function that can
detect and evaluate chaos. This means abandoning the quiesence
paradigm. This means a qualitative change in chess programs.
Ok, if you still don't see it, I give up (on trying to explain that
is).
> It's easy to bloat the evaluation in Crafty, but measuring how a
> change performs is difficult. Some changes make Crafty play slower but
> better, others make it faster and better, others make it play worse against
> fast search programs but better against humans, etc. With lots of goals,
> it's difficult.
>
> :
> : > One question. If you say that the eval "looks for *everything* I can
> : > think of" what is the difference in applying "brute force" to a game
> : > tree to applying it to all kinds of evaluation features ?
> :
> : 1. Brute force (or material based search, we'll say) couldn't cope.
> : i) not all knowledge can emerge from m-b-s
> : ii) other knowledge won't emerge from m-b-s within the
> : available search-space.
> :
> : 2. As we both know, some combinational-base knowledge emerges from
> : m-b-s. This knowledge is not uniform over the tree, it doesn't
> : exist at all at the leaf nodes, and it exists maximally at the
> : root.
> :
> : An eval-intelligence based program has its knowledge spread uniformly
> : throughout the tree.
>
> Not exactly, otherwise you wouldn't be doing the search, eh?
Obviously, the search is carried out to gain more knowledge about
the position. The issue (for me) is whether or not the evaluation
function can be relied apon by the programmer. If the answer is 'yes'
then qualitative differences emerge - the ability to forward prune
being an obvious one.
You can tell me for Crafty:
1. Does Crafty's eval know if it own king is in check, or does it wait
for the search to capture the king to find out ? Of course, Crafty
knows, but some programs don't.
2. Does Crafty's eval know if it gives check ?
3. Does Crafty's eval know if it's king can be checked next move ?
4. If yes to 3. Does Crafty's eval know if the check would be mate ?
5. If yes to 3. Does Crafty's eval know if its only defence to check
would be to make a losing interpose ?
6. If yes to 5. Does Crafty's eval know if the losing interpose
were captured would it then be mate ?
7. If yes to 3. Does Crafty's eval count king flight squares ?
8. If yes to 3. Does Crafty's eval test flight squares for repetition
draw, for follow through mates etc ?
9. If yes to 7, Does Crafty's eval test flight squares for nite forks
10. etc. etc. - everything king-wise you can think of ....
11. Does Crafty's eval know the above in the converse case of
check threats to the opponent's king ?
12. Similar stuff, but relating to forks, pins, trapped pieces,
attacked pieces etc. etc in the evaluation ?
Ok, I don't know about Crafty, I've not looked closely at it, but, my
guess it that the bulk of programs get to point 2 above, with some going
to 3. Some, very fast materialistic programs don't even know 1.
Some slower commercial programs get higher.
My point remains, the same point that everybody says they don't see:
that such a level of knowledge (plus) in the evaluation leads to
a qualitatively different style of program.
There is so much you can do, that the dismissive, its all equivalent
to finding the knowledge through search, just doesn't see the point.
The above stuff influences the score given to the position, the
range of candidates available from a position, the ability to be
*highly* speculative about the value of the position, and so on.
> I can visualize
> three types of programs: (1) fast search, poor eval; (2) *no* search, complex
> eval and (3) something in between. I don't classify any current program except
> maybe Fritz in (1), and I don't know of any program that fits in (3). Everyone
> else seems to be kissing cousins stuck in (2).
>
I assume you've muddled (2) and (3) here ?
> :
> : So what, I hear you say. Well, this means that m-b-s main lines
> : become increasingly knowledge-free with depth. Since the program
> : plan is to move towards the final moves in the main line, m-b-s
> : has a fundamental 'lack-of-sensible-plan' problem. This is another
> : way of saying "it's materialist", all it knows is to eat your
> : material if you blunder.
>
> Not always. I can show you lots of games that Crafty plays where it knows
> that to take a pawn is bad,
How about take a bishop, or a rook, or a queen, or sac one ?
And not for ending reasons, but middlegame king safety ones ?
> even though the search doesn't reveal why. I
> could show you a game against WchessX last night where wchess though the game
> was even, Crafty thought it was +4.5, due to some endgame knowledge it uses,
> even when in a R+B+P's ending. Turned out that in this game, it was right.
> In other games, it's been wrong. That doesn't sound like a completely
> materialistic program. I'd suspect Fritz will take a pawn when it's offered,
> and will most likely escape the consequences due to its fast search. Against
> a top-level player, it'd get thrashed for doing so of course.
>
Not all programs are entirely materialistic. Most programs have
evaluation terms for positional factors - they'ld get thrashed otherwise.
Its a grey scale; except that beyond a certain take-off point
qualitative changes emerge. This take-off point is the one at which
the programmer (realistically) believes that the eval function
can be trusted *without further search*.
> :
> : It also means that m-b-s in unable to register whether it is about
> : to fall into a hole at the horizon, or, worse, before the horizon.
> : Reason: m-b-s has difficuties recognising holes near leaf nodes
> : because it lacks knowledge near leaf nodes.
> :
> : So m-b-s spends 99.9999999...999% of its time evaluating nonsensical
> : positions, and, worse, its evaluations of most of these positions
> : (those near and at the leaves) are seriously defective. m-b-s cannot
> : rely on its own evaluation function.
>
> Exactly why we do the search part. However, as I said, I'm under the
> impression you are doing a search too. This implies that your eval also
> can't cope with things?
>
If it could, then chess would be solved, so I'ld do a one ply search
and return.
This would be too arrogant, even for me, so I'ld recommend using the
time available to look deeper :)
> :
> : Unable to rely on its own evaluation function, it can't forward
> : prune, so its branching factor is higher than it need be.
> :
> : Compare to the intelligent evaluation function.
> : i) can rely on its evaluation, so can prune forward - result
> : better branching factor.
>
> and blunders of course.
Of course. Again, there's a trade-off between sacrificing search
width to gain search depth. You do it with the null-move, that can
lead to blunders as well, but you hope to gain from the deeper search.
>
> : ii) can detect holes much better, and create plans to deal with
> : them - extend, evaluate etc.
>
> Why can't any program do this?
Any program can, by the application of knowledge to the position.
Our hypothetical m-b-s program doesn't because it wants to be fast,
and to realistically detect the possible holes would take it a
disproportionate amount of evaluation time.
Our hypothetical knowledge based program has already calculated
most of the factors in it evaluation function, so the detection
of holes comes as a time-cheap bonus.
>
> : iii) can plan to move towards the positions indicated by the
> : main line, since these are evaluated sensible.
>
> Ditto this.
Ditto above. Hypothetical m-b-s program doesn't have the time
to evaluate - therefore evals near leaf nodes not sensible.
Why am I repeating ? It seems like we are not operating to the
same meanings of the words .... ?
>
> : iv) can become speculative, enough 'facts' are known
> : at evaluation time.
>
> and this. I see wchessx play speculative moves. I see Crafty do almost too
> many speculative moves. I don't see the difference between what you claim to
> do and what others claim to do, except for details...
Indeed, you've made it clear that you don't :)
I do though.
Chris Whittington
Urban Koistinen
- Urban Koistinen (e...@bengt.algonet.se) wrote:
- : Robert Hyatt (hy...@crafty.cis.uab.edu) wrote:
- : : Marcel Nijman (mar...@mbfys.kun.nl) wrote:
- : : :
- : : : I don't really see why this should be faster than doing something like
- : : : the following:
- : : :
- : : :
- : : : i = rook_vertical_index[sq0];
- : : : while (TRUE)
- : : : { sq1 = rook_vertical[i];
- : : : if (sq1 == END_MARKER)
- : : : break;
- : : : if (color(sq1) != my_color)
- : : : add_move(sq0, sq1);
- : : : if (board[sq1] != EMPTY)
- : : : break;
- : : : i++;
- : : : }
- : : Easy to explain. your line, sq1= ..., results in a
- : : memory fetch, after the
- : : address arithmetic to calculate the address of
- : : rook_vertical is done. With
- : : X88, after calculating the address, you are *done*.
- : : The memory reference is the killer.
- : : Note also that you took the easy case of only moving along a
- : : file. For a bishop,
- : : it steps along a rank and file at the same time so you
- : : have to check *both* before you know the square is illegal.
- : Read the source Bob!
- : He is reading a precalculated array.
- : Bishop and rook moves are pretty much the same then.
- I did. However, he's doing a memory fetch to detect off the board. X88
- eliminates that as I mentioned. It is *not* a huge savings, but it is a
- measurable one.
My comment is right after your sentence about file and bishop.
Bishops and rooks are equally easy in *both* Marcels and the
X88 way of edge detection.
I did not disagree with you about the memory fetch.
Maybe my "Read the source Bob!" should have been
"Missed a point of the source Bob!" for clarity.
Urban Koistinen
: In article <4r0e0m$h...@epimetheus.algonet.se>,
: e...@aristotle.algonet.se says...
Easier for me to do and understand for an 8*8 value anyway,
just like I do understand 10+30 better than 012+036.
: Thanks for the tip :-)
:-)
Chris Whittington
>
> >> For this reason, I suggest all talk of which program will be
> >> the world champion be dropped.
> >>
> >
> >I thought we were talking about general method, no ?
>
> Are we? Huh. I seem to recall you saying a Peter-ish program will never beat
> Kasparov. Maybe this was to a different thread.
>
> Cheers,
> Tom
>
Are you being quite fair, I think I said materialist program,
without specifying a personality associated with it.
I will say, from what Peter says about his program, namely that
it is materialist, that a Peter-ish program won't beat Mr K, if you
want, but I'ld prefer to stick to general method.
But I'm fairly sure (find me the quote if you can, I've been wrong
before, but I'm not going through all the old posts to look)
that I've not said it to date.
Chris Whittington
Robert Hyatt
Right *here*: A direct quote from you, which *immediately followed
peter's comment about slate/atkin and 4.x. If that doesn't apply to
them, just who does it apply to?
Here's what peter said:
: > peter gillgasch wrote:
: > : > As I mentioned in an earlier post those problems lead two bright guys
: > : > (Slate & Atkin from the Northwestern University Chess Program) to the
Here's the words right out of your mouth:
: > : From the *university*, oohh, well they *must* be right then, innit ?
: Pause next time please, before using such intemperate language.
Why don't you pay attention to (a) what you are responding to (b) whether
the response is adding anything to the thread and (c) follow the simple rule
of if you have nothing to contribute, then *contribute nothing.*
:
: Believe me, I have no problems with 'university types' (I've been through
: the system three times to date) other than a suspicion that scientific
: acedemia does tend to only respect 'facts' and 'theories' that come
: from other bits of acedemia. But we know this, I needn't elaborate.
Again, you paint with a broad brush, and cover a lot of ground that needs
to be left unpainted. I get dozens of suggestions a week, and unless I've
already tried them, I do so. I don't have a bias either toward or against
university types. I've been one for 28 years now, and have seen both good
and bad. Ditto for any other field as well.
:
: BTW I don't bash germans either. My ex-wife is German, two of my
:
I still don't think that full-width precludes doing the above. I'm working
on exactly the same ideas, although likely implemented in different ways. I
want to avoid closed positions, avoid simplifying into clear positions, etc.
I'm following this path for multiple reasons. I see crafty zap GM players
all the time when things are complex, and I see it get zapped by IM's when they
steer the game into positions where the program's tactical prowess is
useful. However, it still seems that the search is the obvious way to exploit
tactical opportunities. I don't believe evaluation can do this, without
producing millions of lines of code. However, by the same measure, there are
things that a search can't do without being able to execute zillions of moves
per second, something equally unlikely. I'd bet that once you reach your
"chaos" that Crafty can rip thru it and find the tactical way to exploit
the position. I'd also bet that crafty could use help from what you are doing
in order to reach the positions where its search would be dynamite.
: > It's easy to bloat the evaluation in Crafty, but measuring how a
:
It can ask the question should it be important. So far, however, this has
been a search issue and not an evaluation issue.
: 2. Does Crafty's eval know if it gives check ?
Again there's a function that can answer this, but it's not been used in the
evaluation.
:
: 3. Does Crafty's eval know if it's king can be checked next move ?
nope.
:
: 4. If yes to 3. Does Crafty's eval know if the check would be mate ?
N/A of course...
:
: 5. If yes to 3. Does Crafty's eval know if its only defence to check
: would be to make a losing interpose ?
I've done this in the past. Peter suggested a "one sane response to check"
extension a few years back and I played with it. However, I'd bet I can
create a position where anyone who tries this would produce the wrong
answer. Just because the interpose is unsafe doesn't mean it's hopeless.
I remember one Horowitz example where the first interpose lost the piece,
but the second interpose was crushing. However, the second couldn't be
played until the first cleared the way. That's the type of problem position
I'd hate to try to handle, which is why I think the search is the right way
to evaluate that.
:
: 6. If yes to 5. Does Crafty's eval know if the losing interpose
: were captured would it then be mate ?
:
: 7. If yes to 3. Does Crafty's eval count king flight squares ?
:
: 8. If yes to 3. Does Crafty's eval test flight squares for repetition
: draw, for follow through mates etc ?
:
: 9. If yes to 7, Does Crafty's eval test flight squares for nite forks
:
: 10. etc. etc. - everything king-wise you can think of ....
:
: 11. Does Crafty's eval know the above in the converse case of
: check threats to the opponent's king ?
:
: 12. Similar stuff, but relating to forks, pins, trapped pieces,
: attacked pieces etc. etc in the evaluation ?
trapped pieces, yes. Pinned pieces, yes once, no at present, because
it stopped being a problem at 10 plies or so. At least I've not seen many
cases where a pin led to a loss.
:
: Ok, I don't know about Crafty, I've not looked closely at it, but, my
: guess it that the bulk of programs get to point 2 above, with some going
: to 3. Some, very fast materialistic programs don't even know 1.
: Some slower commercial programs get higher.
:
: My point remains, the same point that everybody says they don't see:
: that such a level of knowledge (plus) in the evaluation leads to
: a qualitatively different style of program.
: There is so much you can do, that the dismissive, its all equivalent
: to finding the knowledge through search, just doesn't see the point.
I won't argue the point. However, if I want to compute the sine of an
angle, I use the trig library, not something that *can* do it, but not
as well. To evaluate tactics, I believe the search is the proper
AI approach to accomplish this. If the tactics have been resolved, then
the evaluation is the right thing to use.
I'll even concede that the evaluation can be used elsewhere. One simple
example, when to trade. In Cray Blitz, if the pawn score returned a big
number, CB would try to trade, knowing it had a significant advantage in
pawn structure, and this advantage increases as material is removed. This
could be used to include or exclude trades if wanted.
However, to have the evaluation attempt to evaluate tactics might work in
theory, but I doubt it'll work in practice, because the search is a general
approach that handles a myriad of different tactical possibilities without
having domain-specific information coded in. The evaluation will have so
many special-cases, code bloat doesn't do it justice. As I mentioned,
Blitz V4 was over 120,000 lines of code. Blitz V5 was 10,000. The
reduction was caused by canning the plausible move generator and tactical
analyzer, and replacing them with something much more reliable and bug-free.
:
: The above stuff influences the score given to the position, the
: range of candidates available from a position, the ability to be
: *highly* speculative about the value of the position, and so on.
:
: > I can visualize
: > three types of programs: (1) fast search, poor eval; (2) *no* search, complex
: > eval and (3) something in between. I don't classify any current program except
: > maybe Fritz in (1), and I don't know of any program that fits in (3). Everyone
: > else seems to be kissing cousins stuck in (2).
: >
:
: I assume you've muddled (2) and (3) here ?
:
: > :
: > : So what, I hear you say. Well, this means that m-b-s main lines
: > : become increasingly knowledge-free with depth. Since the program
: > : plan is to move towards the final moves in the main line, m-b-s
: > : has a fundamental 'lack-of-sensible-plan' problem. This is another
: > : way of saying "it's materialist", all it knows is to eat your
: > : material if you blunder.
: >
: > Not always. I can show you lots of games that Crafty plays where it knows
: > that to take a pawn is bad,
:
:
: How about take a bishop, or a rook, or a queen, or sac one ?
: And not for ending reasons, but middlegame king safety ones ?
Happens too often to count. King safety sometimes exceeds the value of a
piece. It's sacrificed the exchange too often to count, and feedback from
GM players has always been amazement. (a) that it did it and (b) that the
GM considered it the correct move to boot.
:
:
: > even though the search doesn't reveal why. I
Tom Kerrigan
Chris, you are posting more and more about how neat-o searches are so amazing. You
seem to be overlooking the fact that having a clever search is simply an
*optimization*! Okay, so your program searches some lines to 50 ply. Good for it.
Now, if I offer you a program that reaches 50 ply with a stupid, inane, slow,
moronic, non-Kasparov-beating brute force (eew! sounds like a swear word, doesn't
it?) searcher, which would you prefer? With all due respect to CST, I prefer the
program that brute forces 50 ply.
Also, with this university bullshit... I read the paragrah you quoted, written by
Peter, and the only occurance of the word "university" that I can recall is in the
name of the damn school. Why the hell are you jumping at this? I live in a city
named "Fort Collins" but you don't see military-bashers annoying me. I think
Hyatt's reply is totally justified.
Cheers,
Tom
_______________________________________________________________________________
Tom Kerrigan kerr...@frii.com O-
If at first you don't succeed, redefine success.
Chris Whittington
This says *nothing* about 'university' or 'Slate'. It was a sarcastic
comment targeted at PG's use of 'universtity + slate' to support
his view (that Shannon B was done and failed), and, by implication,
to attack mine.
If I claim my view is supported by Winston Churchill, it doesn't make my
view any better. My view has to stand or fall on its own merits.
If you say 'oh, well if WC supports it, it must be alright then', I'ld
take that as a sarcastic comment about my attempt to use WC to
democratise my view, to bring in external support that can't
by definition be criticised or questioned - rather than an attack on
the merits or otherwise of WC.
My name's Chris, your name's Bob, I know what I meant, I told you
what I meant - but you know better, so out you come with some
more bluster to justify your original intemperate (rude) comments.
Mild sarcasm I can cope with, outright rudeness (hard-on for
university types, alt-dickheads), from you or anybody else, directed
at me or anybody else, I object to.
As an aside, I don't approve of Thorsten's lumping of Peter with
Boris Becker, Adolf Hitler or whoever. I don't approve of his
implying Peter was a fascist. Thorsten does a lot of work on my
program, he's a great help, he's very intelligent and perceptive, he
has many interesting things to say, but he has his own psycho-ideology,
his own ideas. You've already accused me of saying stuff about
germans, wasn't me, I explained it wasn't me, explained it
wouldn't be me - do you retract? no chance. Can you be wrong? presumably
not.
This thread started as a request to me from Bruce Moreland that I
'explain' my ideas. I tried to do this in a friendly spirit.
That the thread degenerated so quickly into sarcasm, personal attack,
rudeness, acrimony, probably says something about me, I'll admit,
but certainly suggests there is something well wrong with this news
group. Chess players need to guard against fighting zero-sum games
off the chess board.
A bit of admission of error, or apology for rudeness would be a start.
But I've not noticed it yet, anywhere, anytime.
I've better things to waste my time on.
Chris Whittington
Robert Hyatt
Chris Whittington (chr...@cpsoft.demon.co.uk) wrote:
: hy...@crafty.cis.uab.edu (Robert Hyatt) wrote:
: >
Possibly true, but since I can't read your mind, I take/took your statement
at face value. It is *not* the first time you've used that particular
attack. It certainly sounds like "university types are *never* correct"
after factoring in the sarcastic tone you used. You have to remember that
no one can se a smile, nor a facial expression, nor body language, and therefore
have to take what you write at face value. It'd be much more productive to
simply leave such slurs out, or else clearly explain your position in detail,
rather than a "one-liner" followed by a change of topic.
:
: If I claim my view is supported by Winston Churchill, it doesn't make my
: view any better. My view has to stand or fall on its own merits.
But if you are a physicist, and claim your view is supported by a Nobel
prize-winner in physics, it does lend credibility to your position. If you
then claim that the Nobel winner doesn't necessarily know what he's doing,
you should expect a firestorm. *unless* you offer a lot of proof.
: If you say 'oh, well if WC supports it, it must be alright then', I'ld
: take that as a sarcastic comment about my attempt to use WC to
: democratise my view, to bring in external support that can't
: by definition be criticised or questioned - rather than an attack on
: the merits or otherwise of WC.
:
: My name's Chris, your name's Bob, I know what I meant, I told you
: what I meant - but you know better, so out you come with some
: more bluster to justify your original intemperate (rude) comments.
:
: Mild sarcasm I can cope with, outright rudeness (hard-on for
: university types, alt-dickheads), from you or anybody else, directed
: at me or anybody else, I object to.
Me too. Why not confine the conversation to the topics you are interested
in any drop the insulting tone? If you don't agree with my point of view,
that doesn't bother me at all. Why not try to convince me you are right,
rather than becoming insulting/defensive/etc. If you read back through
your posts for 6 months, that's not at all uncommon to see repeated over
and over. The ICCA, the USA, university types, me personally, all have been
blasted.
:
: As an aside, I don't approve of Thorsten's lumping of Peter with
: Boris Becker, Adolf Hitler or whoever. I don't approve of his
: implying Peter was a fascist. Thorsten does a lot of work on my
: program, he's a great help, he's very intelligent and perceptive, he
: has many interesting things to say, but he has his own psycho-ideology,
: his own ideas. You've already accused me of saying stuff about
: germans, wasn't me, I explained it wasn't me, explained it
: wouldn't be me - do you retract? no chance. Can you be wrong? presumably
: not.
Probably my mistake, and I appologize for that. I intended the "german
bashing" as a reference for things that don't belong in any thread posted
here. It wasn't intended to be words I put into your mouth, just a comment
that this stuff gets *far* off the topic of the newsgroup. You have attacked
me personally, and the other topics I listed above. And it did *nothing* to
further your position. Logical, respectful, insightful comments will do a
lot more to convince someone, me at least.
:
: This thread started as a request to me from Bruce Moreland that I
: 'explain' my ideas. I tried to do this in a friendly spirit.
:
: That the thread degenerated so quickly into sarcasm, personal attack,
: rudeness, acrimony, probably says something about me, I'll admit,
: but certainly suggests there is something well wrong with this news
: group. Chess players need to guard against fighting zero-sum games
: off the chess board.
:
: A bit of admission of error, or apology for rudeness would be a start.
: But I've not noticed it yet, anywhere, anytime.
:
: I've better things to waste my time on.
:
: Chris Whittington
Done, however, to be fair, note that I did *not* start the rudeness. I simply
responded to it. If you think someone has an incorrect view of a problem,
point it out. Show them (us/me) where we're wrong. Expect counter-arguments
in response. If you don't want such a discourse, then, of course, don't post
anything at all. Posting brings you into the discussion, but from that point
on, you have to expect to defend your position. It's simply better to defend
it with facts and discussion, rather than sarcasm and personal/general attacks.
Chris Whittington
kerr...@frii.com (Tom Kerrigan) wrote:
>
> I don't have a mouse plugged in, so quoting is tricky. Sorry in advance.
>
> Chris, you are posting more and more
Only by request.
> about how neat-o searches are so amazing.
> You
> seem to be overlooking the fact that having a clever
> search is simply an
> *optimization*!
>
Really ? If a > b, because a is a cleverer version of b - this is
called an optimisation, eh ? Yes, its right ! Eureka ! I run naked
from my bath through the streets of Athens ......
.............................................. (continued page 94)
Note from editor: the above is called mild sarcasm, it is designed
to be slightly amusing, add a speck of life to what can be a dry, dull
field (computer chess), and not designed to hurt or seriously
offend you.
Mild sarcasm is used in counter to your ever-so-slightly rude
expression 'seem to be overlooking'. Not much more than 0.5 on a
scale of 1 to 10 rudeness factor, but personal nevertheless.
You could take the 'you seem to be overlooking the fact that' out, and
be left with 'Having a clever search is simply ....'. Briefer, neutral
I don't get provoked (unless that's what you want?), and less chance
of the thread degenerating.
Hyatt's 'post to alt.dickhead' and other assorted charmlessnesses
come higher on the scale. Not as bad as 'borrow a brain next time
you post', but unnecessary and leading to thread breakdown.
>
> Okay, so your program searches some lines to 50 ply.
No it doesn't.
> Good for it.
> Now, if I offer you a program that reaches 50 ply with a stupid, inane, slow,
> moronic, non-Kasparov-beating brute force (eew! sounds like a swear word, doesn't
> it?) searcher, which would you prefer? With all due respect to CST, I prefer the
> program that brute forces 50 ply.
Ok, fine, no problem. You go one way, I'll go the other.
In case you missed it, I said I wasn't going to continue arguing about it.
I've said what I think, I answered Brune Moreland's query.
No progress got made. There's just been a load of acrimony. Forcing me
to say what I think in print, helped clarify my own view to myself, so
dark cloud has silver lining.
Done.
>
> Also, with this university bullshit... I read the paragrah you quoted, written by
> Peter, and the only occurance of the word "university" that I can recall is in the
> name of the damn school.
Ah, clarity ! - I was misled by the expression 'NW University Project'.
Therefore assumed PG was using 'university + slate' as ad hominam
argument. So, the university bit was wrong - didn't realise a university
could be a high school.
My mistake. Thanks for making it clear.
So now I begin to see why Hyatt went thermo-nuclear.
> Why the hell are you jumping at this? I live in a city
> named "Fort Collins" but you don't see military-bashers annoying me.
Yup, analogy accepted. Fort doesn't mean Tom rides a panzer.
> I think
> Hyatt's reply is totally justified.
>
Yup, I concede I was operating with partial unsound conclusions.
But it does not excuse Hyatt's intemperate language and rudeness, not
for me anyway.
Shall we stop now ?
Chris Whittington
>
> Cheers,
> Tom
>
Robert Hyatt
Chris Whittington (chr...@cpsoft.demon.co.uk) wrote:
How about doing this: (and I know this is a sensitive issue for anyone
working on a commercial program)
Pick a topic in CST that you think is (a) unique and (b) not likely to be
used by other commercial programs. Let's discuss that in detail, you explaining
how you do whatever it is, and why you do it that way. I'll study what you
say and then figure out whether I think "crafty" (used here, not as a specific
program, but, rather, as an example of search-directed + evaluation computer
chess) either (a) accomplishes the same thing in a different way,
(b) accomplishes the same thing in the same way, or (c) why I think the idea
is either not so hot or else doesn't apply well to what I'm doing.
I don't have any secrets, hidden agenda, nor do I think I can write programs
better than anyone else. I do this for fun, and plan on continuing to do so
for a long time. One advantage that I have is that I've been doing this for
25 years now. That's given me plenty of opportunities to make mistakes, try
things that appear to be obvious but which don't work so well in practice. I
don't believe for a minute that being old (48) is an asset, but the experience
gained by reaching 48 is certainly worth a lot. Most likely, anyone can bring
a lot to the table for the computer-chess meal. Some ideas are good, some are
bad, some are bad now but might be good in the future. I claim to be open-
minded enough to look at *anything*... and wise enough to realize that when
given the choice of writing big or small codes, to accomplish the same thing,
that it's much more likely that the small code is going to produce better
results. This is the very reason why software engineering has sprung up.
Maybe one day, if enough people get interested in Crafty to figure out how it
works, and then they start modifying it, software engineering will breathe
new life into computer chess. It would be nice to have a standard "Quiesce()"
module that anyone can modify and if it works, share it with everyone else.
Ditto for Search() or EvaluatePassedPawns() or any other piece of code in
Crafty. The idea of code "reuse" makes large programs smaller over time since
much of the large code is reused over and over. Taking Evaluate() and adding
to it is not difficult. Writing the whole program from scratch is.
The only thing missing from what Crafty does, at present, which would make it
look more like what you do, is to use the evaluation to guide the search. This
is done to a very limited extent, like pushing passed pawns, double-extending
one-reply checks, etc. There's nothing to prevent someone from taking
NextMove() and not have it regurgitate every legal move at each ply, rather
it could selectively choose from the full set of moves, based on some sort of
evaluation, long-range-planner, or whatever. The benefit is that the search
component of Crafty is getting reasonably fast, and still has a long way to go
before the maximum speed is reached. The bitmaps make coding evaluation
knowledge less of a speed concern, and more of a "how do I want to do this"
concern. In Cray Blitz we were always weighing evaluation terms vs speed cost.
The bitmaps have greatly reduced this to the point that there's been nothing
I've wanted to do that I couldn't efficiently do without regard to execution
cost. That says there's still a long way to go before the improvement curve
begins to flatten out.
The only thing I can promise is that if I don't agree with an idea you propose,
I'll try to give concrete reasons why, and, if possible even provide real test
data to support my position (check out the famous SEE vs MVV/LVA thread from
last year for an example). I won't write your ideas off "just because they
are from some kook overseas, or just because they are from a non-university
type, or ..." If we get past that, the discussion might be interesting...
Peter W. Gillgasch
Chris Whittington <chr...@cpsoft.demon.co.uk> wrote:
> Ah, clarity ! - I was misled by the expression 'NW University Project'.
> Therefore assumed PG was using 'university + slate' as ad hominam
> argument. So, the university bit was wrong - didn't realise a university
> could be a high school.
>
> My mistake. Thanks for making it clear.
>
> So now I begin to see why Hyatt went thermo-nuclear.
Chris Whittington <chr...@cpsoft.demon.co.uk> wrote:
> This says *nothing* about 'university' or 'Slate'. It was a sarcastic
> comment targeted at PG's use of 'universtity + slate' to support
> his view (that Shannon B was done and failed), and, by implication,
> to attack mine.
Chris Whittington <chr...@cpsoft.demon.co.uk> wrote:
> The point was relating to the *packaging* of knowledge. You are not so
> young as to have not come across this phenomenon. If the knowledge comes
> in the 'right', packaging it gets accepted, otherwise it's deeply
> suspected. I was alleging that Peter's acceptable packaging is
> university/bright guy, and he assumes I don't fit his requirement.
Chris Whittington <chr...@cpsoft.demon.co.uk> wrote:
> As an aside, I don't approve of Thorsten's lumping of Peter with
> Boris Becker, Adolf Hitler or whoever. I don't approve of his
> implying Peter was a fascist. Thorsten does a lot of work on my
> program, he's a great help, he's very intelligent and perceptive, he
> has many interesting things to say, but he has his own psycho-ideology,
> his own ideas.
Chris Whittington <chr...@cpsoft.demon.co.uk> wrote:
> No way am I living in the same decade, continent, world as Gillgasch.
Chris Whittington <chr...@cpsoft.demon.co.uk> wrote:
> A bit of admission of error, or apology for rudeness would be a start.
> But I've not noticed it yet, anywhere, anytime.
1. It is irrelevant whether NU is a high school or an university.
If you think that this makes any difference then this just proves
that you did not understand anything what Hyatt told you.
2. As I already pointed out your accusation that I believe only in
knowledge that comes from universities is wrong.
I simply stated when and by whom the typical Shannon A program design
was "invented" and which program was the first that was designed that
way for the sole purpose of illustrating the historical background.
I even stated that purpose at the beginning of the post so it is for
any person that can read and think without getting emotionally
involved (that is a person who is able to participate in a scientific
discussion on usenet) obvious that this was no instrument to make a
claim of any sort.
But you love that accusation too much to drop it.
3. Obviously for some reason you need someone to bash on just to feed
your ego.
4. You want apologies for close to anything. I never saw one of yours.
Instead you defend your peers even if they are *really* screwing up
in a totally unacceptable manner.
I am sure that if I say now "welcome to my kill file" that this amuses
you and tells you that you are a pretty cool person that is always right
especially since you have the honour to be the first (and hopefully the
last) person to have that pleasure.
I am happy to make your day.
Best regards
-- Peter W. Gillgasch
mcl...@prima.ruhr.de
In article <4r21bb$8...@news.xs4all.nl>X-XS4ALL-Date: Sat, 29 Jun 1996 03:3, Ed
Schroder <rebc...@xs4all.nl> writes:
>: gil...@ilk.com (Peter W. Gillgasch) wrote:
>>Chris Whittington <chr...@cpsoft.demon.co.uk> wrote:
>
>[ snip ]
>
>> Briefly:
>> The evaluation function is responsible for making pruning, extension
>> and candidate move decisions.
>
>:Sounds like the typical 60ties design.
>
>REBEL (in general) does the same as CST.
>
>There is no need to do a nullmove since all info comes from the
>evaluation function and doing a nullmove would be a waste of time
>for Rebel.
>
>Old fashioned?
>Maybe, but I am pretty satisfied with the system even after 16 years.
>
>
It seems that I was right to put Ed's Rebel in one group
with Hiarcs4, Mchess5 and Chris CSTal.
>[ snip ]
>
>
>> Also, I came to realise that with a much heavier eval knowledge
>> component, it was possible to become highly speculative in the
>> evaluation function. CST, internally, 'wins' material before it is
>> realistically won, 'mates' its opponent before it is realistically
>> mating.
>
>:This is certainly doable but as you noted (see next paragraph) this is a
>:dangerous concept if the implementation is not 100% right in all cases.
>:It is that point that makes me think that your concept is basically
>:doomed.
>
>In the past I have experimented in this area too, resulting in fantastic
>attack games but also hopeless losses. Finally I have chosen for the
>balance, meaning for example that if Rebel sacrifices a pawn it should
>a correct sacrifice in at least 95% of the cases.
>
>Speculative play: Dangerous? Yes , Doomed? No
>
Normally Rebel7 has very low evaluations in relation to Hiarcs and Mchess5.
I understand why Mchess5 has these high evaluations, also Marks Hiarcs4,
but I never understood the evaluation-function of Rebel7.
This is the reason why I though Ed is doing it a little different by
doing very clever forward pruning. Rebels tree seems to be really
filled only with the minimum trials.
Maybe Ed learned building clever small but efficient tress while
he worked with the 8-Bit 6502-4 Mhz 32Kilo-byte ROM Machines, 8 Kilo-byte RAM!
Although these old dedicated machines named Rebel5 or MM5 had very
small CPU-power and MEMORY-resources, rebel5 was a very intelligent
chess-computer.
Of course I know Frans can program my washing-machine to play chess,
but on a 6502 Ed has done more chess-knowledge into it, and
it was the strong surprise 1986 in cologne.
>
>[ snip ]
>
>
>:No evaluation function is worth 2000 ELO. A combination of search and
>:knowledge should be worth at least 2000 ELO (otherwise the programmer is
>:in the wrong business).
>
>I agree.
>I think Chris meant that if you put the program on LEVEL PLY=1 the
>program will play on a rating of 2000. This would prove that the programs
>evaluation function is 2000 ELO points.
>I don't know such a program and I doubt if such a program exists (1 ply,
>no extensions, only Q-search)
>
>
>[ snip ]
>
>
>:To be frank I am a bit surprised by your post since there is nothing new
>:in this idea. It looks to me that you are still simply living in the
>:60ties and you are still fighting with the problems the chess
>:programmers had in the 60ties. I have a hard time to understand why you
>:don't move on to the 70ties but this is your life.
>
>Disagree.
>Sure, the basic ideas are old fashioned, but through the years the
>ideas are improved and fine tuned. Others stopped looking for new ways,
>I am in favor for the old approach and I am (mostly!) happy with it.
>
>- Ed Schroder -
>
>
That is exactly true. And THESE OTHERS STOPPED LOOKING FOR NEW WAYS
because Mr.Friedel and other convincing guys ALWAYS said:
NONONO - the 60ties efforts a doomed!
That is what I criticize. These people have no right to publish and
talk and influencing the public by saying:
alternative ideas of intelligent 0-ply chess-programs are senseless,
time-wasting and will never success.
And if they would have the right, I don't think that their published
articles that should brainwash the readers and suggest that
knowledged-based ideas are dead, are not helping computerchess in making
qualitative progress.
I have spoken to many guys who tried the knowledged-based ideas.
They all made bad experience with the so called REALISTS and
publishers that made jokes about them.
E.G. Thomas Nitsche, the Mephisto3 programmer never failed with his ideas,
but the SYSTEM stopped him.
Have you ever seen a chess-computer like the Mephisto 3 that computes
2 nodes per second on a slow 1806-8 Mhz ??
It computed arround 10 seconds on a Motorola 68000.
I think it was an amazing effort. It made move decisions after having proofed
18 nodes, and was able to play good chess (of course a child of its time).
But the brute-force-lobby was faster and more succesful. But I guess
the idea of Nitsche would have been more succesful, if he would have
continued in our times.
That is what makes me angry. And for heavens sake that Marty Hirsch
is not giving up programming chess, although everybody it attacking him,
although his program is the strongest in the swedish-rating-list.
The fast-success-lobby is interested (not the amateurs or university guys)
in making fast-money. I guess Ed and Marty and many others have other ideals.
But it is very difficult to survive against people that brainwash
the customers by writing big articles about Deep Blue and NOT writing
about german-programs, although we have many good efforts.
This is nonsense.
mcl...@prima.ruhr.de
In article <83613585...@cpsoft.demon.co.uk>, Chris Whittington
<chr...@cpsoft.demon.co.uk> writes:
>> : > research universities. Not all, but certainly *most*. And it has
nothing to
>> : > do with this discussion. Good ideas are good, bad ideas are bad,
regardless
>> : > of the source. So let's drop the university bashing, US bashing,
Germany
>> : > bashing, etc... and keep the discussion on computer chess. The name of
the
>> : > newsgroup has something to do with the latter, but not the former.
>> : >
>> :
>> : You are way out of line.
>> : There is no bashing of Slate or universities. Read again.
>> :
>> : The point was relating to the *packaging* of knowledge. You are not
>> : so young as to have not come across this phenomenon.
>> : If the knowledge comes in the 'right', packaging it gets accepted,
>> : otherwise it's deeply suspected.
>> : I was alleging that Peter's acceptable packaging is
>> : university/bright guy, and he assumes I don't fit his
>> : requirement.
>> :
>> : Where's the Slate/university bashing ? Hmmm ?
>>
>>
>> Right *here*: A direct quote from you, which *immediately followed
>> peter's comment about slate/atkin and 4.x. If that doesn't apply to
>> them, just who does it apply to?
>>
>> Here's what peter said:
>>
>> : > peter gillgasch wrote:
>> : > : > As I mentioned in an earlier post those problems lead two bright
guys
>> : > : > (Slate & Atkin from the Northwestern University Chess Program) to
the
>>
>> Here's the words right out of your mouth:
>>
>> : > : From the *university*, oohh, well they *must* be right then, innit ?
>>
>>
>> : Pause next time please, before using such intemperate language.
>>
>> Why don't you pay attention to (a) what you are responding to (b) whether
>> the response is adding anything to the thread and (c) follow the simple rule
>> of if you have nothing to contribute, then *contribute nothing.*
>>
>
>This says *nothing* about 'university' or 'Slate'. It was a sarcastic
>comment targeted at PG's use of 'universtity + slate' to support
>his view (that Shannon B was done and failed), and, by implication,
>to attack mine.
>
>If I claim my view is supported by Winston Churchill, it doesn't make my
>view any better. My view has to stand or fall on its own merits.
>If you say 'oh, well if WC supports it, it must be alright then', I'ld
>take that as a sarcastic comment about my attempt to use WC to
>democratise my view, to bring in external support that can't
>by definition be criticised or questioned - rather than an attack on
>the merits or otherwise of WC.
>
>My name's Chris, your name's Bob, I know what I meant, I told you
>what I meant - but you know better, so out you come with some
>more bluster to justify your original intemperate (rude) comments.
>
>Mild sarcasm I can cope with, outright rudeness (hard-on for
>university types, alt-dickheads), from you or anybody else, directed
>at me or anybody else, I object to.
>
>As an aside, I don't approve of Thorsten's lumping of Peter with
>Boris Becker, Adolf Hitler or whoever. I don't approve of his
>implying Peter was a fascist. Thorsten does a lot of work on my
>program, he's a great help, he's very intelligent and perceptive, he
>has many interesting things to say, but he has his own psycho-ideology,
>his own ideas. You've already accused me of saying stuff about
>germans, wasn't me, I explained it wasn't me, explained it
>wouldn't be me - do you retract? no chance. Can you be wrong? presumably
>not.
>
NONONONO! I have not said that Peter is a fascist!
I have made a list of persons that seem to be
mothersons or "realists" or "materialists" or what I call "catholics"
or scientists!
If Peter though or anybody else that I called him a fascist, I excuse.
What I mean is that e.g. Ron Hubbard, Bill Gates, Frederic Friedel,
or the catholic pope and Hitler have some behaviour that is very close
to the other persons in the list.
All these persons are mothersons, that means they have a problem with
self-consciousness and need to over-compensate by
a) having control over people
b) having money or power
c) call themselves REALISTS or godlike or almighty.
I put Peter in this list not to say he is fascist but to say
HE BELIEVES IN HIS REALITY like the pope believes he is a god and not
a human polish person that PLAYS a god.
Please believe me: I never intend to say Peter is a fascist.
Of course Chris has nothing against germans, as he mentioned.
I am a german and I don't like germans due to my experience
in the german army, and due to the experience when people in
my home town burned a house full of ASYLANTEN (don't know the
english term!) . But it was in time where every weekend
all over germany they (neo-fascists) made their PLAY with
burning houses of foreign-workers and other other attacks.
I am not a fascists nor an antisemit.
It is just that I have problems to accept the german-history
and germany growing to be again the same country, than it was
in the past.
One more point:
I I am saying that I like frans morsch, I mean it.
I have no problems saying that somebody is a shit! (as you have seen).
I would say and name the person if I think this way about him.
That you think I would apologize to throw mud shows more about
your point-of-view, not mine.
I do not excuse in forward, before starting to throw with garbage or
rude words.
I met Peter in Paderborn, and I found he is ok. I am not attacking
him. Just criticizing his ideas.
I have nothing against him in personel. How could I. I don't know him.
But if he says A and I am the opinion B and B is NOT A than I have to
tell him.
My language is more analog meanwhile his language is more digital,
ok, I am always speaking in images and methaphors.
Maybe Peter thinks with his logical left-brain-side and I think
with my right-brain-side.
His language is a matter-of-fact (objective),
my language is figuratively or pictorial.
Also Peter is taking computer-chess more seriously, for me it is just
a hobby.
If you think I am MAD, ok. I have no problems with that.
>This thread started as a request to me from Bruce Moreland that I
>'explain' my ideas. I tried to do this in a friendly spirit.
>
>That the thread degenerated so quickly into sarcasm, personal attack,
>rudeness, acrimony, probably says something about me, I'll admit,
>but certainly suggests there is something well wrong with this news
>group. Chess players need to guard against fighting zero-sum games
>off the chess board.
>
>A bit of admission of error, or apology for rudeness would be a start.
>But I've not noticed it yet, anywhere, anytime.
>
Chris Whittington
> > Therefore assumed PG was using 'university + slate' as ad hominam
> > argument. So, the university bit was wrong - didn't realise a university
> > could be a high school.
> >
> > My mistake. Thanks for making it clear.
> >
> > So now I begin to see why Hyatt went thermo-nuclear.
>
> Chris Whittington <chr...@cpsoft.demon.co.uk> wrote:
>
> > comment targeted at PG's use of 'universtity + slate' to support
> > his view (that Shannon B was done and failed), and, by implication,
> > to attack mine.
>
>
> > The point was relating to the *packaging* of knowledge. You are not so
> > young as to have not come across this phenomenon. If the knowledge comes
> > in the 'right', packaging it gets accepted, otherwise it's deeply
> > suspected. I was alleging that Peter's acceptable packaging is
> > university/bright guy, and he assumes I don't fit his requirement.
>
>
> > As an aside, I don't approve of Thorsten's lumping of Peter with
> > Boris Becker, Adolf Hitler or whoever. I don't approve of his
> > implying Peter was a fascist. Thorsten does a lot of work on my
> > program, he's a great help, he's very intelligent and perceptive, he
> > has many interesting things to say, but he has his own psycho-ideology,
> > his own ideas.
>
>
> > No way am I living in the same decade, continent, world as Gillgasch.
>
> Chris Whittington <chr...@cpsoft.demon.co.uk> wrote:
>
> > But I've not noticed it yet, anywhere, anytime.
>
"Methinks the lady doth protest too much" (Shakespeare, by the way)
So long, Peter !
Chris Whittington
Chris Whittington
hy...@crafty.cis.uab.edu (Robert Hyatt) wrote:
>
> How about doing this: (and I know this is a sensitive issue for anyone
> working on a commercial program)
>
> Pick a topic in CST that you think is (a) unique and (b) not likely to be
> used by other commercial programs. Let's discuss that in detail, you explaining
> how you do whatever it is, and why you do it that way. I'll study what you
> say and then figure out whether I think "crafty" (used here, not as a specific
> program, but, rather, as an example of search-directed + evaluation computer
> chess) either (a) accomplishes the same thing in a different way,
> (b) accomplishes the same thing in the same way, or (c) why I think the idea
> is either not so hot or else doesn't apply well to what I'm doing.
>
> I don't have any secrets, hidden agenda,
You are human aren't you ?
You have no hidden agenda ?
Not possible. [ insert mild sarcasm smiley here ]
Limey kook, please.
> or just because they are from a non-university
> type, or ..." If we get past that, the discussion might be interesting...
>
>
Two responses:
1. I am not so arrogant to assume that r.g.c.c can't go on without me.
But I am arrogant enough to know that it will the poorer without my
contribution.
I've not yet decided what my position vis-a-vis participating,
sniping from the sidelines, or saying bye-bye, yet is. It depends
on other issues:
a) progress on manners of discussion.
b) respect for un-orthodox views.
c) recognition that computer chess is not exclusively about
the mechanics of programs, but has a wider political and
philosophical theme.
2. I think that I've already given views on my style of program and
the thoughts behind it; in the earlier acrimonious thread.
I also think that the ideas were ignored/not answered. There may
be several reasons for this; but, if I am to be charitable, I can
perhaps assume that they were just not explained properly.
Perhaps the way forward, if there is to be one, would be for you,
or somebody, to attempt to summarise/precis the ideas contained.
Then I can get a handle on what is understood.
Chris Whittington
Bill Newton
>"Methinks the lady doth protest too much" (Shakespeare, by the way)
>So long, Peter !
>Chris Whittington
Was it really necessary for you to repost all that correspondence
between yourself and Peter Gillgasch, simply to make what I imagine you
believe is a pithy comment?
May I,with the utmost respect of course ;-) suggest that in future you
use a little common sense, and edit reposts appropriately,you'll be
surprised how much the silent majority of this newsgroup will applaud
such a simple action.
Although to be fair.......you are not alone, so (to all) if the cap
fits............:-)
--
Bill Newton
Chris Whittington
Thanks for conceding its 'possibly' true.
And, I repeat it was not an attack on universities (as I've said, I've
been through 2 degrees and a higher qualification - not the usual
behaviour of an anti-university type, whatever that is.
So it wasn't a slur. It was mild sarcasm against Gillgasch. I concede
that 'mild' is open to interpration. It was meant mildly, but I guess
it may not be so taken.
> :
> : If I claim my view is supported by Winston Churchill, it doesn't make my
> : view any better. My view has to stand or fall on its own merits.
>
> But if you are a physicist, and claim your view is supported by a Nobel
> prize-winner in physics, it does lend credibility to your position. If you
> then claim that the Nobel winner doesn't necessarily know what he's doing,
> you should expect a firestorm. *unless* you offer a lot of proof.
>
This is fair enough, until you remember they give Nobel prizes to
Ronald Reagan, Anwar Saddat, Begin et al.
Nobel stuff is as political as anything else.
Rule 3. Listen to the idea, not the qualifications of who is saying it.
> : If you say 'oh, well if WC supports it, it must be alright then', I'ld
> : take that as a sarcastic comment about my attempt to use WC to
> : democratise my view, to bring in external support that can't
> : by definition be criticised or questioned - rather than an attack on
> : the merits or otherwise of WC.
> :
> : My name's Chris, your name's Bob, I know what I meant, I told you
> : what I meant - but you know better, so out you come with some
> : more bluster to justify your original intemperate (rude) comments.
> :
> : Mild sarcasm I can cope with, outright rudeness (hard-on for
> : university types, alt-dickheads), from you or anybody else, directed
> : at me or anybody else, I object to.
>
> Me too. Why not confine the conversation to the topics you are interested
> in any drop the insulting tone? If you don't agree with my point of view,
> that doesn't bother me at all. Why not try to convince me you are right,
> rather than becoming insulting/defensive/etc. If you read back through
> your posts for 6 months, that's not at all uncommon to see repeated over
> and over. The ICCA, the USA, university types, me personally, all have been
> blasted.
ICCA yes, I admit it. Not happy with them at all. But that's another story.
USA. Have travelled extensively there, have several American friends, know
its a big place with multi-faceted features. Not too happy with
penetration of European culture (particularly English culture) by
mass-media, Hollywood culture, or the "bigger, faster, more" ideas
that tend to emerge, but like the place and the people apart
from that. Its a fine Grand Canyon, we have nothing like it.
University types - already spoken on that front. Obviously there
tends to be a clash between commerce and research. The one feels it
in the real world and the other feels its on a higher plane; but its
no great problem.
You personally. I like to think I've attacked your *ideas* only.
If, ever, I've made a personal attack on you, then I would apologise.
I may have been provocative, or employed my usual sarcasm, but, rude,
I hope not.
But you were directly rude. Initiated. Without provocation.
>
> :
> : As an aside, I don't approve of Thorsten's lumping of Peter with
> : Boris Becker, Adolf Hitler or whoever. I don't approve of his
> : implying Peter was a fascist. Thorsten does a lot of work on my
> : program, he's a great help, he's very intelligent and perceptive, he
> : has many interesting things to say, but he has his own psycho-ideology,
> : his own ideas. You've already accused me of saying stuff about
> : germans, wasn't me, I explained it wasn't me, explained it
> : wouldn't be me - do you retract? no chance. Can you be wrong? presumably
> : not.
>
> Probably my mistake, and I appologize for that. I intended the "german
> bashing" as a reference for things that don't belong in any thread posted
> here. It wasn't intended to be words I put into your mouth, just a comment
> that this stuff gets *far* off the topic of the newsgroup. You have attacked
> me personally,
Your ideas only, I hope.
> and the other topics I listed above. And it did *nothing* to
> further your position. Logical, respectful, insightful comments will do a
> lot more to convince someone, me at least.
Thank you for the retraction. It would be slightly more welcome if
not immediately followed through with a *but* and an insinuation
that my comments are not logical, nor respectful, nor insightful - but
I suppose I should be grateful for small mercies; whoops, there goes
the sarcasm again :).
>
> :
> : This thread started as a request to me from Bruce Moreland that I
> : 'explain' my ideas. I tried to do this in a friendly spirit.
> :
> : That the thread degenerated so quickly into sarcasm, personal attack,
> : rudeness, acrimony, probably says something about me, I'll admit,
> : but certainly suggests there is something well wrong with this news
> : group. Chess players need to guard against fighting zero-sum games
> : off the chess board.
> :
> : A bit of admission of error, or apology for rudeness would be a start.
> : But I've not noticed it yet, anywhere, anytime.
> :
> : I've better things to waste my time on.
> :
> : Chris Whittington
>
> Done, however, to be fair, note that I did *not* start the rudeness. I simply
> responded to it.
Well, now I'm very sorry to have to say this; but *you_did_start* it.
1. Moreland asked me to provide some details.
2. I did.
3. Gillgasch made his historical contribution.
4. I responded, to him, with some sarcasm, fairly mild - reason:
I felt he was attacking, under a mask of trying to be scientific.
And with some straightforward normal stuff.
5. You came out with:
post to alt.dickheads
parents ashamed of you
hard-on for university types
You know that I felt this was way beyond normal limits, and
unprovoked, and I don't accept past impressions that (erroneously
in my view) you may have built up as an excuse.
I concede that I am provocative and somewhat sarcastic. Apologies
offered if ever it goes too far.
> If you think someone has an incorrect view of a problem,
> point it out. Show them (us/me) where we're wrong. Expect counter-arguments
> in response. If you don't want such a discourse, then, of course, don't post
> anything at all. Posting brings you into the discussion, but from that point
> on, you have to expect to defend your position. It's simply better to defend
> it with facts and discussion, rather than sarcasm and personal/general attacks.
>
Or, with serious levels of personal abuse and rudeness .....
Your turn. Or you can pass.
Chris Whittington
Tom Kerrigan
>That is exactly true. And THESE OTHERS STOPPED LOOKING FOR NEW WAYS
>because Mr.Friedel and other convincing guys ALWAYS said:
>NONONO - the 60ties efforts a doomed!
>That is what I criticize. These people have no right to publish and
>talk and influencing the public by saying:
>alternative ideas of intelligent 0-ply chess-programs are senseless,
>time-wasting and will never success.
Blah blah blah. Get off it, already. Looks like the concept of free speech is
alien to you. Besides, I'm sure these brute-forcers really say, "To hell with
knowledge! We're going to make everybody write stupid programs now! Woo-hoo!"
Cheers,
Tom
_______________________________________________________________________________
Tom Kerrigan kerr...@frii.com O-
Dessert is probably the most important stage of the meal, since it will
be the last thing your guests remember before they pass out all over
the table.
-- The Anarchist Cookbook
Philippe Schnoebelen
Chris Whittington <chr...@cpsoft.demon.co.uk> writes:
> Believe me, I have no problems with 'university types' (I've been through
> the system three times to date)
Poor you... I sincerely hope the fourth try will succeed.
Disclaimer: I am an University type :-)
--Philippe
Chris Whittington
Thanks. Sorry to disappoint but I was successful each time.
Chris Whittington
Bruce Moreland
In article <83597114...@cpsoft.demon.co.uk>, chr...@cpsoft.demon.co.uk
says...
>Briefly:
>The evaluation function is responsible for making pruning, extension
>and candidate move decisions.
>
>Since the program runs at only 1800 n/s on a P90, the forward pruning
>decisions are very important, and, if CST gets it wrong, it will
>be crushed. So the eval looks for *everything* I can think of.
>Every single tactical theme possible is covered (almost).
>
>Of course, it is not possible to be totally accurate in these
>calculations, sometimes there are too many pins and other complexities,
>but CST tries.
>[snip]
>It seemed to me, and despite the many claims that knowledge had been
>tried and failed, that it must be possible to program an evaluation
>function to understand at the level of the patzer above.
>The patzer knowledge could be used to guide and prune the search, and
>the search (shallower than with faster programs) could be relyed on
>to pick up stuff missed by the evaluation patzer.
>
>Also, I came to realise that with a much heavier eval knowledge
>component, it was possible to become highly speculative in the
>evaluation function. CST, internally, 'wins' material before it is
>realistically won, 'mates' its opponent before it is realistically
>mating. Often it gets it wrong, often it gets it right - but the result
>is a fantastically exciting and dynamic style of play. Just about everyday
>I get a thrill/heart attack from some manic game on the autoplayers,
>where CST seems to be playing madness, pieces hanging everywhere, mating
>attacks for both sides. CST says +10.00 pawns, opponent says +2.00
>pawns - it takes maybe 10 half moves for the situation to resolve.
>[snip]
>So, I'm not claiming that I do anything special. Simply that no-one
>else has stuck long enough at this approach to make it work.
>
>And, lastly, programs are pretty good now, we have much program space
>in PC's (it not like there's only 64K for code anymore). PC's are fast
>so we get away with doing much code executions. Programs don't need
>to be bare materialists - there's much scope for giving them particular
>play styles. CST is designed (has emerged) to play in the style of Tal,
>and it does.
I'm kind of confused as to how we got from this to people putting people in
kill-files, but it has happened. There have been so many 300-line responses
in this thread that I had back-burnered it until now. I spent some time
trying to figure out how we got from this point to where we are now. I think
that at least some of it involves personality issues brought in from other
threads, which have disappeared from my newsreader.
The combatants are all people who can take care of themselves, and they are
generating too much text to actually read, so I'm not going to try to figure
it out today.
Back to the topic.
My own program doesn't work like this. I can abandon my own design, and
adopt Chris' design, or I can tell him that his design can't ever work. I'm
not terribly confident in my own design, but it seems to be at least
credible, so I don't see any reason to abandon it. To tell Chris that his
design is bad would be premature (uniformed), counterproductive, and quite
possibly wrong. CST beat Genius under tournament conditions (any suggestion
that this was a bogus version of Genius or that Genius was hurt by having to
run on a P5/133 as opposed to a P5/120 is baloney), so it obviously works, it
is just a matter of how often, and even if it doesn't work as often as a
fast/dumb program works, perhaps it does not matter, because it might be what
people want anyway.
So, to repeat myself, I'm very interested in this program. It is a challenge
to how most of us are doing things, and there might be germs in it of how the
commercial guys are doing things.
Assuming that the speculative stuff is off, if you take what CST would
consider a leaf node, and take the same node as expanded by my program (mine
is dumb and fast, so in most cases I had better be getting some plies under
the node, if I don't I might as well make my eval smarter), I wonder what the
difference in evaluation accuracy of that node is.
Likewise I wonder what the effect of the eval function is on search
direction, perhaps CST is out-searching fast/dumb programs on positions that
matter.
I wonder what affect better hardware would have on CST, meaning that if we
put his program and a "fast" program in a vault for five years, then take
them out and run them on whatever hot processor is out there then, which will
have gained the most.
The speculative stuff is interesting, but if what I am trying to do is
increase winning percentage against the broad base of players, I would be
concerned that some percentage of busted attacks would translate directly
into easy losses versus low rated players. These players are winning very
few now, so even if only 5% of games were tanked like this, that would be a
dramatic increase in losses against these folks, which would result in an
accurately reduced rating -- the program would be weaker.
My program is doing alright with humans on ICC, but it does not often attack,
and it sometimes gets rolled pretty badly itself. I'm hoping that at the
very least I'll get some ideas out of this discussion about how to improve
both of these points.
A lot of this is randomness until we get better access to CST, however.
bruce
--
The opinions expressed in this message are my own personal views
and do not reflect the official views of Microsoft Corporation.
Dr A. N. Walker
Chris Whittington wrote:
[...]
> The Tal approach says "steer the game towards
> chaotic situations, and then 15-20 plies of search will be enough,
> for much of the time". The human defence to this will be to stay clear
At the recent ACC8 conference, GM Bronstein played a demo match,
two games at game in 25 minutes, against M Chess Pro 5.0. In the first
game, as black, he played reasonably quietly, built up a positional plus,
nearly blew it to a tactical cheapo, and drew. In the second, as white,
he sacced a pawn and smashed MCP tactically. [I expect the games will
eventually be published.] He gave a talk afterwards which ran, roughly:
"How to beat computer? Experts say to play quietly. Is not right. Well,
is *maybe* true, but is *boring*. Way to beat computer is to lose pawn.
Then computer happy, but not know what to do. I happy because to lose
pawn is advantage. Yes, when pawn down, is advantage because I play
better -- is clear what I must do, I can make plan. Computer cannot make
plan. Players always worry when pawn down -- how to get pawn back. No,
GMs not worry abour pawns. Pawn down not matter, is advantage." [Add
accent and wide smile to taste.]
He proved it, too.
--
Andy Walker, Maths Dept., Nott'm Univ., UK.
a...@maths.nott.ac.uk
Chris Whittington
"Dr A. N. Walker" <a...@maths.nott.ac.uk> wrote:
>
> Chris Whittington wrote:
> [...]
> > The Tal approach says "steer the game towards
> > chaotic situations, and then 15-20 plies of search will be enough,
> > for much of the time". The human defence to this will be to stay clear
>
> At the recent ACC8 conference, GM Bronstein played a demo match,
> two games at game in 25 minutes, against M Chess Pro 5.0. In the first
> game, as black, he played reasonably quietly, built up a positional plus,
> nearly blew it to a tactical cheapo, and drew. In the second, as white,
> he sacced a pawn and smashed MCP tactically. [I expect the games will
> eventually be published.] He gave a talk afterwards which ran, roughly:
>
> "How to beat computer? Experts say to play quietly. Is not right. Well,
> is *maybe* true, but is *boring*. Way to beat computer is to lose pawn.
> Then computer happy, but not know what to do. I happy because to lose
> pawn is advantage. Yes, when pawn down, is advantage because I play
> better -- is clear what I must do, I can make plan. Computer cannot make
> plan. Players always worry when pawn down -- how to get pawn back. No,
> GMs not worry abour pawns. Pawn down not matter, is advantage." [Add
> accent and wide smile to taste.]
>
> He proved it, too.
>
> --
> Andy Walker, Maths Dept., Nott'm Univ., UK.
> a...@maths.nott.ac.uk
I agree again.
Mchess Pro is in double trouble in such a situation.
MCP has a speculative algorithm, it's inclined to award itself
overhigh bonuses for positional, or good tactical features (a good
thing to do in my view).
Result: MCP tends to be a little sacrificial.
But, why be sacrificial when you are already winning, that might
just be the way to lose.
So MCP has another algorithm. When MCP is material ahead, often
just one pawn ahead, he awards himself a big 'winning bonus', it
looks to be around two pawns. So when he is really +1.00, he
says +3.00. To be double sure, MCP, I think, tests that the
opponent doesn't have anything strong happening, like advanced
passed pawns, then the winning bonus is reduced
This tends to prevent him from making saccy, speculative moves when he's
already winning.
But MCP is not expert at detecting king attacks. So, sac a pawn, attack
his king, and he thinks he is +3.00. This makes MCP extra-extra
materialistic after you sac against him - just the attitude *not* to
have when facing a saccy king attack.
BTW Mchess is a Shannon B program. One of those programs everybody
has given up writing and never can win World Championships nor
rise to the top of rating lists. Just like Hiarcs, Rebel and CSTal :)
All goes to show that writing speculative programs is not easy.
And writing Shannon B programs is not easy either.
Marty can flame me if he thinks my analysis is rubbish ....
Chris Whittington
Jan Eric Larsson
Chris Whittington writes:
>From the *university*, oohh, well they *must* be right then, innit ?
and then:
>Mild sarcasm I can cope with, outright rudeness (hard-on for
>university types, alt-dickheads), from you or anybody else, directed
>at me or anybody else, I object to.
Hm... What if you did not post things like the first statement above
to the entire world? Maybe you wouldn't get things back? Just a thought...
>A bit of admission of error, or apology for rudeness would be a start.
>But I've not noticed it yet, anywhere, anytime.
More food for thought here, methinks...
Jan Eric Larsson
Knowledge Systems Laboratory, Stanford University, Room 248, M/C 9020
Gates Computer Science Building 2A, Stanford, CA 94305, USA
Phone: +1 415 725 3859, Fax: +1 415 725 5850, E-mail: Lar...@KSL.Stanford.Edu
Web: http://www-ksl.stanford.edu/people/larsson/