MCP6 Endgame Tablebase. Thanks mr.Hirsch!
H.Pieters
Thanks for MCP6 and endgame tablebase.
However I like to play with other chess programs too, I specially
thank mr. Marty Hirsch for his work to produce MChess Pro 6.0.
MCP6 makes full automatic use of the endgame tablebases which I
downloaded from internet: ftp://caissa.onenet.net/pub/chess/TB
The MCP6 manual gives complete instruction how to do this.
As a result MCP6 plays its endgames as perfect and quick as
usually only in the opening. Just put the downloaded and extracted
endgame tablebases in the directory TB in MCP6's main directory.
The program recognise and responds immediately any endgame position
if set in the menu-option (F5).
I hope Rebel 9 will also offer this feature. Well done mr.Hirsch!
Hans Pieters.
H.Pieters
Thanks for MCP6 and endgame tablebase.
However I like to play with other chess programs too, I specially
thank mr. Marty Hirsch for his work to produce MChess Pro 6.0.
and uploader of these most useful endgame tablebases on internet.
MCP6 makes full automatic use of the endgame tablebases which I
downloaded from internet: ftp://caissa.onenet.net/pub/chess/TB
The MCP6 manual gives complete instruction how to do this.
As a result MCP6 plays its endgames as perfect and quick as
usually only in the opening. Just put the downloaded and extracted
endgame tablebases in the directory TB in MCP6's main directory.
The program recognise and responds immediately any endgame position
if set in the menu-option (F5).
I hope Rebel 9 will also offer this feature.
lmk
I read that if you take out the 2 duplicate games ( which totaled 5
out of the 20 played resulted in Rebel 8 winning 18-17 over MChess 6.0.
If you include the duplicates MC6 wins 22-18.
George Dixon
I also downloaded and installed some of the endgame tablebases into MCP6
and then tried it out with KQ v KR and was completely intimidated when
the program immediately announced MATE IN 34 MOVES !!
It's too bad the more complex endings tablebases are so damn large as to
make acquisition of them physically impossible for all but the largest
hard drives.
George
H.Pieters <hpi...@nijmegen.inter.nl.net> wrote:
:
: Thanks for MCP6 and endgame tablebase.
:
:
Kai Lübke
George Dixon <de...@interactive.net> wrote:
>I also downloaded and installed some of the endgame tablebases into MCP6
>and then tried it out with KQ v KR and was completely intimidated when
>the program immediately announced MATE IN 34 MOVES !!
But you will also find it silly how MCP6 is going to behave in, say, a
KQPPK endgame: it will find that if it sacrifices the queen, the KPPK
tablebase says "Mate in 26" or so, and consequently MChess will
sacrifice the queen. Funny, but inevitable with endgame tablebases - I
laughed at it many times with Crafty...
Shep
Enrique Irazoqui
lmk <l...@mindspring.com> wrote in article <3289C6...@mindspring.com>...
> I read that if you take out the 2 duplicate games ( which totaled 5
> out of the 20 played resulted in Rebel 8 winning 18-17 over MChess 6.0.
> If you include the duplicates MC6 wins 22-18.
Not really. There are 40 games in total. If you take out duplicates (3
games: 7, 9 and 35) Mchess 6 still wins 19-18. If you take out the cooked
games (5 games: 2, 25 and the duplicates 7,9 and 35), then Rebel 8 wins
18-17.
Enrique
Komputer Korner
Kai L=FCbke wrote:
> =
> George Dixon <de...@interactive.net> wrote:
> =
> >I also downloaded and installed some of the endgame tablebases into MCP6=
> >and then tried it out with KQ v KR and was completely intimidated when
> >the program immediately announced MATE IN 34 MOVES !!
> =
> But you will also find it silly how MCP6 is going to behave in, say, a
> KQPPK endgame: it will find that if it sacrifices the queen, the KPPK
> tablebase says "Mate in 26" or so, and consequently MChess will
> sacrifice the queen. Funny, but inevitable with endgame tablebases - I
> laughed at it many times with Crafty...
> =
> Shep
Nothing wrong with that. You just need the KQPP vs K tablebase that =
Steven Edwards will be happy to provide. =
-- =
Komputer Korner
The komputer that couldn't keep a password safe from prying eyes and
couldn't kompute the square root of 36^n.
H.Pieters
Hi,
You mentioned TB part, KQPPK. But I couldn't find it in the TB dir.
Please if you know of another download site with more TB's, tell us.
Here the current directory:
--------------------------------------------------------------------
Current directory is ftp://chess.onenet.net/pub/chess/TB
Please read the file README-TB
it was last modified on Thu Apr 20 11:01:14 1995 - 575 days ago
Nov 05 06:10 text/plain <A HREF="TB/.cache">.cache</A> 5Kb
Apr 23 1996 text/plain <A HREF="TB/.cache+">.cache+</A> 24Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KBBK.tbb.gz">KBBK.tbb.gz 338Kb
Jul 24 1995 text/plain <A HREF="TB/KBBK.tbs">KBBK.tbs</A> 7Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KBBK.tbw.gz">KBBK.tbw.gz 273Kb
Dec 13 1995 text/plain <A HREF="TB/KBBKN.tbs">KBBKN.tbs</A> 17Kb
Jun 24 1995 GNU Compressed <A HREF="TB/KBKB.tbb.gz">KBKB.tbb.gz 122Kb
Jul 24 1995 text/plain <A HREF="TB/KBKB.tbs">KBKB.tbs</A> 3Kb
Jun 24 1995 GNU Compressed <A HREF="TB/KBKB.tbw.gz">KBKB.tbw.gz 142Kb
Jun 24 1995 GNU Compressed <A HREF="TB/KBKN.tbb.gz">KBKN.tbb.gz 129Kb
Jul 24 1995 text/plain <A HREF="TB/KBKN.tbs">KBKN.tbs</A> 3Kb
Jun 24 1995 GNU Compressed <A HREF="TB/KBKN.tbw.gz">KBKN.tbw.gz 142Kb
Jun 19 1995 GNU Compressed <A HREF="TB/KBKP.tbb.gz">KBKP.tbb.gz 735Kb
Jul 24 1995 text/plain <A HREF="TB/KBKP.tbs">KBKP.tbs</A> 8Kb
Jun 19 1995 GNU Compressed <A HREF="TB/KBKP.tbw.gz">KBKP.tbw.gz 709Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KBNK.tbb.gz">KBNK.tbb.gz 619Kb
Jul 24 1995 text/plain <A HREF="TB/KBNK.tbs">KBNK.tbs</A> 9Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KBNK.tbw.gz">KBNK.tbw.gz 543Kb
Jul 24 1995 text/plain <A HREF="TB/KBNKN.tbs">KBNKN.tbs</A> 21Kb
Jun 15 1995 GNU Compressed <A HREF="TB/KBPK.tbb.gz">KBPK.tbb.gz 1453Kb
Jul 24 1995 text/plain <A HREF="TB/KBPK.tbs">KBPK.tbs</A> 8Kb
Jun 15 1995 GNU Compressed <A HREF="TB/KBPK.tbw.gz">KBPK.tbw.gz 1144Kb
Jun 24 1995 GNU Compressed <A HREF="TB/KNKN.tbb.gz">KNKN.tbb.gz 129Kb
Jul 24 1995 text/plain <A HREF="TB/KNKN.tbs">KNKN.tbs</A> 3Kb
Jun 24 1995 GNU Compressed <A HREF="TB/KNKN.tbw.gz">KNKN.tbw.gz 136Kb
Jun 19 1995 GNU Compressed <A HREF="TB/KNKP.tbb.gz">KNKP.tbb.gz 986Kb
Jul 24 1995 text/plain <A HREF="TB/KNKP.tbs">KNKP.tbs</A> 9Kb
Jun 19 1995 GNU Compressed <A HREF="TB/KNKP.tbw.gz">KNKP.tbw.gz 934Kb
Jun 23 1995 GNU Compressed <A HREF="TB/KNNK.tbb.gz">KNNK.tbb.gz 140Kb
Jul 24 1995 text/plain <A HREF="TB/KNNK.tbs">KNNK.tbs</A> 3Kb
Jun 24 1995 GNU Compressed <A HREF="TB/KNNK.tbw.gz">KNNK.tbw.gz 118Kb
Jun 15 1995 GNU Compressed <A HREF="TB/KNPK.tbb.gz">KNPK.tbb.gz 1478Kb
Jul 24 1995 text/plain <A HREF="TB/KNPK.tbs">KNPK.tbs</A> 8Kb
Jun 15 1995 GNU Compressed <A HREF="TB/KNPK.tbw.gz">KNPK.tbw.gz 1213Kb
Oct 07 1994 GNU Compressed <A HREF="TB/KPK.tbb.gz">KPK.tbb.gz 19Kb
Jul 24 1995 text/plain <A HREF="TB/KPK.tbs">KPK.tbs</A> 8Kb
Oct 07 1994 GNU Compressed <A HREF="TB/KPK.tbw.gz">KPK.tbw.gz 18Kb
Jan 30 1996 GNU Compressed <A HREF="TB/KPPK.tbb.gz">KPPK.tbb.gz 1168Kb
Jan 31 1996 text/plain <A HREF="TB/KPPK.tbs">KPPK.tbs</A> 8Kb
Jan 30 1996 GNU Compressed <A HREF="TB/KPPK.tbw.gz">KPPK.tbw.gz 838Kb
Jan 26 1996 GNU Compressed <A HREF="TB/KQBK.tbb.gz">KQBK.tbb.gz 446Kb
Jul 24 1995 text/plain <A HREF="TB/KQBK.tbs">KQBK.tbs</A> 5Kb
Jan 26 1996 GNU Compressed <A HREF="TB/KQBK.tbw.gz">KQBK.tbw.gz 261Kb
Oct 08 1994 GNU Compressed <A HREF="TB/KQK.tbb.gz">KQK.tbb.gz 7Kb
Jul 24 1995 text/plain <A HREF="TB/KQK.tbs">KQK.tbs</A> 5Kb
Oct 08 1994 GNU Compressed <A HREF="TB/KQK.tbw.gz">KQK.tbw.gz 5Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KQKB.tbb.gz">KQKB.tbb.gz 627Kb
Jul 24 1995 text/plain <A HREF="TB/KQKB.tbs">KQKB.tbs</A> 6Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KQKB.tbw.gz">KQKB.tbw.gz 428Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KQKN.tbb.gz">KQKN.tbb.gz 701Kb
Jul 24 1995 text/plain <A HREF="TB/KQKN.tbs">KQKN.tbs</A> 7Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KQKN.tbw.gz">KQKN.tbw.gz 416Kb
Jun 19 1995 GNU Compressed <A HREF="TB/KQKP.tbb.gz">KQKP.tbb.gz 1331Kb
Jul 24 1995 text/plain <A HREF="TB/KQKP.tbs">KQKP.tbs</A> 13Kb
Jun 19 1995 GNU Compressed <A HREF="TB/KQKP.tbw.gz">KQKP.tbw.gz 1036Kb
Jun 24 1995 GNU Compressed <A HREF="TB/KQKQ.tbb.gz">KQKQ.tbb.gz 419Kb
Jul 24 1995 text/plain <A HREF="TB/KQKQ.tbs">KQKQ.tbs</A> 7Kb
Jun 24 1995 GNU Compressed <A HREF="TB/KQKQ.tbw.gz">KQKQ.tbw.gz 220Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KQKR.tbb.gz">KQKR.tbb.gz 930Kb
Jul 24 1995 text/plain <A HREF="TB/KQKR.tbs">KQKR.tbs</A> 13Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KQKR.tbw.gz">KQKR.tbw.gz 555Kb
Jan 30 1996 GNU Compressed <A HREF="TB/KQNK.tbb.gz">KQNK.tbb.gz 429Kb
Jul 24 1995 text/plain <A HREF="TB/KQNK.tbs">KQNK.tbs</A> 5Kb
Jan 27 1996 GNU Compressed <A HREF="TB/KQNK.tbw.gz">KQNK.tbw.gz 258Kb
Jan 28 1996 GNU Compressed <A HREF="TB/KQPK.tbb.gz">KQPK.tbb.gz 1169Kb
Jan 31 1996 text/plain <A HREF="TB/KQPK.tbs">KQPK.tbs</A> 8Kb
Jan 28 1996 GNU Compressed <A HREF="TB/KQPK.tbw.gz">KQPK.tbw.gz 661Kb
Jun 23 1995 GNU Compressed <A HREF="TB/KQQK.tbb.gz">KQQK.tbb.gz 317Kb
Jul 24 1995 text/plain <A HREF="TB/KQQK.tbs">KQQK.tbs</A> 5Kb
Jun 23 1995 GNU Compressed <A HREF="TB/KQQK.tbw.gz">KQQK.tbw.gz 142Kb
Jan 27 1996 GNU Compressed <A HREF="TB/KQRK.tbb.gz">KQRK.tbb.gz 421Kb
Jul 24 1995 text/plain <A HREF="TB/KQRK.tbs">KQRK.tbs</A> 6Kb
Jan 27 1996 GNU Compressed <A HREF="TB/KQRK.tbw.gz">KQRK.tbw.gz 208Kb
Jan 27 1996 GNU Compressed <A HREF="TB/KRBK.tbb.gz">KRBK.tbb.gz 490Kb
Jul 24 1995 text/plain <A HREF="TB/KRBK.tbs">KRBK.tbs</A> 6Kb
Jan 27 1996 GNU Compressed <A HREF="TB/KRBK.tbw.gz">KRBK.tbw.gz 327Kb
Oct 08 1994 GNU Compressed <A HREF="TB/KRK.tbb.gz">KRK.tbb.gz 8Kb
Jul 24 1995 text/plain <A HREF="TB/KRK.tbs">KRK.tbs</A> 6Kb
Oct 08 1994 GNU Compressed <A HREF="TB/KRK.tbw.gz">KRK.tbw.gz 6Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KRKB.tbb.gz">KRKB.tbb.gz 205Kb
Jul 24 1995 text/plain <A HREF="TB/KRKB.tbs">KRKB.tbs</A> 8Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KRKB.tbw.gz">KRKB.tbw.gz 218Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KRKN.tbb.gz">KRKN.tbb.gz 334Kb
Jul 24 1995 text/plain <A HREF="TB/KRKN.tbs">KRKN.tbs</A> 10Kb
Oct 10 1994 GNU Compressed <A HREF="TB/KRKN.tbw.gz">KRKN.tbw.gz 338Kb
Jun 19 1995 GNU Compressed <A HREF="TB/KRKP.tbb.gz">KRKP.tbb.gz 1498Kb
Jul 24 1995 text/plain <A HREF="TB/KRKP.tbs">KRKP.tbs</A> 15Kb
Jun 19 1995 GNU Compressed <A HREF="TB/KRKP.tbw.gz">KRKP.tbw.gz 1364Kb
Jun 24 1995 GNU Compressed <A HREF="TB/KRKR.tbb.gz">KRKR.tbb.gz 387Kb
Jul 24 1995 text/plain <A HREF="TB/KRKR.tbs">KRKR.tbs</A> 10Kb
Jun 24 1995 GNU Compressed <A HREF="TB/KRKR.tbw.gz">KRKR.tbw.gz 229Kb
Jan 27 1996 GNU Compressed <A HREF="TB/KRNK.tbb.gz">KRNK.tbb.gz 487Kb
Jul 24 1995 text/plain <A HREF="TB/KRNK.tbs">KRNK.tbs</A> 6Kb
Jan 27 1996 GNU Compressed <A HREF="TB/KRNK.tbw.gz">KRNK.tbw.gz 342Kb
Jan 29 1996 GNU Compressed <A HREF="TB/KRPK.tbb.gz">KRPK.tbb.gz 1404Kb
Jan 31 1996 text/plain <A HREF="TB/KRPK.tbs">KRPK.tbs</A> 8Kb
Jan 29 1996 GNU Compressed <A HREF="TB/KRPK.tbw.gz">KRPK.tbw.gz 880Kb
Jun 23 1995 GNU Compressed <A HREF="TB/KRRK.tbb.gz">KRRK.tbb.gz 402Kb
Jul 24 1995 text/plain <A HREF="TB/KRRK.tbs">KRRK.tbs</A> 6Kb
Jun 23 1995 GNU Compressed <A HREF="TB/KRRK.tbw.gz">KRRK.tbw.gz 217Kb
Apr 20 1995 text/plain <A HREF="TB/README-TB">README-TB 9Kb
Jan 31 1996 GNU Compressed <A HREF="TB/Summary.gz">Summary.gz 60Kb
Jul 25 1995 text/plain <A HREF="TB/kbbk.tbs">kbbk.tbs 7Kb
Apr 20 1995 text/plain <A HREF="TB/tbt.c">tbt.c 30Kb
May 23 1995 Executable <A HREF="TB/tbt.exe">tbt.exe 18Kb
Kjell Tore Sandum
Are there any 5-piece endgames available for M Chess Pro? I also miss
the 4-piece endgame KPKP.
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ Kjell Tore Sandum \Email:Kjell.T...@hiMolde.no_/
_/ More Research,Molde College\Home:Grasskaret 6, 6400 Molde_/
_/ P.Box 308,N-6401 Molde,Norway\Tel:+4771212845, 90722906 _/
_/ Tel:+4771214000 Fax:+4771214100\ Fax: +4771212845 _/
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Tim Mirabile
klu...@mi.uni-koeln.de (Kai Lübke) wrote:
>George Dixon <de...@interactive.net> wrote:
>
>
>>I also downloaded and installed some of the endgame tablebases into MCP6
>>and then tried it out with KQ v KR and was completely intimidated when
>>the program immediately announced MATE IN 34 MOVES !!
>
>But you will also find it silly how MCP6 is going to behave in, say, a
>KQPPK endgame: it will find that if it sacrifices the queen, the KPPK
>tablebase says "Mate in 26" or so, and consequently MChess will
>sacrifice the queen. Funny, but inevitable with endgame tablebases - I
>laughed at it many times with Crafty...
I just checked, and it seems that MChess doesn't do this. I also tried the
Saavedra position against it, and it correctly defends by going into a KQKR
ending. Then I set up a position where it could play RxRd5 and get the Saavedra
position, which it correctly does, even though that transposes into a tablebase
mate in KRKP. It would be interesting to see if Crafty does this as well, or
avoids the tablebase mate to stay in the lost KRPKR, where it will not get the
chance to try to defend KQKR.
The real problem with Crafty's implementation of tablebases is in defending a
lost position. Because of the tablebases, it allows the win without putting up
any resistance. For example, I was playing a Crafty clone on FICS, and I had
R+P vs R, and was heading for the Lucena position. When I was about to queen,
it moved its rook away, so that it was no longer covering the queening square.
At that point, I realized it had tablebases, because it preferred to go into
KQRKR instead of KRK.
+----------------------------------------------------------------------+
| Tim Mirabile <t...@mail.htp.com> http://www.webcom.com/timm/ |
| TimM on FICS - telnet://fics.onenet.net:5000/ PGP Key ID: B7CE30D1 |
+----------------------------------------------------------------------+
Rolf W. Tueschen
"Enrique Irazoqui" <en...@bitmailer.net> wrote:
>Enrique
>
Hello Enrique,
I'm writing to you for the first time. So you may not take me wrong please.
But your answer exactly could be very useful for my simple questioning of
Ed Schroder. If you could be so kind to explain your method a bit more
precisesly it could be very helpful for Ed Schroder to understand my
questions/criticism.
Please,
Just define notion of your *duplicate*.
Just define when it schould be possible to take away a duplicate.
Just explain notion of your *cooked game*.
And finally explain when you simply take away such a cooked game.
I don't know anything about your match. Did you manage a real match -- I
mean with different colours?
Elsewhere I defined a *real* duplicate/double as follows:
Take a game X vs Y 1-0, 30 moves; then the exact double in statistical
terms is a game Y vs X 1-0, 30 moves and with the same identical move
order. Never heard of cooked games, but the killing procedure should be the
same.
Such a duplicate you can easily kill/take away. And my thesis is that
*ONLY* duplicates of that kind are allowed to be killed. Otherwise you
falsify your results. I find it very important to take each single game
score into the statistical calculating.
What is your opinion? If you please could send me by email as well?
Greetings
Rolf Tueschen
Robert Hyatt
H.Pieters (hpi...@nijmegen.inter.nl.net) wrote:
:
: Hi,
:
: You mentioned TB part, KQPPK. But I couldn't find it in the TB dir.
: Please if you know of another download site with more TB's, tell us.
: Here the current directory:
They are not available on ftp machines. Here's why....
For a 5-man ending, you need 24 bits to specify the location of 4 of
the men (6 bits each for squares 0-63) plus N bits for the last piece,
where N might be < 6, because (for example) one king can be constrained
to 1/4 of the board and then the position can be mirrored/flipped to
make it match the real position. So lets go with 4 bits, which gives
28 bits total. At one byte per entry (all 5 man endings may not fit
in 1 byte, because they might have mates > 126, but I'm not sure...)
this gives a total size of 262 megabytes, which might compress pretty
well, but which will still be *very* large. I got complaints about my
20+ megabyte book file, so imagine how difficult this would be to download...
Bob
Robert Hyatt
Kjell Tore Sandum (Kjell.T...@hiMolde.no) wrote:
: Are there any 5-piece endgames available for M Chess Pro? I also miss
: the 4-piece endgame KPKP.
:
KPKP hs not been release, because it does not take enpassant
captures into consideration. As a result, the program has to
be careful about which positions it looks up, otherwise it will
get a grossly wrong answer...
the 5 man endings are about 500mb per pair, so you need a huge
disk to store 'em... :)
Goran Grottling
In article <01bbd26d$4c4fff80$b648...@10.0.1.1>, en...@bitmailer.net says...
*
*lmk <l...@mindspring.com> wrote in article <3289C6...@mindspring.com>...
** I read that if you take out the 2 duplicate games ( which totaled 5
** out of the 20 played resulted in Rebel 8 winning 18-17 over MChess 6.0.
** If you include the duplicates MC6 wins 22-18.
*
*Not really. There are 40 games in total. If you take out duplicates (3
*games: 7, 9 and 35) Mchess 6 still wins 19-18. If you take out the cooked
*games (5 games: 2, 25 and the duplicates 7,9 and 35), then Rebel 8 wins
*18-17.
*
*Enrique
Dear Enrique,
This shows clearly how it would be, if the SSDF should analyze the result given (in this case 22-18) and then decide which
games should be counted and which games shouldn't.
We should then have a committee or something to decide what the "real" result would be! Some would vote 22-18, some 19-18,
some 17-18, some maybe for 15-12 and some for 10-10. The definition of what a "killer-game" really is varies from person to
person.
I think that most of you realize that the results from SSDF then will be subjective and nothing to rely on at all.
Did I get my point clear?
Goran Grottling
H.Pieters
Hi Bob,
But I stil wish to download those large TB-files, because you can have
them on a 2.nd (hard)drive or burn it to a CD-ROM. MCP6 can use two
drives with tablebases in the same time, as the manual says.
All the (work)files out of TB.dir are more as 100 MB together
and packed to a zip about 30 MB. I put that packed file TBDIR.zip
with the complete TB-directory workfiles on Bullet-BBS (denknet)
in Amsterdam. It took 2,5 hours of uploading.
Please give the other sources with extended endgame-tablebases.
Hans.
On 16 Nov 1996, Robert Hyatt wrote:
> H.Pieters (hpi...@nijmegen.inter.nl.net) wrote:
> :
> : Hi,
> :
> : You mentioned TB part, KQPPK. But I couldn't find it in the TB dir.
> : Please if you know of another download site with more TB's, tell us.
> : Here the current directory:
> :
>
> They are not available on ftp machines. Here's why....
>....
Steven J. Edwards
hy...@crafty.cis.uab.edu (Robert Hyatt) writes:
>Kjell Tore Sandum (Kjell.T...@hiMolde.no) wrote:
>: Are there any 5-piece endgames available for M Chess Pro? I also miss
>: the 4-piece endgame KPKP.
>KPKP hs not been release, because it does not take enpassant
>captures into consideration. As a result, the program has to
>be careful about which positions it looks up, otherwise it will
>get a grossly wrong answer...
True. Fortunately, I think that only about 8% or so of the
evaluations need to be skipped.
>the 5 man endings are about 500mb per pair, so you need a huge
>disk to store 'em... :)
The five man pawnless endings, like KRBKR, require exactly 160 Mbyte
per file. For both sides to move, one needs both files in a pair for
a total of 320 Mbyte.
The five man endings with at least one pawn, like KRPKR, require
exactly 512 Mbyte per file. For both sides to move, one needs both
files in a pair for a total of 1 Gbyte.
Having both files in a pair is not strictly necessary, but it speeds
things up a bit if the tablebases are probed mnay times during a
search instead of just near the top of the search tree.
It is only a matter of time until storage and bandwidth come down in
price enough to handle the data.
-- Steven (s...@mv.mv.com)
Tim Mirabile
"H.Pieters" <hpi...@nijmegen.inter.nl.net> wrote:
>Hi,
>You mentioned TB part, KQPPK. But I couldn't find it in the TB dir.
>Please if you know of another download site with more TB's, tell us.
>Here the current directory:
You wont find it here. KQPPK is a five man class - it's a little to big to
download, even when compressed.
--
Tim Mirabile <t...@mail.htp.com> - http://www.webcom.com/timm/
Visit my homepage for information on USCF & FIDE rated chess on Long Island.
TimM on the Free Internet Chess Server - telnet://fics.onenet.net:5000/
ICD/Your Move Chess & Games - http://www.icdchess.com/
The opinions of my employers are not necessarily mine, and vice versa.
Robert Hyatt
H.Pieters (hpi...@nijmegen.inter.nl.net) wrote:
: Hi Bob,
:
: But I stil wish to download those large TB-files, because you can have
: them on a 2.nd (hard)drive or burn it to a CD-ROM. MCP6 can use two
: drives with tablebases in the same time, as the manual says.
:
: All the (work)files out of TB.dir are more as 100 MB together
: and packed to a zip about 30 MB. I put that packed file TBDIR.zip
: with the complete TB-directory workfiles on Bullet-BBS (denknet)
: in Amsterdam. It took 2,5 hours of uploading.
:
: Please give the other sources with extended endgame-tablebases.
: Hans.
:
: On 16 Nov 1996, Robert Hyatt wrote:
:
There simply aren't any sources for them yet. Steven would first have
to spend a few months uploading, then you'd have to spend the next few
months downloading.
A CD rom won't hold more than a pair (or two) of the 5-man endings because
of their size. and with a pawn, this gets much worse. Steven reported
that KRPKR needs 1,024 megabytes for the black and white to move files...
that's *one* pair, needing a gig..
Kjell Tore Sandum
> KPKP hs not been release, because it does not take enpassant
> captures into consideration. As a result, the program has to
> be careful about which positions it looks up, otherwise it will
> get a grossly wrong answer...
I understand that en-passant is a special problem that must be taken care of. But isn't KPKP an
important class of endgames that some chessplaying engines make (a few) mistakes in? I hope to
see KPKP available for Crafty and M Chess Pro soon! (But maybe these programs play KPKP well
enough without tablebases?)
Pawn promotion is another special case for the programs to handle. How do Crafty handle this
(for instance conversion from KBPK to KQBK)?
I'm surprised that some commercial programs (such as Fritz 4.01) make decisive mistakes in
endgames played from the tablebases. For instance, I watched DrWho (Fritz 4.01) play Crafty in an
dead drawn KRPKR endgame, and just after Lonnie told me that Fritz hit the tablebases, the
program made a terrible blunder, and Crafty won easily (also playing from tablebases?). Is it
difficult to make a chess program play correctly from endgame tablebases? Is Crafty the only
program (so far) that does this without any bugs?
> the 5 man endings are about 500mb per pair, so you need a huge
> disk to store 'em... :)
I would gladly buy a 2.5 Gb HD to use for the most important 5-piece tablebases. (It's dazzling
to watch a program announce "Mate in 51"!) I guess they can be compressed by a relatively large
factor... On the Fritz CD I find the following number of megabytes for some important tablebases:
KQPKQ 37
KRPKR 56
KQKRP 91
Sincerely
Kjell T.
Robert Hyatt
Kjell Tore Sandum (Kjell.T...@hiMolde.no) wrote:
:
The problem with fritz is it uses the distance to conversion form of endgame
databases, rather than the distance to mate format Steven uses. Fritz went
for the longest conversion since it was on the losing side, but it ignored
the board position and stepped right into a short mate. It's happened on
many occasions, although Crafty never has the problem because a database probe
returns the exact distance to mate, even if the mate spans a couple of
databases, like a KRKP that turns into a KRKQ, etc...
Robert Hyatt
I already use it, but as I mentioned, because of the en passant problem,
Steven doesn't want to make it public, because all of the tablebase users
(other than crafty) will produce incorrect evaluations in those few positions
where an enpassant capture is ever going to be possible (pawns on adjacent
files, one pawn being on its original square...)
It's really not a necessary tablebase in Crafty, because crafty already has
specific evaluation code for the square of the pawn and understands most of
these positions instantly. For the few it doesn't understand, it can really
search deeply very quickly and probably will play most correctly without the
KPKP database. The real help comes when KPKP translates into a won KQKQ type
of position..
Bob
Steven J. Edwards
hy...@crafty.cis.uab.edu (Robert Hyatt) writes:
>H.Pieters (hpi...@nijmegen.inter.nl.net) wrote:
>: But I stil wish to download those large TB-files, because you can have
>: them on a 2.nd (hard)drive or burn it to a CD-ROM. MCP6 can use two
>: drives with tablebases in the same time, as the manual says.
>:
>: All the (work)files out of TB.dir are more as 100 MB together
>: and packed to a zip about 30 MB. I put that packed file TBDIR.zip
>: with the complete TB-directory workfiles on Bullet-BBS (denknet)
>: in Amsterdam. It took 2,5 hours of uploading.
>:
>: Please give the other sources with extended endgame-tablebases.
>: Hans.
>: On 16 Nov 1996, Robert Hyatt wrote:
>There simply aren't any sources for them yet. Steven would first have
>to spend a few months uploading, then you'd have to spend the next few
>months downloading.
Maybe it's not so bad if fast modems are involved, and (of course) the
files are gzip compressed. I am thinking about uploading some of the
pawnless five man classes to an ftp site this way. However, the files
are still quite large: up to 40 Mbyte or so. Perhaps the larger
problem is finding an ftp site willing to host them.
Again, I think the best approach right now is to exchange Iomega Zip
drive 100 Mbyte disk cartridges with Linux ext2 filesystem formatting.
Alas, neither a CD-ROM burner nor a high speed direct Internet
connection are in my budget for the next year or so.
>A CD rom won't hold more than a pair (or two) of the 5-man endings because
>of their size. and with a pawn, this gets much worse. Steven reported
>that KRPKR needs 1,024 megabytes for the black and white to move files...
It would be possible to get by fairly well with only (say) the WTM
side of KRPKR and so the 512 Mbyte file would fit, uncompressed, on a
single CD-ROM. A user may also shrink the requirements by storing
each position evaluation in a single bit (won/not-won) instead of a
single byte (distance to mate/loss, draw, broken). A won/not-won WTM
KRPKR would fit into 64 Mbyte.
-- Steven (s...@mv.mv.com)
Michael F. Byrne
Goran Grottling <goran.g...@mailbox.swipnet.se> wrote in article
<56j1ah$2...@mn5.swip.net>...
> In article <01bbd26d$4c4fff80$b648...@10.0.1.1>, en...@bitmailer.net
says...
> *
> *lmk <l...@mindspring.com> wrote in article
<3289C6...@mindspring.com>...
> ** I read that if you take out the 2 duplicate games ( which totaled 5
> Dear Enrique,
>
> This shows clearly how it would be, if the SSDF should analyze the
result given (in this case 22-18) and then decide which
> games should be counted and which games shouldn't.
>
> We should then have a committee or something to decide what the "real"
result would be! Some would vote 22-18, some 19-18,
> some 17-18, some maybe for 15-12 and some for 10-10. The definition of
what a "killer-game" really is varies from person to
> person.
>
> I think that most of you realize that the results from SSDF then will be
subjective and nothing to rely on at all.
>
> Did I get my point clear?
>
> Goran Grottling
>
>
well one thing is clear..the results as posted are subjective
anyway.....but as somebody else pointed out....it's the best we have and
if it wasn't for SSDF we would not anything at all....I have seen enough
posts from SSDF that satisfies me that they they take
this seriously and are concerned with presenting the programs as they
are....for the mission that they have set out to do..they are doing
it....the ? is should that process be modified...or enhance with additional
forms of testing or add'l ratings for example...one list could be without
doubles the list could be with doubles...so the user know exactly what the
ratings are with and without...but the games wou;ld have to be exact
doubles...if move 47 varies...it is no longer a double... the other option
is to present a a rating from w/o opening books
but from standard opening line with each program getting a shot with the
same line as white agaimnst the same opponent...just my $.02
Kjell Tore Sandum
[snip]
> : ...Is it difficult to make a chess program play correctly from endgame tablebases?
I must answer my own question here:
M Chess Pro 6.0 also uses the TBs, and does so without any bugs.
NOTE:
Just be sure to download the KQBK, KQNK, KQQK and even KQRK
if you have KPPK, KBPK and KNPK tablebases. This is because
pawn promotion converts to a new class of endgames.
Kjell T.
Kjell Tore Sandum
Hyatt:
> The problem with fritz is it uses the distance to conversion form of endgame
> databases, rather than the distance to mate format Steven uses. Fritz went
> for the longest conversion since it was on the losing side, but it ignored
> the board position and stepped right into a short mate. It's happened on
> many occasions, although Crafty never has the problem because a database probe
> returns the exact distance to mate, even if the mate spans a couple of
> databases, like a KRKP that turns into a KRKQ, etc...
But the problems I have seen with Fritz 4.01 (and 4.00) is decisive mistakes like drawing won
positions and losing drawn positions - all because of the tablebases on the CD-rom. I would
recommend all Fritz4 users to play without the endgame CD-ROM.
Kjell T.
Komputer Korner
H.Pieters wrote:
>
> snipped
>
I didn't say when Steven will provide it, but he promises to do it.
--
Komputer Korner
The komputer that couldn't keep a password safe from prying eyes,
couldn't kompute the square root of 36^n, and missed the real motive
of Chessbase.
Urban Koistinen
Robert Hyatt (hy...@crafty.cis.uab.edu) wrote:: : But I stil wish to download those large TB-files, because you can have
: : them on a 2.nd (hard)drive or burn it to a CD-ROM. MCP6 can use two
: : drives with tablebases in the same time, as the manual says.
: :
: : All the (work)files out of TB.dir are more as 100 MB together
: : and packed to a zip about 30 MB. I put that packed file TBDIR.zip
: : with the complete TB-directory workfiles on Bullet-BBS (denknet)
: : in Amsterdam. It took 2,5 hours of uploading.
: :
: : Please give the other sources with extended endgame-tablebases.
: : Hans.
: :
: : On 16 Nov 1996, Robert Hyatt wrote:
: There simply aren't any sources for them yet. Steven would first have
: to spend a few months uploading, then you'd have to spend the next few
: months downloading.
: A CD rom won't hold more than a pair (or two) of the 5-man endings because
: of their size. and with a pawn, this gets much worse. Steven reported
: that KRPKR needs 1,024 megabytes for the black and white to move files...
A CD rom will hold all 5-man endings that Steven has computed to date
if they are stored compressed with gzip.
I have only gotten mails from 4 people to date who want to buy them
at USD 30. I'll try to get a sponsor so I can make it anyway.
Anyone with USD 150 to spare?
Komputer Korner
Robert Hyatt wrote:
> snipped-
Is Fritz the only program besides Crafty that will access and play from
a 5 man EG? As far as I know, Fritz only does the KRP vs KR though.
Kjell Tore Sandum
> A CD rom will hold all 5-man endings that Steven has computed to date
> if they are stored compressed with gzip.
>
> I have only gotten mails from 4 people to date who want to buy them
> at USD 30.
Count me in!
Kjell Tore Sandum
Kjell Tore Sandum
Komputer Korner wrote:
>
> Is Fritz the only program besides Crafty that will access and play from
> a 5 man EG? As far as I know, Fritz only does the KRP vs KR though.
M Chess Pro 6.0 reads and uses *.TBB and *.TBW files. ("5 man" will be available soon.)
BTW: I've had problems using the KRPKR bases in Fritz. In some positions Fritz make major
blunders when playing from the CD-ROM. Is this bug fixed now?
Robert Hyatt
Komputer Korner (kor...@netcom.ca) wrote:
: Robert Hyatt wrote:
: > snipped-
:
: Is Fritz the only program besides Crafty that will access and play from
: a 5 man EG? As far as I know, Fritz only does the KRP vs KR though.
: The komputer that couldn't keep a password safe from prying eyes,
: couldn't kompute the square root of 36^n, and missed the real motive
: of Chessbase.
And it used Ken's DB format, not the usual tablebase files posted around
by Steven Edwards. These are distance-to-conversion databases and can't
be mixed with Fritz as far as I know.
Bob
brucemo
Kjell Tore Sandum wrote:
> I understand that en-passant is a special problem that must be taken care of. But isn't KPKP an
> important class of endgames that some chessplaying engines make (a few) mistakes in? I hope to
> see KPKP available for Crafty and M Chess Pro soon! (But maybe these programs play KPKP well
> enough without tablebases?)
>
> Pawn promotion is another special case for the programs to handle. How do Crafty handle this
> (for instance conversion from KBPK to KQBK)?
>
> I'm surprised that some commercial programs (such as Fritz 4.01) make decisive mistakes in
> endgames played from the tablebases. For instance, I watched DrWho (Fritz 4.01) play Crafty in an
> dead drawn KRPKR endgame, and just after Lonnie told me that Fritz hit the tablebases, the
> program made a terrible blunder, and Crafty won easily (also playing from tablebases?). Is it
> difficult to make a chess program play correctly from endgame tablebases? Is Crafty the only
> program (so far) that does this without any bugs?
I don't think any competent program would mis-evaluate ANY KP vs KP position, if it encountered it
at the root of the search, i.e. if you handed the position to the program. However, it might
mis-evaluate it if it found it in the search, meaning that it might not have enough depth to get
the answer right if it found the position way out near the search horizon.
Pawn promotion is handled automatically by the tablebases.
No offense to Bob, Crafty has a big bug (so does my program) unless he's figured out how to fix it
(I haven't).
If the program has a rook, and the opponent has a queen and a pawn, and the pawn is hanging, Crafty
won't take the pawn, because it's mate in X due to the KQ vs KR tablebase. If it does not take the
pawn, it is not mate in X, because it doesn't have a KQP vs KR tablebase, but the ending is
obviously much more easily winnable in practice. Adding five-man classes will just make this
worse, you could have a program avoid taking a pawn, just to stay out of a lost KBB vs KN.
As far as I know it doesn't have bugs involving losing theoretically drawn endings. Other programs
have implemented this as well, I assume without bugs, but I don't know if you can get any of them.
bruce
Rolf W. Tueschen
hy...@crafty.cis.uab.edu (Robert Hyatt) wrote:
>Komputer Korner (kor...@netcom.ca) wrote:
>: Robert Hyatt wrote:
>: > snipped-
>:
>: Is Fritz the only program besides Crafty that will access and play from
>: a 5 man EG? As far as I know, Fritz only does the KRP vs KR though.
>: --
>: Komputer Korner
>: The komputer that couldn't keep a password safe from prying eyes,
>: couldn't kompute the square root of 36^n, and missed the real motive
>: of Chessbase.
Another ... and couldn't.
Fritz4 has the following endings:
QR vs R (strange?!)
Q vs RP
RP vs R
QP vs Q
Rolf
Enrique Irazoqui
Goran Grottling <goran.g...@mailbox.swipnet.se> wrote in article
<56j1ah$2...@mn5.swip.net>...
> In article <01bbd26d$4c4fff80$b648...@10.0.1.1>, en...@bitmailer.net
says...
> *
> *lmk <l...@mindspring.com> wrote in article
<3289C6...@mindspring.com>...
I have been against killer lines and I still don't care for them, but I now
think that the issue of counting or not cooked games is dead. In my
opinion, the point is that it's impossible in practical terms to keep
identifying cooked games, particularly if hidden books are implemented.
Therefore I think that the only feasible way to go is to include all played
games for rating purposes. I don't see any other practical alternative.
Tim Mirabile
Kjell Tore Sandum <Kjell.T...@hiMolde.no> wrote:
>[snip]
>> : ...Is it difficult to make a chess program play correctly from endgame tablebases?
>> : Is Crafty the only program (so far) that does this without any bugs?
>
>I must answer my own question here:
>
> M Chess Pro 6.0 also uses the TBs, and does so without any bugs.
>
> NOTE:
> Just be sure to download the KQBK, KQNK, KQQK and even KQRK
> if you have KPPK, KBPK and KNPK tablebases. This is because
> pawn promotion converts to a new class of endgames.
Is it possible that MChess 6 doesn't probe the tablebases during a search? It
seems like it only uses them when the board position reaches a tablebase ending.
Robert Hyatt
Tim Mirabile (t...@mail.htp.com) wrote:
It's a trade-off. In Crafty, I probe only after a capture, only when there
are 4 or fewer pieces left after a capture, and only during the basic
search, *not* in the quiescece search. It slows down by as much as 50%
in endings, of course the slowdown is relative, because it is grafting very
deep searches from the database.
However, the main point is, if you don't probe during the search, you lose
a big benefit, that of using your fast search to reach positions you can
say are "won, lost or drawn" instantly... If you don't probe them except at
the root, it will often be too late...
Kjell Tore Sandum
> Is it possible that MChess 6 doesn't probe the tablebases during a search? It
> seems like it only uses them when the board position reaches a tablebase ending.
I'm not sure about this one, but it looks like MCP6 checks any exchange in the root position to
see if the exchange leads to a TB position. It would probably take too much time to probe the
tablebases during the search (even though the program only needs to do this when the material is
reduced enough to make it possible(/likely) to hit a TB position).
The following programs use TBs (distance to mate or conversion):
Fritz4 | C | ? |
Tascbase (The King) | ? | ? |
CheckCheck | ? | P?|
M Chess Pro 6.0 | M | R |
Crafty | M | ? |
(any other?)
It would be interesting to know how all these programs use the TBs (checking only the root
position [R] or probing the tablebases during the search [P]) and the type (distance to mate [M]
or conversion [C]). I think that CheckCheck "probes" the tablebases during a search...
Robert Hyatt
Kjell Tore Sandum (Kjell.T...@hiMolde.no) wrote:
: > seems like it only uses them when the board position reaches a tablebase ending.
:
: I'm not sure about this one, but it looks like MCP6 checks any exchange in the root position to
: see if the exchange leads to a TB position. It would probably take too much time to probe the
: tablebases during the search (even though the program only needs to do this when the material is
: reduced enough to make it possible(/likely) to hit a TB position).
:
: The following programs use TBs (distance to mate or conversion):
:
: Fritz4 | C | ? |
: Tascbase (The King) | ? | ? |
: CheckCheck | ? | P?|
: M Chess Pro 6.0 | M | R |
: Crafty | M | ? |
: (any other?)
:
: It would be interesting to know how all these programs use the TBs (checking only the root
: position [R] or probing the tablebases during the search [P]) and the type (distance to mate [M]
: or conversion [C]). I think that CheckCheck "probes" the tablebases during a search...
Crafty probes during the search, but not the quiescence search. However, it
only probes when it *knows* it will hit, because it has all 4-man endings,
and only probes when a capture takes it to 4, 3 or 2 man positions. which
have to hit...
Bob
Ed Schröder
From: "Enrique Irazoqui" <en...@bitmailer.net>
: I have been against killer lines and I still don't care for them,
: but I now think that the issue of counting or not cooked games is
: dead. In my opinion, the point is that it's impossible in practical
: terms to keep identifying cooked games, particularly if hidden books
: are implemented.
: Therefore I think that the only feasible way to go is to include
: all played games for rating purposes. I don't see any other practical
: alternative.
Hidden books?
Everything is allowed?
Meaning programmers will be forced to spend MONTHS if not YEARS of their
precious time on cooked (hidden?) opening books in order to get a higher
rating on SSDF?
You must be kidding!
Programmers should spend their time on improving their chess engine for
people instead of making programs for SSDF!
- Ed Schroder -
Enrique Irazoqui
Enrique Irazoqui <en...@bitmailer.net> wrote
> Ed Schröder <rebc...@xs4all.nl> wrote
Subject: Re: Rebel 8 vs .MCP6
> Hidden books?
Why not? If it is feasible, and it is, it will be done.
> Everything is allowed?
Anything that produces a legal move is allowed in chess. Legal, not
necessarily fair.
> Meaning programmers will be forced to spend MONTHS if not YEARS of their
> precious time on cooked (hidden?) opening books in order to get a higher
> rating on SSDF?
Unless you come with a better solution. I have not heard it yet.
> You must be kidding!
I wish I were. I don't like it better than you do. It's very simple: cooks
are here to stay. And I don't believe in some sort of "gentleman's
agreement".
> Programmers should spend their time on improving their chess engine for
> people instead of making programs for SSDF!
Absolutely. But if you have been concerned by killer lines it's precisely
because of SSDF's list. If SSDF doesn't change procedures, programmers
concerned about the ranking of their programs will have to fight back.
Learners (I don't believe much in them in their present state), updated
books... One obvious problem is that programs with killer lines will drop
their ratings quite dramatically after a year. Therefore people buying a
program because of this rating can be mislead.
Ed: it's not anymore a matter of liking this situation or not. Personally I
hate it. It is a matter of dealing with the real world. I wish you could
come with a fair solution. I can't think of any.
Enrique
Michael F. Byrne
Ed Schröder <rebc...@xs4all.nl> wrote in article
<56uc1j$q...@news.xs4all.nl>...
> From: "Enrique Irazoqui" <en...@bitmailer.net>
>
> : I have been against killer lines and I still don't care for them,
> : but I now think that the issue of counting or not cooked games is
> : dead. In my opinion, the point is that it's impossible in practical
> : terms to keep identifying cooked games, particularly if hidden books
> : are implemented.
>
[deleted]
> Hidden books?
>
> Everything is allowed?
>
> Meaning programmers will be forced to spend MONTHS if not YEARS of their
> precious time on cooked (hidden?) opening books in order to get a higher
> rating on SSDF?
>
> You must be kidding!
>
> Programmers should spend their time on improving their chess engine for
> people instead of making programs for SSDF!
>
> - Ed Schroder -
>
agree Ed....SSDF is way overrated anyway (no pun intended)...Programmers
should spend
their time on the chess engine and perhaps a little book learning might be
wise...those who start with these hidden books will wasting their
time..esecially as more sophisticated learning is implemented into the
programs
Mark Rawlings
"Ed Schröder" <rebc...@xs4all.nl> wrote:
>From: "Enrique Irazoqui" <en...@bitmailer.net>
>: I have been against killer lines and I still don't care for them,
>: but I now think that the issue of counting or not cooked games is
>: dead. In my opinion, the point is that it's impossible in practical
>: terms to keep identifying cooked games, particularly if hidden books
>: are implemented.
>: Therefore I think that the only feasible way to go is to include
>: all played games for rating purposes. I don't see any other practical
>: alternative.
>Hidden books?
>Everything is allowed?
>Meaning programmers will be forced to spend MONTHS if not YEARS of their
>precious time on cooked (hidden?) opening books in order to get a higher
>rating on SSDF?
Does it really take that long to cook opening books? I thought a
program with a learning feature could just be set up to continually
play a rival program for hundreds of games, and when it's done it just
spits out a nice cooked book. Since all programs don't have a
learning feature, maybe it's harder for some programmers than others?
(or maybe I just don't know how it's done!)
Mark
Jeff Hamm
>Please,
>Just define notion of your *duplicate*.
>Just define when it schould be possible to take away a duplicate.
>Just explain notion of your *cooked game*.
>And finally explain when you simply take away such a cooked game.
>
>I don't know anything about your match. Did you manage a real match -- I
>mean with different colours?
>
>Elsewhere I defined a *real* duplicate/double as follows:
>
>Take a game X vs Y 1-0, 30 moves; then the exact double in statistical
>terms is a game Y vs X 1-0, 30 moves and with the same identical move
>order. Never heard of cooked games, but the killing procedure should be the
>same.
>
>Such a duplicate you can easily kill/take away. And my thesis is that
>*ONLY* duplicates of that kind are allowed to be killed. Otherwise you
>falsify your results. I find it very important to take each single game
>score into the statistical calculating.
>
>What is your opinion? If you please could send me by email as well?
>
>Greetings
>
>Rolf Tueschen
>
Hi,
I think it becomes important to determine what a "match" between two
programs is trying to demonstrate before one considers the idea of
"duplicate" games. If one wishes to use the results to predict the "likely"
outcome of a game between the two programmes then the removal of any games
would be inappropriate, regardless of one's definition of "duplicate" games.
However, if one wants to get an idea of "general chess strength", it seems
to me important to evaluate performance based on a series of "unique" games.
As an extreme example, say I have X play Y in 18 games. X wins 10 and Y
wins 8. However, all of X's wins are identical games (X makes the same
moves, Y makes the same reply ... end result is win for X), where as in Y's 8
wins, none of the games follow such a pattern. So, which programme is likely
to win the next game? Probability would predict that X is more likely to win
than Y (10 wins to 8). But all this really shows is that X is better at
playing one particular line, which Y seems willing to fall into fairly often.
If the game does not follow that particular line, then one would expect Y to
win (8 wins to 0).
From this, I would define a duplicated game as game A) X vs Y having
the same moves as game B) X vs Y, rather than game A) X vs Y having the same
moves as game B) Y vs X. In terms of removing duplicated games, I would
count the first instance of the game, and discount the "repititions". In
otherwords, in the "trimmed" result, this would end up as X 1 win, Y 8 wins.
Regardless of ones' definition of a duplicated game, in the reportng of
match results, it seems if any trimming is to be done, it is important to
clearly define what criterion games are ommitted. I'm not even going to
address the idea of duplicates being "any position which arises from the
opening book" and results in identical moves thereafter. The X vs Y = Y vs X
game seems unnecessary to consider as a duplicate since the results off set
each other (both programs get 1 point) while using the above selection would
allow the offset of points, but not the accumulation of points by one program
continually playing the same "win" over and over. Just check out many of the
computer accounts on FICS and most indicate that such "repeated" games are
considered "abuse".
- Jeff Hamm
Komputer Korner
Robert Hyatt wrote:
snipped>
Since Tascbase and Fritz have the 5 man EG TB's on CD ROM's but can't
use them to play with ( not entirely true, Fritz uses KR vs KRP) and
M-Chess and Crafty only access the 4 man , I was wondering why they
don't access the 5 man EG's. I guess that it is because the CDROM's
supplied by Fritz and Tascbase are mini versions that don't have the
complete files? If that is the case, then we will have to wait for
DVD discs to be able to enjoy 5 or 6 man EG's or am I missing something?
Komputer Korner
Michael F. Byrne wrote:
>snipped
Learning programs help against doubles.
Wide wide random books help against cooked books.
Multiple random search engines help against non existent killer engines.
There is always a vaccination against "killers".
Kai Lübke
raw...@erols.com (Mark Rawlings) wrote:
>Does it really take that long to cook opening books? I thought a
>program with a learning feature could just be set up to continually
>play a rival program for hundreds of games, and when it's done it just
>spits out a nice cooked book. Since all programs don't have a
>learning feature, maybe it's harder for some programmers than others?
>(or maybe I just don't know how it's done!)
I don't think it's as easy as that. Chances are you probably won't
find the (very few) "holes" in your opponent's engine.
Maybe this procedure can assist you in finding them, but the main work
remains for the (human) creator of the opening book and/or the
programmer.
Remember you can't just say "I want to create the opening book that's
best for my program, so I just let it play 1000s of games with opening
book turned off and learning turned on"... ;-)
Shep
Kai Lübke
Komputer Korner <kor...@netcom.ca> wrote:
>Robert Hyatt wrote:
>snipped>
>Since Tascbase and Fritz have the 5 man EG TB's on CD ROM's but can't
>use them to play with ( not entirely true, Fritz uses KR vs KRP) and
> M-Chess and Crafty only access the 4 man , I was wondering why they
>don't access the 5 man EG's. I guess that it is because the CDROM's
> supplied by Fritz and Tascbase are mini versions that don't have the
>complete files? If that is the case, then we will have to wait for
>DVD discs to be able to enjoy 5 or 6 man EG's or am I missing something?
I don't exactly remember the formula for the size of EGTB's, but for 6
man endings, even the DVD's won't be enough. Maybe in 10-15
years... ;-(
Shep
Robert Hyatt
Komputer Korner (kor...@netcom.ca) wrote:
: Robert Hyatt wrote:
: snipped>
:
: Since Tascbase and Fritz have the 5 man EG TB's on CD ROM's but can't
: use them to play with ( not entirely true, Fritz uses KR vs KRP) and
: M-Chess and Crafty only access the 4 man , I was wondering why they
: don't access the 5 man EG's. I guess that it is because the CDROM's
: supplied by Fritz and Tascbase are mini versions that don't have the
: complete files? If that is the case, then we will have to wait for
: DVD discs to be able to enjoy 5 or 6 man EG's or am I missing something?
:
Crafty wouldn't access them for three reasons:
1. the endgames are distance-to-conversion, which crafty doesn't use. It
only wants distance-to-mate. For many reasons not worth mentioning and
starting *that* thread up again...
2. they are not in the same format as Steven's data, and also require on-the-
fly uncompression which crafty doesn't do.
3. a CDRom is terribly slow to access. Probing it during a game like I do the
tablebase files would be an absolute killer.
Bob
Steven J. Edwards
Komputer Korner <kor...@netcom.ca> writes:
>Since Tascbase and Fritz have the 5 man EG TB's on CD ROM's but can't
>use them to play with ( not entirely true, Fritz uses KR vs KRP) and
> M-Chess and Crafty only access the 4 man , I was wondering why they
>don't access the 5 man EG's. I guess that it is because the CDROM's
> supplied by Fritz and Tascbase are mini versions that don't have the
>complete files? If that is the case, then we will have to wait for
>DVD discs to be able to enjoy 5 or 6 man EG's or am I missing something?
Crafty can handle five man tablebases; it needs a one line change
where it tests the number of men on the board. In the file search.c,
change the line:
if ((CaptureOrPromote(current_move[ply-1]) || (ply < 4)) &&
(PopCnt(Occupied) < 5)) {
to:
if ((CaptureOrPromote(current_move[ply-1]) || (ply < 4)) &&
(PopCnt(Occupied) < 6)) {
And that should do the trick. But note that it will slow things down
a bit in some cases if not many five man classes are present.
Experimentation is needed.
-- Steven (s...@mv.mv.com)
Kjell Tore Sandum
> 1. the endgames are distance-to-conversion, which crafty doesn't use. It
> only wants distance-to-mate. For many reasons not worth mentioning and
> starting *that* thread up again...
I'm interested in this discussion (but I didn't read rgcc back then). Where can I find more
info?
Thanks!
Komputer Korner
Komputer Korner wrote:
>
> Robert Hyatt wrote:
> snipped>
>
> use them to play with ( not entirely true, Fritz uses KR vs KRP) and
> M-Chess and Crafty only access the 4 man , I was wondering why they
> don't access the 5 man EG's. I guess that it is because the CDROM's
> supplied by Fritz and Tascbase are mini versions that don't have the
> complete files? If that is the case, then we will have to wait for
> DVD discs to be able to enjoy 5 or 6 man EG's or am I missing something?
>
>
> Komputer Korner
> The komputer that couldn't keep a password safe from prying eyes,
> couldn't kompute the square root of 36^n, and missed the real motive
> of Chessbase.
Rolf informs me that Fritz can access 4 different 5 man EG's.
RP vs R, QR vs R, Q vs RP, QP vs Q. The question is: Is Fritz
the only micro program that can actually use 5 man EG tablebases in it's
play?
Rolf W. Tueschen
JPH...@is2.dal.ca (Jeff Hamm) wrote:
>(Rolf Tueschen wrote:)
>>Take a game X vs Y 1-0, 30 moves; then the exact double in statistical
>>terms is a game Y vs X 1-0, 30 moves and with the same identical move
>>order. Never heard of cooked games, but the killing procedure should be the
>>same.
>>
>>Such a duplicate you can easily kill/take away. And my thesis is that
>>*ONLY* duplicates of that kind are allowed to be killed. Otherwise you
>>falsify your results. I find it very important to take each single game
>>score into the statistical calculating.
>>
> I think it becomes important to determine what a "match" between two
>programs is trying to demonstrate before one considers the idea of
>"duplicate" games.
> However, if one wants to get an idea of "general chess strength", it seems
>to me important to evaluate performance based on a series of "unique" games.
> From this, I would define a duplicated game as game A) X vs Y having
>the same moves as game B) X vs Y, rather than game A) X vs Y having the same
>moves as game B) Y vs X. In terms of removing duplicated games, I would
>count the first instance of the game, and discount the "repititions". In
>otherwords, in the "trimmed" result, this would end up as X 1 win, Y 8 wins.
----------------------------------------------------------------------------------------------------------------------------------
Preface
~~~~~~
Thanks for the very interesting analysis, Jeff. We could make progress now.
I’d like to confirm some experts that my post only does belong to Jeff’s
article. I don’t want to disturb any programmers valuable thoughts about
this topic.
First let me tell of my first steps into chess long time ago. When I heard
of *the French*, *Spanish*, *King's Indian* and so on, I made a little
mistake at first. But my father explained the correct notion. When I played
White 1.e4, that wasn't *me* who played *the French*, *I* played the king's
pawn. That’s it.
Black played 1.--e6 and only he as black made the decision to go into the
French. Then, after 2.d4 d5 I could decide between the *Forward Variation*
with 3. e5 or the normal 3. Nc3 or even the *Tarrasch* 3. Nd2. If I decided
to play Tarrasch, then Black couldn't have said *he played the Tarrasch*
because this was not his but my decision. And so on.
In literature of chess you'll certainly would find phrasings of that sort:
Korchnoi (as white) played some very strong King's Indians (with his g3).
But here again: Korchnoi only could show his strength AFTER Black's
decision for g6. Otherwise we could have seen Nimzo Indians or more
probably Korchnoi's famous Catalans.
When I read Jeff's article I remembered these very first steps of mine.
Assumptions (A) and Conclusions (C)
~~~~~~~~~~~~~~~~~~~~~~~~~
I don't understand what *a match between two programs* should *demonstrate*
(A1). This is more a philosophical question. I won't judge in neither
direction whatever the score may be. I want to know which one is *winning*.
Even with a clear 19-1 I wouldn't say *whoww the **19** program is or seems
to be clearly stronger or what else.* Score IS 19-1. Period.
Next time **19** looses against another program 8-12. Period. In SSDF they
do this over hundreds of games. At the end at a certain given date they
present the total sum of all wins and the percentage. I already wrote my
opinion that within a certain bigger range most programs of one class and
generation are almost of *the same* strength. To know more about more
precisely differentiations among progs of a certain class they should test
in that class. Maybe they won’t do that. But Bob Hyatt already confirmed
his doubts about the sense of the actual listings doing those sharp
differentiations. Bob used the notion class as well if I remember right.
Anyway the endscore should give an *idea of the general chess strength*
(A2) of a program based on lot of single match results. Notion *chess
strength* nevertheless needs more definition if we start to reflect on
definitions in my humble opininion.
Jeff is now saying that to know more about A2 he would like calculation
*based on a series of **unique** (A3) games*. And I understand this if we
are interested mainly in the chess content of games. Repetitions don’t
bring us *more* information. One could even say that if they show anything
they demonstrate a certain stupidiness of the looser.
Definition of a unique game is given indirectly. Jeff takes the extreme
case of several completly identical games of X vs Y. So only one of those
duplicates is taken into calculation and maybe 9 or 99 are deleted as
superfluous or without any further informational content.
Apart the question how to handle partial doubles (e.g. 30 or 50 moves
identical but then a bit different ending) this is impossible to do. Before
demonstrating this I take another thesis into consideration.
Thesis that a series of 10 identical games X vs Y (only) *really shows that
X is better at playing one particular line ...* (C1). Analysing this for
some time I can't accept it.
Apart the question if someone really wants to know reliable conclusions
about the chess strength of a program after 10 or 20 games against a single
other program. Assumed X played a strong and almost phantastically
beautiful line for white and wins against Y repeatedly -- only one example
of this line is worth to be counted (C2)?
But whatever bad the quality of the winner lines of Y -- they should be all
counted only because they are different ones?
This is simply a logical delusion. I would propose only to take the *best*
win. :) Why not? Sorry, I wanted to show where it ends if we start to take
philosophical notions under account in statistics.
Next point. Take (A2) -- X always wins with white (10-0), and Y does really
n o t h i n g?
Thinking of my preface, I cannot accept this. White plays a move and Black
answers. Then White makes his move again. Who dares to propose that only
White determins whats going on? If Black only changed one response we would
perhaps see the most beautiful game ever played. But no, Black always
reacts the same. And now who dares to *attack* White for NOT changing a
good line (which already brought him several wins!) and perhaps avoiding
loosing the game?
Finally (A3) is interesting but simply not logically to handle.
Each game on the contrary is unique by definition. Even a doubled or
tripled version. And considering chess it would be wrong to critizise White
for always following the same winning line if Black doesn't vary!
Kasparov and Karpov sometimes repeated 15 and more moves and only later the
game became a new one. This is called match psychology. They even tried to
copy the line which the other formerly used himself.
All depended on the situation where one side left the previously played
line. So repetition as such is not at all stupid!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Before going further I'd like to call for the *real* match score between X
and Y. Does X always have white? Never heard of such a match. Perhaps Y
with white does also produce some fine doubles? But X maybe produces
doubles with better chess content?
And finally I don't want to forget my thesis that all programs/machines are
determined. Why? Look at the result above. If X was really strong and
somewhat human he would certainly won the *match* much higher. He would
have found some more weaknesses in the more dull Y machine. No, seriously,
a machine who looses repeatedly in the same line till the end is somewhat
really stupid in my opinion.
If someone at this point suddenly exclaims *but this is human
argument/play, we're dealing with computerchess*, I would answer, well,
then please don't ask human questions like that of *the real chess
strength*.
My Conclusion
~~~~~~~~~~
Until further and deeper explanations done we should simply count scores
and show performance with percentages like on SSDF. If we start discussion
of valuable and worthless wins ---
we're lost in endless debates.
Anecdote
~~~~~~~
Germany would never have won the soccer European title this summer IF the
english player hadn't taken the statistically less successful *low* shot in
the 11 meter shoot-off. Some inches higher and Germany would have lost the
game.
And England had played the final and probably won the cup. But in the end
they simply calculated the goals. No organizer or politician did intervene
and *delete* this *stupid* shot. And so *we* won the semi-final and then
the final. On the base of a really *bad* shot killed by the german keeper.
BTW best soccer player of the world in that tournament was --- only by
looking at TV: --- a certain Rolf T. Simple case of overestimation
methinks. :)
Rolf Tueschen
Michael F. Byrne
crafty can access 5 man databases..it's a simple mod to the source..the
problem is that SJE's 5 man DB are not available yet..to my knowldege
Komputer Korner <kor...@netcom.ca> wrote in article
<32966C...@netcom.ca>...
mche...@aol.com
M-Chess Pro 6.0 will use 5-man tablebases whenever they are available.
It doesn't probe during searches except after captures at the root. There
is a big advantage but there are also cons (including some silly moves
played) to probing the tablebases during searches. Probing during search
can require a lot of reads and is slow with a CD. I intend to supply an
endgame CD or CD's which M-Chess Pro 6.0 will be able to use effectively.
-Marty
Kjell Tore Sandum
mche...@aol.com wrote:
>
> M-Chess Pro 6.0 will use 5-man tablebases whenever they are available.
>
> It doesn't probe during searches except after captures at the root.
In a position when several moves (of which at least one was winning) lead to a positive
evaluation, MCP6 choose an exchange that transposed (directly) to a drawn TB position. Is this a
bug? (If you want, I can mail you the position.)
> There
> is a big advantage but there are also cons (including some silly moves
> played) to probing the tablebases during searches. Probing during search
> can require a lot of reads and is slow with a CD. I intend to supply an
> endgame CD or CD's which M-Chess Pro 6.0 will be able to use effectively.
I look forward to get this CD(s). Do you know approx. when it will be available, and the price?
Sincerely
Kjell T.
Mark Rawlings
mche...@aol.com wrote:
>M-Chess Pro 6.0 will use 5-man tablebases whenever they are available.
>It doesn't probe during searches except after captures at the root. There
>is a big advantage but there are also cons (including some silly moves
>played) to probing the tablebases during searches. Probing during search
>can require a lot of reads and is slow with a CD. I intend to supply an
>endgame CD or CD's which M-Chess Pro 6.0 will be able to use effectively.
>-Marty
Which 5-man classes (if any) will there be on the CD?
Mark
mche...@aol.com
I expect to include one 5-man class: KRBKR.
>It doesn't probe during searches except after captures at the root.
There
>is a big advantage but there are also cons (including some silly moves
>played) to probing the tablebases during searches. Probing during search
>can require a lot of reads and is slow with a CD. I intend to supply an
>endgame CD or CD's which M-Chess Pro 6.0 will be able to use effectively.