Not logged inRybka Chess Community Forum
Up Topic Rybka Support & Discussion / Rybka Discussion / Problem with Rybka 2.3.2a accessing 6 piece tablebase.
- - By PhilomathBret (**) [us] Date 2008-05-02 06:53
I downloaded a the 6 piece tablebase with 2 pawns vs. 2 pawns and Rybka accesses it just fine when that is how many pieces are actually on the board. When I go to the position 2-3 moves before it gets down to that, the engine seems to be accessing the tablebase fine and it says that the position is a draw (which it is). Then if I go to the position 1 move before. It thinks one side is winning by about 3.5, even though it gives the main line as something that will go into the draw in 1 move (2 ply). My guess is that there are other positions like this in which Rybka's engine doesn't accurately use the tablebase for its evalutation. I hope this gets fixed for Rybka 3.
Parent - - By Permanent Brain (*****) Date 2008-05-02 08:57
If it's 3 or 4 (half-)moves before tablebase material can arise, then it is certainly an "issue" which needs to be looked at. But there will always be a distance where the gain from tablebases will decrease, or where they will not help at all yet, because tbs. material is just too far away.

You could try though, if the problem you found (in that specific positions) is affected by the NalimovUsage engine setting. Maybe it goes away if you adjust it from rarely to normally or frequently. Although, it may be that in other cases or in general, this could decrease the endgame performance. That certainly depends on your system and configuration detail, for example if you have the Nalimovs on a storage device with fast access(!) times.

Another consideration is if your position is a rare exception, or someting related to knowledge which was removed after Rybka 2.2. If you have Rybka 2.2 too, I suggest to try this version too, for comparison. In a number of positions which were posted, where 2.3.2a had problems, I got good results from 2.2. But my tests are not related to 6-piece tbs. because I don't use them and not even all 5-piece tbs.
Parent - - By PhilomathBret (**) [us] Date 2008-05-02 11:26
I don't think I was totally clear about what I said. I was talking about one particular endgame position that the tablebase says is a draw. When I go 3-4 moves before this position, the engine says it's a draw. Then when I get closer to the position (1 move before), it's saying that it's a clear win for one side, even though the main line of the engine's analysis is what leads to the tablebase draw in 1 move.

I changed the NalimovUsage setting from rarely to frequently and that fixed the problem. Thank you! Why would that decrease the endgame performance to use the Nalimov tablebase more frequently? And could it decrease performance in other areas of the game?
Parent - - By Nelson Hernandez (Gold) [us] Date 2008-05-02 13:45
You could help us by posting the FEN. 
Parent - - By PhilomathBret (**) [us] Date 2008-05-02 20:35
What is that?
Parent - By Nelson Hernandez (Gold) [us] Date 2008-05-02 23:17
http://en.wikipedia.org/wiki/Forsyth-Edwards_Notation

In the board position the Brain posted below, notice the code immediately on top of the diagram.
Parent - By Uly (Gold) [mx] Date 2008-05-03 01:43

> What is that?


Try finding something similar to "Copy FEN" or "Copy Position" on the "Edit" or "File" menu of your interface.
Parent - - By Roland Rösler (****) [de] Date 2008-05-03 01:58

>>You could help us by posting the FEN. 
>What is that?


I think, this is the post of the month!
PS: Maybe we shall have a poll about the best post of the month (or quarter).
Parent - - By turbojuice1122 (Gold) [us] Date 2008-05-03 04:25
Well, of the year so far, my nomination would go to this one, where Alan parodies Nelson's remark imagining playing against a chimpanzee.
Parent - - By Roland Rösler (****) [de] Date 2008-05-03 04:55
Alan is good in responding Nelsons posts. I have seen this. What I think about philosophy you can read here and have a look to the next posts.
Parent - - By BB (****) [au] Date 2008-05-03 05:11

>I honestly don't know which philosophers have done more harm, the French or the Germans.


I'd say the French were more harmful at philosophy, but possibly only because the Germans found that psychology was a superior field for spreading damage. :-P But then again, one could argue that the French [particularly Clemenceau] scored their greatest coup against the Germans via the unnatural preservation of the Bismarckian Reich during the Peace to End All Peace at Versailles.
Parent - - By Roland Rösler (****) [de] Date 2008-05-03 06:05
After I have read the smallest book I have ever read, I was sure, that philosophy is only bullshit. Okay I saw also German tv, where the author makes his comments. It was great! Gunnar Heinsohn and his book "Söhne und Weltmacht" is better than any philosophy. Maybe, it´s only another story of interpreting history. But I don´t think so. Philosophy don´t count, when you can (have to make!) make benefit. This is old, but it is interesting, when you have a look to the real reasons.
Parent - By BB (****) [au] Date 2008-05-03 06:17 Edited 2008-05-03 06:23

>Okay I saw also German tv, where the author makes his comments


Again the French were ahead of you --- the French TV-viewing public were receiving Sartre via Lectures pour tous already in the 50s. :-P
Parent - By Permanent Brain (*****) Date 2008-05-02 16:51 Edited 2008-05-02 17:18

> Why would that decrease the endgame performance to use the Nalimov tablebase more frequently?


I think it depends a lot on the individual system configuration. As you have seen, the default is "rarely" (it was "normally" in 2.2). The problem is the access time which is required, each time the engine looks up a tablebase position in the Nalimov files. This can cause a slowdown effect. This effect will of course be the bigger, the more tbs. lookups are done, per second. At the same time, the perfect information of course helps. So, it is always a tradeoff.

The slowdown is most noticable when the tbs. are accessed for the first time (per session), and will be smaller later because some data can be retrieved from caches, instead of having to access the storage device.

The number of such accesses can vary, up to many thousands per minute. Examples with setting "normally", D945 3.4 GHz:

8/5k2/3r1p2/2N3b1/3P4/8/3RK3/8 w - - 0 1


Analysis by Rybka 2.3.2a 32-bit :

1.Rd1 f5 2.Kd3 Bf6 3.Kc4 Bxd4 4.Rxd4 Rxd4+ 5.Kxd4 f4
  =  (-0.01)   Depth: 5   00:00:00
  =  (0.00)   Depth: 21   00:01:37  4623kN, tb=3423 <-- that means ~35 tbs. accesses per second

8/8/3pp3/3p1k2/3P1P2/4PK2/8/8 w - - 0 1


Analysis by Rybka 2.3.2a 32-bit :

1.Ke2 Ke4 2.Kd2
  =  (0.22)   Depth: 5   00:00:00
  =  (0.01)   Depth: 6   00:00:00  0kN
1.Kf2 Ke4 2.Ke2 Kf5 3.Kd3 e5 4.fxe5 dxe5 5.dxe5 Kxe5
  =  (0.05)   Depth: 6   00:00:00  0kN
  =  (0.00)   Depth: 38   00:00:46  4817kN, tb=39970 --> 869/sec. (!)

The slowdown effect (in principle) should be minimized, as good as possible, by configuration. Recommendable is to use a fast storage device, like flash memory (USB memory stick or -card), or a solid state disk. Important is the access time, not the transfer rate, because small parts of data need to be read very often. Normal USB sticks will not have enough space for 6-piece tbs., but on an 8 GB stick you can put all 3/4/5-pieces files.

I use a 1 GB stick only, because I do not use all 5-piece tbs. but only a smaller subset with important files (rook vs. rook), as a compromise which I think is another idea to reduce the slowdown effect. I think there are many 5-piece endings which do not require tablebases, i.e. QB-N or the like, where "the case is clear." Since I do not need absolute high performance, I like to use the normally or even frequently settings, for endgame analyses with this configuration.

Another part of the related configuration is the tablebase cache. Here, tbs. data is buffered in it's uncompessed form, while the normal file caches contain compressed data because the Nalimov files are compressed. Various tests couldn't lead to a clear conclusion though, if the tablebase cache size has a significant impact on the tbs. performance or not. Some think it has none. Since I have more than enough RAM anyway, I set it to 128 MB. Even if it's almost useless, I think it cannot harm. But in case of shortage of RAM, the hash tables should have priority.

All this considerations apply of course only to endgame positions where the engine begins to access the tablebases, during the search.
Parent - - By Vasik Rajlich (Silver) [hu] Date 2008-05-03 16:26
There are a bunch of little bugs in the tablebase access of Rybka 2.3.2a. We'll try to have this as clean as possible in Rybka 3. In most cases, Rybka 2.3.2a works ok.

Vas
Parent - - By PhilomathBret (**) [us] Date 2008-05-05 09:59
I found another one. It seems that it commonly will see a tablebase position in its main line yet not use this in its evaluation.

An idea for the Rybka 3 GUI: instead of just showing 0.00, it could have some indication of what kind of 0.00 it is. When I see 0.00, I don't always know if it's a tablebase draw, a simple repetition of moves, or just an equal position with a lot of play left in it.

Can somebody update me on what's happening with the potential Nakamura-Rybka match?
Parent - By Vasik Rajlich (Silver) [hu] Date 2008-05-05 21:37

> An idea for the Rybka 3 GUI: instead of just showing 0.00, it could have some indication of what kind of 0.00 it is. When I see 0.00, I don't always know if it's a tablebase draw, a simple repetition of moves, or just an equal position with a lot of play left in it.


This will require changes to UCI. Things like this are for Rybka 4 and beyond.

> Can somebody update me on what's happening with the potential Nakamura-Rybka match?


AFAIK Larry is working on it.

Vas
Up Topic Rybka Support & Discussion / Rybka Discussion / Problem with Rybka 2.3.2a accessing 6 piece tablebase.

Powered by mwForum 2.27.4 © 1999-2012 Markus Wichitill