Problem: bitbase access by Scorpio versions... Dan Shawul?

[ernest]

Maybe Dan or somebody else can help...

With Scorpio 2.0 (date: end 2007 ), I have no problem in 5-man bitbase access, even with the new (Dann Corbit compressed - 223 MB) bitbases and the v3.3 egbbdll. My test is mostly in 32-bit.

I wanted to test with the more recent Scorpio 2.7 version.
I use the Fritz 11 and Shredder GUIs.

Since Scorpio is Winboard, you have to use Wb2uci and Wb2Uci.eng
The Scorpio configuration file, scorpio.ini defines the
#path to egbb
egbb_path C:\egbb\

Note that if you skip the last \ , the path is not recognized!

I shut off all access to Nalimov GUI access and used the 5-man position
8/8/8/8/5kp1/P7/8/1K1N4 w - - 0 1 ; bm Kb1-c2; dm50
(only solution Kc2, never found without tables or bitbases)

Well, with version 2.7 of Scorpio (the latest), and for that matter any version later than 2.0:
_ on infinite analysis, no output, depth stays at 1
_ on "compute", I get the immediate move (correct move, "depth 1" eval?)
Analysis by Scorpio 2.7:
1.Kc2
= (0.00) Depth: 1 00:00:00

as compared to the correct

Code: Select all

Analysis by Scorpio 2.0:
1.Kc2 Ke5 2.Kd3 g3 
  +-  (48.44)   Depth: 6   00:00:00  1kN
1.Kc2 Ke5 2.Kd3 g3 
  +-  (48.44)   Depth: 6   00:00:00  1kN
1.Kc2 Ke5 2.Kd3 g3 
  +-  (48.44)   Depth: 7   00:00:00  1kN
1.Kc2 Ke5 2.Kd3 g3 
  +-  (48.44)   Depth: 7   00:00:00  1kN
1.Kc2 Ke5 2.Kd3 g3 
  +-  (48.44)   Depth: 8   00:00:00  2kN
1.Kc2 Ke5 2.Kd3 g3 
  +-  (48.44)   Depth: 8   00:00:00  3kN
..............

Looking at logs, I find that there is access to the egbb, but immediately followed by stop and exit.

Also note that when in scorpio.ini I put
#egbb_load_type 3
(meaning loading all 5 men in memory), my Task Manager does not show 200 MB more used in memory, and access is still from disk...

[Daniel Shawul]

Hmm Scorpio seems to give you a bit of a headache there. I have countless number of reports with this kind of problem. The most probable cause for egbb problems is non-compatible version of the probling dll with egbbs used. When you download the egbbs use the dll inside there, don't download elsewhere and put it in the new dlls there.
If your bitbase size is about 220MB then use the new ones.
If your bitbase size is about 365MB then use the old ones.
Check that and we will go from there.
Cheers
Edit Wait your problem seems to be different. In the position you provided 8/8/8/8/5kp1/P7/8/1K1N4 w - - 0 1 , all the moves lead to draw with best play so it just picks one and make it.

[syzygy]

I suppose Scorpio only searches winning moves when the root position is in the bitbases. In this position, the only winning move is Kc2. Since there is only one move to search, a 1-ply search will do.

edit: oops, this answer would have made sense were it not for the incorrect 0.00 score returned...

[syzygy]

Edit Wait your problem seems to be different. In the position you provided 8/8/8/8/5kp1/P7/8/1K1N4 w - - 0 1 , all the moves lead to draw with best play so it just picks one and make it.

Heh, now I get confused

Is the 0.00 draw score not a problem? Or am I reading it wrong? (Kc2 is winning according to my tables.)

[Daniel Shawul]

I am the one who is confused... I think he may have found a bug. But I forgot scorpio code so much..c is ugly to look at

[Daniel Shawul]

Ernest, it is working fine I think. It is because of some complicated code I put to cull root moves that lead to inferior score when being in egbb. So for <= 5 man positions, the root is already inside egbb and any move that leads to a score less than or equal to the root score by a good margin is culled out. So if the root says draw 0 score , then all the moves that loose are removed. If the root score is a win, then all moves that draw or loose are removed.
So in those situations it can sometimes end up with only one move to play. Typically for test suites there is only one good move to play and this happens a lot. I just run it on MES testsuite, the first 20 or so positions were solved at ply 1 this way. My motive was to make moves very quickly and save time. I think your are good to go, just remember this when analyzing positions with <=5 men.

[ernest]

Ernest, it is working fine I think. It is because of some complicated code I put to cull root moves that lead to inferior score when being in egbb. So for <= 5 man positions, the root is already inside egbb and any move that leads to a score less than or equal to the root score by a good margin is culled out.

Thanks Daniel!

Indeed, from the 5-man position where I reported the difficulty with Scorpio 2.7
(only winning move Kc2)
[d]8/8/8/8/5kp1/P7/8/1K1N4 w - - 0 1 ; bm Kb1-c2; dm50

I derived the following 7-man position
[d]8/8/8/7p/5kq1/P6Q/8/1K1N4 w - - 0 1
and Scorpio 2.7 gave the correct infinite analysis, triggered by the bitbases:
8/8/8/7p/5kq1/P6Q/8/1K1N4 w - - 0 1
Analysis by Scorpio 2.7:
1.Qxg4+ hxg4
+- (49.16) Depth: 6 00:00:00 5kN
1.Qxg4+ hxg4
+- (49.16) Depth: 6 00:00:00 6kN
1.Qxg4+ hxg4
+- (49.16) Depth: 7 00:00:00 6kN
1.Qxg4+ hxg4
+- (49.16) Depth: 7 00:00:00 7kN
1.Qxg4+ hxg4
+- (49.16) Depth: 8 00:00:00 7kN
1.Qxg4+ hxg4
+- (49.16) Depth: 8 00:00:00 9kN


Last, Dan, you did not answer to my second question:

Also note that when in scorpio.ini I put
#egbb_load_type 3
(meaning loading all 5 men in memory), my Task Manager does not show 200 MB more used in memory, and access is still from disk...
concerning
#load egbbs at start up
# 0 = none
# 1 = all 3/4 men
# 2 = selective loading of 5 men (not implemented yet)
# 3 = all 5 men

It seems only # 0 and # 1 work, loading # 2 and # 3 (5-men into memory) do not work

[Daniel Shawul]

Also note that when in scorpio.ini I put
#egbb_load_type 3
(meaning loading all 5 men in memory), my Task Manager does not show 200 MB more used in memory, and access is still from disk...
concerning
#load egbbs at start up
# 0 = none
# 1 = all 3/4 men
# 2 = selective loading of 5 men (not implemented yet)
# 3 = all 5 men

It seems only # 0 and # 1 work, loading # 2 and # 3 (5-men into memory) do not work

I just tried it. With option 1, 4-men bitbases are loaded in about 3 seconds to a total of 103mb total ram usage. Note about 80mb is for hashtables. But with option 3 that loads all five men, it took almost 4 minutes to initialize as shown below, and the task manager says 446mb used, so it does load the egbbs along with indexing tables. But if you wait a couple of seconds when scorpio is not analyzing any endgame position the usage goes down. That is ok.

Code: Select all

feature done=0
ht 1048576 X 64 = 64MB
eht 524288 X 16 = 8MB
pht 349525 X 24 = 7MB
EgbbProbe 3.3 by Daniel Shawul
Egbbs loaded !
loading_time = 234s

cheers

[Guenther]

Also note that when in scorpio.ini I put
#egbb_load_type 3

Well if you really put this there it will not work of course.
It will be ignored, because it is commented out by the '#' sign.

Guenther

[ernest]

Well if you really put this there it will not work of course.

Indeed Guenther! Thanks!!!

In scorpio.ini I put
#egbb_load_type 3 (don't know how that stupid # came up...)

Now corrected to
egbb_load_type 3