New Scorpio bitbase files

[Daniel Shawul]

I will compile a linux so and upload everything once we make sure it works properly. If you want you can compile the source code yourself and try it
http://dshawul.googlepages.com/home

regards,
Daniel

[ernest]

It should work now.

Hi Daniel,
Both egbbdll.dll (the one I downloaded yesterday and the one I downloaded today) are different (I did a file compare) but both contain the same mention "EgbbProbe 3.2 by Daniel Shawul"
Difficult to keep track!
I think you should offer a zipped download, which at least keeps your original creation date of the dll.

What do you think of Dann Corbit's bitbases?
Any idea where they can still be downloaded?

[bob]

Hello Jouni

The bitbases only give you a win / lose / draw information so the engine itself has to effect the win. Sometimes in positions like you shown that could be difficult. Most of the time the engine uses part of the search depth say (2/3) for that purpose and in the tips it just returns the egbb score without doing search. So this way it would be able to progress most of the time.
Unfortunately the search depth was not enough for the particular for this case which was why it was able to mate without them.

As to your other question, when 64bit and 32bit engines ,which use egbbs, are run on a 64bit computer then we need separate egbbdlls for those. The 32bit engines will load egbbdll and the 64bit engines egbbdll64. The default egbbdlls are compiled with SMP on so we don't need separate compiles for those.

regards,
daniel

This doesn't work. Because eventually you reach a pure 5-piece ending and do _no_ searching at all. Now you have to find a way to get closer to mate. I'd suggest the "swindle mode" built into crafty.

Generate the root move list. Then, using the bitbases, exclude every non-won position so that all you are left with are bitbase won positions. Now turn them off and do a normal search, but only search those moves at the root. This likely won't help for KRP vs KR or KQP vs KQ or some fo the harder positions, unless you have some knowledge in your program about how to win them, but it will be better than a random walk hoping you stumble into a checkmate...

[Daniel Shawul]

Code: Select all

This doesn't work. Because eventually you reach a pure 5-piece ending and do _no_ searching at all. Now you have to find a way to get closer to mate. I'd suggest the "swindle mode" built into crafty. 

I wouldn't say it doesn't work.
In the first 2/3 of the search depth it pretends it doesn't have a bitbase win score, no probes at all. I think Toga tried your method once i.e switching to a special mode "swindle" . The only difference with what I am using is IMO the search depth. You use the full search depth , I use the 2/3rd only. Obviously switching to a swindle spots winning lines better when you have a won 5 men endgame but...

The problem with your method is that it only works when we are in the 5 men bitbases already. If you have a 8,7,6 man endgame and your search spots a bitbase win (some exchanges down the search leading to 5 men bitbases) then we can't use that because there is no win/loss at the root. However with mine it can still make progress by probing the bitbases (which should be probed to see the actual win). I have experimented with both methods in the past and it looks to me better than switching to an artifical search mode (IE egbb probes turned off). But engine authors are free to use whatever they want to, the bitbase only report the scores.

YMMV
Daniel

[Daniel Shawul]

Sorry Ernest, Dann's site is not working. The bitbases download exceeded the bandwidth limit and his site is no more working, which I feel bad about.
I will find some other means for downloads, until then you guys have to share it.
I keep forgetting changing the version numbers. it won't happen again.

regards,
daniel

[bob]

Code: Select all

This doesn't work. Because eventually you reach a pure 5-piece ending and do _no_ searching at all. Now you have to find a way to get closer to mate. I'd suggest the "swindle mode" built into crafty. 

I wouldn't say it doesn't work.
In the first 2/3 of the search depth it pretends it doesn't have a bitbase win score, no probes at all. I think Toga tried your method once i.e switching to a special mode "swindle" . The only difference with what I am using is IMO the search depth. You use the full search depth , I use the 2/3rd only. Obviously switching to a swindle spots winning lines better when you have a won 5 men endgame but...

The problem with your method is that it only works when we are in the 5 men bitbases already. If you have a 8,7,6 man endgame and your search spots a bitbase win (some exchanges down the search leading to 5 men bitbases) then we can't use that because there is no win/loss at the root. However with mine it can still make progress by probing the bitbases (which should be probed to see the actual win). I have experimented with both methods in the past and it looks to me better than switching to an artifical search mode (IE egbb probes turned off). But engine authors are free to use whatever they want to, the bitbase only report the scores.

YMMV
Daniel

I don't see how it helps.

We start off in a 5-piece ending, so bitbase probes are 100%.

The depth limit is 18 plies for this iteration.

You refuse to probe the bitbases for the first 12 moves/plies. You probe at 13 and get an instant hit that says "win". How does that guide you to a closer win so that you don't just walk back and forth threatening to win, but never doing so?

My approach would also use them in the tree prior to reaching 5 piece endings. That is how "swindle mode" works anyway. But once you find a win, and you continue searching after having a 5-man ending at the root, I don't see how you can make any progress since you just randomly search parts of the tree and notice that some lead to a mate, which you like, and some do not, which get cut off. But that's not good enough to avoid dragging a game past the 50 move rule...

[krazyken]

Let me see if I understand this right. Bitbases should not be used to return an eval, they can only be used to prune the tree to make it easier for the engine to search out the mate. If the mate isn't obvious then the engine needs knowledge to know what to try for, such as reducing to an easier endgame, or restricting the enemy king's mobility.

[Daniel Shawul]

I don't see how it helps.

We start off in a 5-piece ending, so bitbase probes are 100%.

I thought that you said the swindle mode works by excluding the non-winning _root moves_ and searching only the winning moves. For that to work the position at the root should be in the egbb in the first place? So I don't see how that works if I have a 7 man position at the root (while having only 5 men bitbases). The search can still return mate scores because of exchanges. You would have to explain how the swindle mode works before we go on...

What I do is probe the bitbases in case we have captures/promotions/pawn pushes immediately even in the first 2/3rd of the search tree. Now if that doesn't cutoff the tree and we reach the "pseudo horizon" (2/3 rd boundary), we do a probe and then adjust the score by the ply. Pretty much like mate scores. If we just returned -MATE then we won't be able to progress. So I do -WIN_SCORE + factor * (PLY) that makes sure mates at shallower depth are prefered. There are some issues with the Hash table that should be handled but this pretty much worked for me for some time... Forget the KQPKQ case that keeps to be posted here again and again.

Also scores are adjusted to make better progress in specially difficult positonss liek KbnK which requires different king piece square table.
For the general case I have this
score = WIN_SCORE
- 10 * distance(SQ6488(w_king),SQ6488(b_king))
+ (5 - all_c) * 1000;


Daniel

[bob]

Let me see if I understand this right. Bitbases should not be used to return an eval, they can only be used to prune the tree to make it easier for the engine to search out the mate. If the mate isn't obvious then the engine needs knowledge to know what to try for, such as reducing to an easier endgame, or restricting the enemy king's mobility.

You can use them as values, until you reach a position in the real game where _everything_ is a bitbase hit. Then you have a problem. Many using bitbases switch to egtb's at the root which solves this completely, without slowing the search in non-egtb-at-the-root positions.

But once you know the root position is won, you have to win it. And if all you have is bitbases, you are going to have to trust your search to shorten the distance to a win as the game progresses. And if you limit that search to only positions that are bitbase wins, you at least can not lose, although you might draw if you can't figure out how to make a move that avoids a 50-move draw before it is too late.

[Denis P. Mendoza]

I will compile a linux so and upload everything once we make sure it works properly. If you want you can compile the source code yourself and try it
http://dshawul.googlepages.com/home

regards,
Daniel

Thanks Daniel, it's now working on multi-cpu mode!
I built also a 64-bit for those who need it. Tested on 2-cpu with no problems.
http://www.mediafire.com/download.php?zm0yy2mimdl

I'll try to secure an archive for these new bitbases somewhere for those who missed them.

Denis