Are Table Bases (always) useful?

[Reinhard Scharnagl]

Hi all,

look at the following perft results:

Code: Select all

FEN: 8/5k2/8/8/2K5/4Q3/8/8 w - - 0 1

  +-a--b--c--d--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |   :::   :::   :::   :::|
7 |:::   :::   :::[k]:::   | Perft Testseries
6 |   :::   :::   :::   :::|
5 |:::   :::   :::   :::   | (With TT Caching 320 MB / 4-fold)
4 |   :::<K>:::   :::   :::|
3 |:::   :::   <Q>   :::   | Smirf Test No.: 00
2 |   :::   :::   :::   :::|
1 |:::   :::   :::   :::   | Break Time 5.0 Sec.
=>+-a--b--c--d--e--f--g--h-+

Ply             Nodes            all (x)            all (+)   Seconds
---------------------------------------------------------------------
01                 33                  0                  7         0
02                173                  3                  0         0
03               5042                  0               1215         0
04              22746                328                  0         0
05             653784                  0             152570         0
06            2949918              41335                  0         0
07           83616918                  0           19402739       0.1
08          377134125            5205065                  0       0.2
09        10623743085                  0         2467938042       0.3
10        48383310341          660368363                  0       0.7
11      1357784458184                  0       316361710265       0.9
12      6198416521509        84689075813                  0       1.7
13    173535414872275                  0     40622522233372       2.1
14    794178737519964     10894390353653                  0       3.3
15  22196633484287873                  0   5220640106354434      21.8
---------------------------------------------------------------------


It lasts until ply 15 until the transposition table would be relevantly filled, thus a timing "explosion" happens then. But if you think it over, the TT seems to be filled with an uncut tree. If you suppose a simple alpha beta search would happen, this would represent about 28 plys. With some kind of additional move filtering you would be able to mirror the whole relevant tree within a TT even when it would last for 100 half moves.

My conclusion is, that there is no need for table bases with less than 5 pieces. The benefit of using such tables there could only be marginal.

Regards, Reinhard.

[Uri Blass]

Hi Reinhard,

I think that there is no need for tablebases in KQ vs K.

You only need your evaluation function to return win or draw and it is not hard to do it.

Tablebases may have advantage in more complicated positions like KR vs KN espacially when the relevant positions happen near the leaf position of the tree and you need to evaluate them.

I know from experience that even commercial programs without tablebases cannot solve KR vs KN by normal alpha beta search.

Maybe they do something wrong(in the case of movei I even did not test it because movei still does not use hash for pruning and it use it only for better order of moves).

Here is Yace analysis of KR vs KN position without tablebases
It has no idea if white wins or if it is a draw(yace is relatively good here and search slightly deeper than Fritz based on nominal depth(Fritz has depth 22 after 3 minutes of search with no conclusion).

White king h1 Rook c6
black king f1 knight a8

512 mbytes hash

New game,
n7/8/2R5/8/8/8/8/5k1K w - - 0 1

Analysis by Yace 0.99.87:

1.Rf6+ Ke2
? (0.48) Depth: 1 00:00:00
1.Re6
? (0.51) Depth: 1 00:00:00
1.Re6
? (0.51) Depth: 1 00:00:00
1.Re6 Nc7
? (0.48) Depth: 2 00:00:00
1.Rf6+ Ke2 2.Kh2
? (0.49) Depth: 2 00:00:00
1.Rf6+ Ke2 2.Kh2
? (0.49) Depth: 2 00:00:00
1.Kh2 Kf2 2.Rf6+ Ke3 3.Re6+ Kd4 4.Kg3
? (0.50) Depth: 2 00:00:00
1.Kh2 Kf2 2.Rf6+ Ke3 3.Re6+ Kd4 4.Kg3
? (0.50) Depth: 2 00:00:00
1.Kh2 Kf2 2.Rf6+ Ke3 3.Re6+ Kd4 4.Kg3
? (0.50) Depth: 2 00:00:00
1.Kh2 Kf2 2.Rf6+ Ke3 3.Re6+ Kd4 4.Kg3
? (0.50) Depth: 3 00:00:00
1.Kh2 Kf2 2.Rf6+ Ke3 3.Re6+ Kd4 4.Kg3
? (0.50) Depth: 3 00:00:00
1.Kh2 Kf2 2.Rf6+ Ke3 3.Re6+ Kd4 4.Kg3
? (0.50) Depth: 4 00:00:00
1.Kh2 Kf2 2.Rf6+ Ke3 3.Re6+ Kd4 4.Kg3
? (0.50) Depth: 4 00:00:00
1.Kh2 Kf2 2.Rf6+ Ke3 3.Re6+ Kd4 4.Kg3
? (0.50) Depth: 5 00:00:00
1.Kh2 Kf2 2.Rf6+ Ke3 3.Re6+ Kd4 4.Kg3
? (0.50) Depth: 5 00:00:00
1.Kh2 Kf2 2.Kh3 Kf3 3.Rf6+ Ke4 4.Kg4
? (0.51) Depth: 6/8 00:00:00 3kN
1.Kh2 Kf2 2.Kh3 Kf3 3.Rf6+ Ke4 4.Kg4
? (0.51) Depth: 6/13 00:00:00 10kN
1.Kh2 Kf2 2.Kh3 Kf3 3.Rf6+ Ke4 4.Re6+ Kd5 5.Re7
? (0.50) Depth: 7/13 00:00:01 13kN
1.Kh2 Kf2 2.Kh3 Kf3 3.Rf6+ Ke4 4.Re6+ Kd5 5.Re7
? (0.50) Depth: 7/14 00:00:01 30kN
1.Kh2 Kf2 2.Kh3 Kf3 3.Kh4 Ke4 4.Re6+ Kd5 5.Re7
? (0.50) Depth: 8/14 00:00:01 40kN
1.Kh2 Kf2 2.Kh3 Kf3 3.Kh4 Ke4 4.Re6+ Kd5 5.Re7
? (0.50) Depth: 8/17 00:00:01 73kN
1.Kh2 Kf2 2.Kh3 Kf3 3.Kh4 Ke4 4.Rd6 Nc7 5.Kg5
? (0.49) Depth: 9/17 00:00:01 100kN
1.Kh2 Kf2 2.Kh3 Kf3 3.Kh4 Ke4 4.Rd6 Nc7 5.Kg5
? (0.49) Depth: 9/17 00:00:01 169kN
1.Kh2 Kf2 2.Kh3 Kf3 3.Kh4 Ke4 4.Re6+ Kd5 5.Re7 Nb6 6.Kg4
? (0.49) Depth: 10/18 00:00:01 215kN
1.Kh2 Kf2 2.Kh3 Kf3 3.Kh4 Ke4 4.Re6+ Kd5 5.Re7 Nb6 6.Kg4
? (0.49) Depth: 10/20 00:00:01 343kN
1.Kh2 Kf2 2.Kh3 Kf3 3.Kh4 Kf4 4.Rc4+ Ke5 5.Rc2 Nb6 6.Re2+ Kd4 7.Kg5
? (0.49) Depth: 11/20 00:00:02 433kN
1.Kh2 Kf2 2.Kh3 Kf3 3.Kh4 Kf4 4.Rc4+ Ke5 5.Rc2 Nb6 6.Re2+ Kd4 7.Kg5
? (0.49) Depth: 11/22 00:00:02 665kN
1.Kh2 Kf2 2.Kh3 Kf3 3.Kh4 Kf4 4.Kh5 Kf5 5.Rc3 Nb6 6.Rf3+ Ke4 7.Kg4
? (0.49) Depth: 12/22 00:00:02 843kN
1.Rc2 Nb6 2.Kh2 Nd5 3.Kg3 Ne3 4.Rf2+ Ke1 5.Kf3 Nc4 6.Rc2 Nd6 7.Re2+ Kd1
? (0.50) Depth: 12/22 00:00:02 1021kN
1.Rc2 Nb6 2.Kh2
? (0.50) Depth: 12/22 00:00:02 1054kN
1.Rc2 Nb6 2.Kh2
? (0.50) Depth: 12/24 00:00:02 1178kN
1.Rc2 Nb6 2.Kh2 Nd5 3.Kg3 Ne3 4.Rf2+ Ke1 5.Kf3 Nd5 6.Re2+ Kd1 7.Re5 Nc3 8.Ke3
? (0.50) Depth: 13/24 00:00:02 1333kN
1.Rc2 Nb6 2.Kh2 Nd5 3.Kg3 Ne3 4.Rf2+ Ke1 5.Kf3 Nd5 6.Re2+ Kd1 7.Re5 Nc3 8.Ke3
? (0.50) Depth: 13/24 00:00:02 2026kN
1.Rc2 Nb6 2.Kh2 Nd5 3.Kg3 Ne3 4.Rc6 Ke2 5.Kf4 Kf2 6.Re6 Nc4 7.Re4 Nd6
? (0.51) Depth: 14/24 00:00:02 2257kN
1.Rc2 Nb6 2.Kh2 Nd5 3.Kg3 Ne3 4.Rc6 Ke2 5.Kf4 Kf2 6.Re6 Nc4 7.Re4 Nd6
? (0.51) Depth: 14/26 00:00:03 3104kN
1.Rc2 Nb6 2.Kh2 Nd5 3.Kg3 Ne3 4.Rc6 Ke2 5.Kf4 Nd5+ 6.Ke4 Ne3 7.Rc3 Ng4
? (0.51) Depth: 15/26 00:00:03 3566kN
1.Rc2 Nb6 2.Kh2 Nd5 3.Kg3 Ne3 4.Rc6 Ke2 5.Kf4 Nd5+ 6.Ke4 Ne3 7.Rc3 Ng4
? (0.51) Depth: 15/28 00:00:04 5145kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Kd1 4.Rc6 Na4
? (0.51) Depth: 16/28 00:00:04 6358kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Kd1 4.Rc6 Na4
? (0.51) Depth: 16/29 00:00:04 9060kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Kd1 4.Rc6 Na4 5.Kf4 Kd2 6.Rd6+ Ke2 7.Rd8 Nc5 8.Rc8 Nb3
? (0.51) Depth: 17/29 00:00:05 11012kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Kd1 4.Rc6 Na4 5.Kf4 Kd2 6.Rd6+ Ke2 7.Rd8 Nc5 8.Rc8 Nb3
? (0.51) Depth: 17/30 00:00:06 15134kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Kd1 4.Rc6 Na4 5.Kf3 Kd2 6.Ra6 Nc5 7.Rd6+ Kc3 8.Ke3
? (0.52) Depth: 18/30 00:00:07 16913kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Kd1 4.Rc6 Na4 5.Kf3 Kd2 6.Ra6 Nc5 7.Rd6+ Kc3 8.Ke3
? (0.52) Depth: 18/30 00:00:09 20601kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg2 Kd1 4.Rf2
? (0.53) Depth: 19/30 00:00:10 24199kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg2 Kd1 4.Rf2
? (0.53) Depth: 19/32 00:00:12 29256kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg2 Kd1 4.Rf2 Nc4 5.Kf3 Na3 6.Ke4 Nc2 7.Ke5
? (0.53) Depth: 20/34 00:00:16 39015kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg2 Kd1 4.Rf2 Nc4 5.Kf3 Na3 6.Ke4 Nc2 7.Ke5
? (0.53) Depth: 20/34 00:00:21 50626kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg2 Kd1 4.Rf2 Nc4 5.Kf3 Na3 6.Ke3 Nc2+ 7.Ke4
? (0.53) Depth: 21/34 00:00:28 68376kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg2 Kd1 4.Rf2 Nc4 5.Kf3 Na3 6.Ke3 Nc2+ 7.Ke4
? (0.53) Depth: 21/34 00:00:35 84628kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Kd1 4.Rf2
? (0.54) Depth: 22/34 00:00:44 106780kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Kd1 4.Rf2
? (0.54) Depth: 22/36 00:00:51 123586kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Kd1 4.Rf2 Nd5 5.Kf3 Nb4 6.Ke3 Nc2+ 7.Kd3 Nb4+ 8.Ke3
? (0.54) Depth: 23/37 00:01:10 170197kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Kd1 4.Rf2 Nd5 5.Kf3 Nb4 6.Ke3 Nc2+ 7.Kd3 Nb4+ 8.Ke3
? (0.54) Depth: 23/39 00:01:25 206886kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Nd5 4.Kf3 Nb4 5.Rh2 Kd1
? (0.54) Depth: 24/39 00:01:50 267093kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Nd5 4.Kf3 Nb4 5.Rh2 Kd1
? (0.54) Depth: 24/40 00:02:12 316499kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Nd5 4.Kf3 Nb4 5.Rh2 Kd1 6.Ke3 Nc2+ 7.Kd3 Nb4+ 8.Kc3 Nd5+ 9.Kc4 Ne3+ 10.Kd3 Nf1 11.Rf2 Ke1 12.Rf4 Nh2 13.Rh4 Nf3 14.Rh5 Kf2 15.Ke4 Ke2 16.Rf5 Nh2
? (0.55) Depth: 25/42 00:02:42 385785kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Nd5 4.Kf3 Nb4 5.Rh2 Kd1 6.Ke3 Nc2+ 7.Kd3 Nb4+ 8.Kc3 Nd5+ 9.Kc4 Ne3+ 10.Kd3 Nf1 11.Rf2 Ke1 12.Rf4 Nh2 13.Rh4 Nf3 14.Rh5 Kf2 15.Ke4 Ke2 16.Rf5 Nh2
? (0.55) Depth: 25/42 00:02:53 412790kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Kd1 4.Rc6 Na4 5.Rc4 Nb2 6.Rc5 Nd3 7.Rc3 Ke2 8.Rc2+ Ke3 9.Kg4
? (0.54) Depth: 26/42 00:04:38 661261kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Kd1 4.Rc6 Na4 5.Rc4 Nb2 6.Rc5 Nd3 7.Rc3 Ke2 8.Rc2+ Ke3 9.Kg4
? (0.54) Depth: 26/43 00:05:14 744281kN
1.Rc2 Nb6 2.Kh2 Ke1 3.Kg3 Kd1 4.Rc6 Na4 5.Kf3 Kd2 6.Rc4 Nc3 7.Rd4+ Kc2 8.Rb4
? (0.54) Depth: 27/43 00:06:27 918351kN

(, MyTown 18.10.2004)

[Reinhard Scharnagl]

Hi Uri,

I think that there is no need for tablebases in KQ vs K.

of course. I have used this example to show, that the search tree is not that big. The example KR / KN seems to be an interesting drosophila to find out, whether there are positional ideas in detail evalution, which would justify to call it positional. Smirf has not gone that far yet. But I am still working on it.

Regards, Reinhard.

[Laurens Winkelhagen]

One, I feel, often overlooked benefit from EGTB is that when you have 6 pieces on the board the 5pc. EGTB's immediately give a score for all the cases in which one of the pieces is slain. IMHO this is the main benefit for EGTB's.

OTOH, as a famous modern-time dutch philosopher always says: Every advantage has its drawback. The following scenario has happened to my engine JanWillem several times:

(please note that I do not use timeseal for FICS)
JanWillem is short on time, but winning on FICS. In fact, while his opponent only has a king, JanWillem also has a queen and a couple of pawns. Seeing that the end game is won with just the pawns, JanWillem offers his queen, promotes his pawn and... loses (draws I should say) on time!!!

Greetings, Laurens.

[Reinhard Scharnagl]

Hi Laurens,

obviously integrating huge look up tables like opening libraries and EGTBs will be good for analysing a situation.

But (I have not been clear in that point) the PROCEEDING of chess program DEVELOPMENT might come to a standstill. New ideas in evaluating positions during the opening or endgame phase cannot compete, because then such algorithms either simply would be switched off, or the opponent's engine is overplaying because of its huge looking up tables.

Thus my proposal: http://www.chessbox.de/Compu/schachfair_e.html

Reinhard.

[Laurens Winkelhagen]

Hi Reinhard,

I think I may have misunderstood the intentions of your post there.

I wholehearthedly agree with the sentiment that computer chess is losing much of its AI-charm due to huge EGTB's and openingbooks. Especially since I'm a AI-student my self. Why-oh-why do programs that hint of intelligence (e.g. chessterfield, cpp1) underpreform the calculators.

However, my intentions when designing janwillem were not so lofty as to build a true AI-engine, but rather an engine which would be able to beat me . This state of mind obviously makes me read threads like this with the possible benefit of techniques (e.g. EGTB lookup) in mind, rather than the philosophical fairness.

- Laurens.
Maybe one day I'll design an engine driven by pattern recognition rather than pc-sq evaluation (most of JanWillems eval-function)... which in my humble opinion is the main difference between humans and computers.

[Uri Blass]

You do not need tablebases in order to design an engine that can beat you.

Tablebases give very little elo relative to better chess algorithm.

Uri

[Laurens Winkelhagen]

Hi Uri,

I know that now;-).



Let me elaborate a bit. There I was,.. I had dusted off my old hobby and had made a chess engine. It played reasonable chess, but I could beat it. just hope for a blunder or trade queens+rooks fast. I had read something about end game table bases, so....

I probably should have focussed on getting the blunder bugs out of the program in stead of implementing the tablebases. Also my engine is notably weak in endgames with pawns and at the time I felt that implementing EGTB's (including locating and contacting nalimov and kadatch) was the lesser job then modifying my evaluation function to make my king go where it's needed most in the endgame. getting the blunderbugs out seemed especially horrid to me.

Of course, now JanWillem still loses a lot of games due to his bad end-game handling, but I feel that the EGTB have improved play more than marginally in his case.

Also, I would like to point out that, even though I'm not a particularly good chess player, I can still make things difficult for JanWillem. Every added elo-point is welcome.

Finally, while the original goal with JanWillem was to make an engine that could/would beat me, this goal has shifted. I now like to improve my engine so that it can see it beat other engines. I have discovered myself to be competative in this respect. The ultimate goal is to produce the best chess engine in the world, but not even in my wildest dream do I see that happen. A more realistic goal is getting out of the lowest division of WBEC-ridderkerk. And to make that happen, well, let's just say that every elo-point is indeed welcome!


-Laurens

[Dann Corbit]

There have been many careful experiments. Every experiment I have seen shows the following:
1. Tablebase files do not increase ELO. The cost of probing is about equal to the gain of knowledge. These tests were done with advanced engines, so perhaps for simple engines it is different.
2. Bitbase files do increase ELO. Probably, because they are much smaller and therefore can be memory resident. Hence, won/loss/drawn can be obtained in a single probe.

The best thing about tablebases is that they can result in perfect play.

I think it is not wise to write special code to solve simple endgames, since the 3 and 4 man tablebase files are very small. The three man files can easily be memory resident.

Hence, effort can be spent on other parts of the evaluation.

Some ideas that are general would be good (e.g. sliders like rooks and queens should be used to push an opposing king to an edge). That idea is good when there are few pieces on the board and will prevent stupid draws. But other than that, I think special algorithms for solving those endings are not a wise use of time.

[Uri Blass]

Hi Dan,I do not use tablebases but I disagree about your claim that
"1. Tablebase files do not increase ELO. The cost of probing is about equal to the gain of knowledge."

The cost of probing is dependent on your decision when to probe.

If you probe only when the remaining depth is big enough then there is practically no cost for probing when they can help even if you decide to use them only at the root.

Uri

[José Carlos]

Hi all. IMO, perfect knowledge is always work using. Even if it's slow to get it, because as Uri says, you can choose to use it only in certain cases. If you're very selective here, you must be careful of being coherent. For example, the program could choose a long KBBKN mate instead of a simple KQK and then find it's a draw by the 50 moves rule.
Perfect knowledge is always useful. It's up to you to use it correctly.

[Reinhard Scharnagl]

Hi all,

suppose, chess would be a completly solved game. Would it then be useless to write chess programs? No at all! The task is, to find good moves under RESTRICTED conditions. Looking up huge tables is not a very intelligent task, but making right decisions under limited information really is.

Reinhard.

[Sune Fischer]

Hi Uri,

I do not use tablebases but I disagree about your claim that
"1. Tablebase files do not increase ELO. The cost of probing is about equal to the gain of knowledge."

The cost of probing is dependent on your decision when to probe.

If you probe only when the remaining depth is big enough then there is practically no cost for probing when they can help even if you decide to use them only at the root.

You have a point with the above, at least at the root there should a positive trade off.

One thing that gets overlooked in all of this is perhaps that the tables consume a lot of memory for cache and indices.

Assuming the engine is limited to e.g. 60 MB memory, it is questionable if configuration A={25 MB tables + 35 MB hash} is better than B={no tabes + 60 MB hash}.

That said, EGTBs might save some time in tournaments, there should be less shuffling in many endgames.

-S.

[José Carlos]

Hi all,

suppose, chess would be a completly solved game. Would it then be useless to write chess programs? No at all! The task is, to find good moves under RESTRICTED conditions. Looking up huge tables is not a very intelligent task, but making right decisions under limited information really is.

Reinhard.

Hi Reinhard.
I partially disagree.
If chess was solved, writting chess programs would be useless regarding to competition, but not to have fun (I've written programs for solved games, and I enjoy playing them).
When you say restricted conditions, you're right. Tecnology restricts our possibilities. That's first restriction and do the best you can with current tecnology is a good category that implies play the best chess that can be played. Then, another interesting a fair category es defined by do the best you can with a computer every user can afford. This is good for the people who buys chess programs. Any other category that you can invent will be no better (and certainly no worse) than the two mentioned. You can limit size of the footprint of the program in memory. I can limit number eval terms that can be evaluated and other people can stablish different limitations. I can't see why one is better than the others, unless for the two formerly mentioned, which have additional merits IMO.
If you really want to use limited information, it might be an interesting test to eliminate evaluation function, or use only material. Let the search decide if a pawn is really weak and can be taken at all.

[Uri Blass]

Hi all,

suppose, chess would be a completly solved game. Would it then be useless to write chess programs? No at all! The task is, to find good moves under RESTRICTED conditions. Looking up huge tables is not a very intelligent task, but making right decisions under limited information really is.

Reinhard.

Hi Reinhard,

The problem is that in this case it may be the end of selling the strongest engine because customers may prefer to buy some program that use huge tables and not to buy some program that is better under restricted conditions.

Programmer will need to focus on other things than improving the strengrth in order to sell their chess program.

[Uri Blass]

Hi all,

suppose, chess would be a completly solved game. Would it then be useless to write chess programs? No at all! The task is, to find good moves under RESTRICTED conditions. Looking up huge tables is not a very intelligent task, but making right decisions under limited information really is.

Reinhard.

Hi Reinhard.
I partially disagree.
If chess was solved, writting chess programs would be useless regarding to competition, but not to have fun (I've written programs for solved games, and I enjoy playing them).
When you say restricted conditions, you're right. Tecnology restricts our possibilities. That's first restriction and do the best you can with current tecnology is a good category that implies play the best chess that can be played. Then, another interesting a fair category es defined by do the best you can with a computer every user can afford. This is good for the people who buys chess programs. Any other category that you can invent will be no better (and certainly no worse) than the two mentioned. You can limit size of the footprint of the program in memory. I can limit number eval terms that can be evaluated and other people can stablish different limitations. I can't see why one is better than the others, unless for the two formerly mentioned, which have additional merits IMO.
If you really want to use limited information, it might be an interesting test to eliminate evaluation function, or use only material. Let the search decide if a pawn is really weak and can be taken at all.

I disagree about the idea of other limitations.
With other limitations the competition is not clear.
You can easily find the size of the program but not what it evaluates.

Even if your evaluation is only material
You can evaluate indirectly other things by better order of moves when you prefer moves that improve the piece square table.

[José Carlos]

I disagree about the idea of other limitations.
With other limitations the competition is not clear.
You can easily find the size of the program but not what it evaluates.

Even if your evaluation is only material
You can evaluate indirectly other things by better order of moves when you prefer moves that improve the piece square table.

You can fake the size of the program if you want. You can run some other hidden program, let it create some big tables in memory and pass a pointer to your program to use them.
You can fake almost everything, in fact.
I was talking about fair competition. Other possible limitations: no book (let the programs create opening moves and make sure they have some randomness to avoid repeated games), no hash tables (programmers might try graph algorithms instead of tree algorithms?), no null move (competition to find new pruning methods), no alpha-beta (how will you then search the tree efficiently?), no extensions (you'll need a better eval of dynamic elements), ...

[Reinhard Scharnagl]

Hi Jos?,

some month's ago I decided for myself that the SIZE would be the ONLY to be verified property of a program, which should to be checked. And the program finally has to be run on a neutral PC.

Reinhard.

[Anonymous]

Hi Uri,

One thing that gets overlooked in all of this is perhaps that the tables consume a lot of memory for cache and indices.

Assuming the engine is limited to e.g. 60 MB memory, it is questionable if configuration A={25 MB tables + 35 MB hash} is better than B={no tabes + 60 MB hash}.

Formally, they use a lot of memory, practically not (or not necessarily). For example, there is no need for a big cache, if you only probe at root. If you decompress the tables, there is no need for the decompression indices. They could be used from disk (but the Nalimov code doesn't), too. Of those memory consuming decompression indices only a small part will be used, anyway. If only probing at root is done, a neglible small part. The OS can swap out them totally (and will do so, in a tight memory situation). So, in essence, the main resource they use, and that cannot be avoided, is disk space (which could be on a remote machine).

Regards,
Dieter

[Sune Fischer]

Hi Dieter,

I actually don't do any of what you suggest, but I'm aware of the possibilities.

I think the tables take up too much disk space as it is, so I'll keep them compressed. I also probe them during search. I don't think they are much use just at the root, it's going to be pure luck then if the engine ends up in a won TB position.
About the OS swapping them out, that's fine as long as they aren't needed but what happens when suddenly they are needed...

I still maintain that it's not completely clear if the TBs are worth it if the engine is limited to a (small) total amount of memory.
Most of the tournaments grant additional memory for the TBs, and even in this case they seem to have an almost neglible impact.

I hope Eugene will make some memory efficient 5-6 man bitbases at one point, perhaps after the 6-man set is complete?

-S.