New Scorpio bitbase files

[bob]

searching only winning moves means your bitbase-less search won't make a mistake at the root and convert the win to a draw or loss, while letting your normal search and evaluation make the progress.

Right, so in those cases that a wrong root move is backed up(found out with the bitbase-less search) it means the search needs some help from the bitbases not just at the root but down the search tree also.

Not at all. How can you _possibly_ lose the game if you only consider bitbase verified winning moves? The problem is the draws due to the 50 move rule or repetition which the bitbases don't cover. All you need is an eval good enough to win such a "won position" once you actually reach it. You don't have to evaluate the position as "won" in your eval, which is dangerous, you just need code that will guide you to a win once you get into a won position. Those really are two different problems (recognizing a won position as opposed to winning a won position).

That is basically what I am trying to do. Let the search do its stuff for some search depth (2/3rd) then cutoff from that point onwards. If I make probe_depth less it won't be able to make progress. You have to probe somewhere close to the leaves to find the correct move at the root!! And for bitbases on disk (5 men are big) probing when the remaining depth left is 2 or 3 is bad. That is why I chose to not use the whole search depth (I really forgot to mention this until you brought up this case!) . For 4 men infact I do probes down the queiscene search also but not for 5 mens.

Somehow we are failing to communicate. A traditional search probes the egtbs/bitbases (depending on which you use) at interior nodes, but does a normal static evaluation at leaf nodes. Doing this, your approach is doomed, because you are not going to reach many of those leaf nodes, you keep getting cutoffs for "won position" at interior nodes. With no idea how to chose among the "won positions" to find the shortest mate, or at least make progress toward the mate.

If you use a completely different search, it might work, but what you seems to be trying to explain is not normal alpha/beta. The easiest solution is to take some known 5-piece winning positions where the mate is well beyond your normal search horizon, and then see if you can win them. From what I am reading in your posts, I don't see how you can do this since you are only rarely reaching endpoints where you do a normal eval.

A better example might be KNN vs KP. You can trivially drag that out excessively and draw it if you make a single mistake. Ditto for KQ vs KR as another example. After playing 30 moves into the 5-piece position, you might have two forced win moves where one is a mate in 15, the other is a mate in 25. The latter will end up drawing... The former will win. Hopefully your evaluation has enough info that it can take _most_ won positions and actually win them, particularly when you eliminate the moves that lose or draw at the root...

Note that I do probes inside search tree (no bitbase-less search for me) to effect mates with 6,7 men at the root. You don't have that problem because you are using EGTB score which has the _Mate in N_ value. Not so for bitbases, all you can do is guess the "N" value by how fast it converts to other postions etc... My search always backs up a correct root move that is why it makes no difference for me to cull moves at the root. But I understand you could have wrong moves there in your case.

The problem is you can't win positions you should be able to win. That's what I'm getting at. When you say "backs up a correct root move", that is _exactly_ what my code guarantees, because I _know_ that none of the root moves I search can lose (I am talking about swindle mode here). For drawing, one doesn't need a good evaluation. But for positions like KQ vs KR, or KRP vs KR, you do need some specific knowledge as bitbases can not possibly guide you to a winning line that doesn't fail the 50-move or repetition test, they just know this position is won with best play without regard to what has happened in the past, and without knowing how deep the win is. As you get closer and closer to a 50 move draw, you get more and more dangerous because you keep playing moves the bitbases say is won, but the path history proves is dead drawn...

[bob]

Swindle mode applies to draws, but it works for this case as well.

If you reach a 5 piece position at the root, where the bitbase result is "won", then you generate all legal moves. You make each move and then probe the bitbase for the resulting position which should now say "lost" since you have flipped sides. However, some of these moves will possibly say "won" since in a won position there might be losing moves as well. For any move where the result is anything but lost, you just cull those moves. So you are left with moves that take the opponent to a lost position, no others remain.

I don't think this helps us to advance in anyway. Whether the loosing root moves are there
or not, the engine will not waste much time with them (becasue of alpha-beta) neither plays them.
BTW I just realized that I do cull the loosing root moves in the recent versions. This was a side
effect of the code I wrote to make scorpio move immediately when it is loosing and drawing (fair
play for the opponent) So when some are drawing moves and some winning only the later are searched.
Before I did this all are searched with no side effect at all. The only problem with using bitbases is
going beyond the 50-move rule limit which should not have been there in the first place.
Ofcourse when we have 6 or more pieces at the root, there are no moves to cull at all, so obviously
no help from that.

Now disable bitbases and just search normally. You probably have some sort of "mop-up evaluation" that recognizes who is losing and who is winning, and tries to drive the losing side to the edge of the board first, and then to the correct corner if that is needed (KBN vs K for example). You continue to only search winning moves at the root and let your evaluation pick the one that appears to make the most progress. This will work in most cases, but difficult endings like KRP vs KR you need some small but specific evaluation terms to understand how to win or draw such positions dependin on which you want to do.

Ok disabling the bitbases and searching to the full depth is clearly better if you have <= 5 men at the root
because you invest the whole search depth for that. But if you have 6,7 or more pieces at the root where you actually need
the bitbases to see the positon is actually a win, you have to probe somewhere! Otherwise first it
says score is +46.52 for the 6men then you disable the bitbases for the next move you get +9.00 your
search/eval is good enough. You might even completly loose the plot and play some random move (I saw it
happen for kppkp cases). Disabling them causes search instability or in the worst case might loose you a possible
win. Thats why I chose a general scheme of probing upto a certain depth (2/3rd in this case). This depth is adjustable
and can be set to the whole search depth, which is similar to disabling it all in all. Infact this may be better
because in your case you use the regualr evaluation function, but in my case *the actual score from the bitbases* ,
rather than material based evaluation, is modified by some factors and returned.

For draws, I do this same thing, culling all moves that lead to losses, and then do a search. This avoids the ugly case where you are in a drawn ending, and you just give up the pawn since that is still a drawn position. This "swindle mode" will use the normal search (no tables used anywhere) so that the program tries to preserve the pawn and advance it as well, and if the opponent makes a mistake, we still check at the root and if we see a forced win we go for it, otherwise we search to make the opponent work as hard as possible to hold the draw and hope he makes a mistake.

Both ideas are the same here, in terms of code, although the desired result is different.

From what I understood of your swindle mode code, you just modify the draw score by 1 to pretend it is not a draw and
let the search find winning paths against an opponent which does not have egtb support. That is similar to what I do
except that I do more elaborate evaluations to progress in winning positions. For draws I don't even care to search them
just for fair play. I except other engines to just resign, rather than make me work, for positions like a won KQPKQ position even if I use bitbases

Daniel

That's not correct. In swindle mode, I +know+ the root position is a draw, i test each move and exclude non-drawing moves which can only be losing since the root is drawing already) and then do a normal search with a normal evaluation. The -.01, 0.00, +.01 are draw scores I use to indicate "draw but opponent has more material (-0.01), "draw, material is equal (0.00) and "draw, but I have more material (+0.01).

The reason is that if I am ahead in material, I at least have swindling chances against my opponent. If I am behind in material or material is equal, I have no chance to swindle him out of a win instead of a draw. So I prefer draws where I am ahead in material. But that has nothing to do with swindle mode searches. I just use the normal search, normal extensions, normal evaluation, to choose from among the moves known to not lose. The hope being the program will not lose the extra material and therefore keep things complicated so that the opponent can make a mistake.

Don't expect Crafty to resign, knowing that you have a potential issue that it can exploit. That's why crafty won't resign in a forced mate against the computer unless it sees _steady_ progress toward the mate. If the mate score jumps around, it is going to play on by default, as I would myself faced with a program that exhibits that behaviour.

[BBauer]

Hi Daniel,

I downloaded your code and built a egbbso.so for 64-bit ubuntu ,
but I didn't succeed with some togas.
When I used scorpio, I got

EgbbProbe 3.2 by Daniel Shawul
./scorpio: symbol lookup error: /media/USB-Bauer/64/bitbases/egbbso.so: undefined symbol: _Z12init_indicesv

So something looks wrong.
Kind regards
Bernhard

[Daniel Shawul]

Not at all. How can you _possibly_ lose the game if you only consider bitbase verified winning moves? The problem is the draws due to the 50 move rule or repetition which the bitbases don't cover. All you need is an eval good enough to win such a "won position" once you actually reach it. You don't have to evaluate the position as "won" in your eval, which is dangerous, you just need code that will guide you to a win once you get into a won position. Those really are two different problems (recognizing a won position as opposed to winning a won position).

I am talking about the case where you don't cull the root moves. I am surprized you thought so because I specifically explained why _you_ do need to cull the root moves somewhere in this thread. It can definately be backed up if you search _all your moves_ and use no bitbases inside search at all. Don't you agree here? I think this is pretty obvious and that is why you _do cull_ those loosing moves before you search them. For me it doesn't make a difference because I do probe the the bitbases inside search even if I have a won 5 men endgame at the root.

Somehow we are failing to communicate. A traditional search probes the egtbs/bitbases (depending on which you use) at interior nodes, but does a normal static evaluation at leaf nodes. Doing this, your approach is doomed, because you are not going to reach many of those leaf nodes, you keep getting cutoffs for "won position" at interior nodes. With no idea how to chose among the "won positions" to find the shortest mate, or at least make progress toward the mate.

If you use a completely different search, it might work, but what you seems to be trying to explain is not normal alpha/beta. The easiest solution is to take some known 5-piece winning positions where the mate is well beyond your normal search horizon, and then see if you can win them. From what I am reading in your posts, I don't see how you can do this since you are only rarely reaching endpoints where you do a normal eval.

I aleady explained that I do evaluate positions inside interior nodes before I return the mate score so I don't know why you are saying that
I am cutting the tree with "no idea" at all. Ok just think of the score composed of these things

Code: Select all

       a) Mate = 9000 , Lose = -9000 , Draw = 0
       b) Material => +300 if one side is a knight up etc...
       c) How far are we from root when we hit this mate =  factor * (PLY) 
       d) Piece closeness to the opponent king 
       e) pawn distance from 7th rank

In short it is just the actual bitbase score modified by whatever you have in your
regular eval() which helps drive the search. One might as well do just -Mate + eval()
without going into the trouble of writing a special eval. So there is absolutely
no difference at all whether I cutoff at interior nodes or at quiescence nodes. The only
difference being the relatively short cutoff point that is 2/3rd in my case (instead of the whole search depth),
which I mentioned previously. As I said in my previous response this is adjustable and I can make this the larger (say full search depth)
and get the same result as you. So the leaf nodes are just right there at the 2/3rd borderline for me. Do you oppose that this is less efficient other than the somewhat reduced search depth?

The problem is you can't win positions you should be able to win. That's what I'm getting at. When you say "backs up a correct root move", that is _exactly_ what my code guarantees, because I _know_ that none of the root moves I search can lose (I am talking about swindle mode here). For drawing, one doesn't need a good evaluation. But for positions like KQ vs KR, or KRP vs KR, you do need some specific knowledge as bitbases can not possibly guide you to a winning line that doesn't fail the 50-move or repetition test, they just know this position is won with best play without regard to what has happened in the past, and without knowing how deep the win is. As you get closer and closer to a 50 move draw, you get more and more dangerous because you keep playing moves the bitbases say is won, but the path history proves is dead drawn...

Again you are not looking things from my perspective. I tried to look at it from
yours and concluded that you do need to cull the root moves. Because once you switch to
swindle mode search where you don't do probes , you might back up a wrong
root move if you don't do probes inside search. We do agree here right? Now for me since I do probes inside
search the right move is always backed up. So it really doesn't matter if cull/or not at the root.
The regular eval is _never_ called in my case. Rather the real bitbase score modified with the required eval terms. Therefore there is no way I will have a wrong root move as the regular eval is not called, which if called could tamper the score and result in a different wrong move.

[bob]

Not at all. How can you _possibly_ lose the game if you only consider bitbase verified winning moves? The problem is the draws due to the 50 move rule or repetition which the bitbases don't cover. All you need is an eval good enough to win such a "won position" once you actually reach it. You don't have to evaluate the position as "won" in your eval, which is dangerous, you just need code that will guide you to a win once you get into a won position. Those really are two different problems (recognizing a won position as opposed to winning a won position).

I am talking about the case where you don't cull the root moves. I am surprized you thought so because I specifically explained why _you_ do need to cull the root moves somewhere in this thread. It can definately be backed up if you search _all your moves_ and use no bitbases inside search at all. Don't you agree here? I think this is pretty obvious and that is why you _do cull_ those loosing moves before you search them. For me it doesn't make a difference because I do probe the the bitbases inside search even if I have a won 5 men endgame at the root.

However, in my _first_ post I explained that I cull the non-drawing moves. That's the way swindle mode has always worked. I cull them because I am not going to use egtb's to guide the search, because I _know_ that the egtb result is draw at best. But egtbs have no concept of drawing in the most difficult-to-defend way possible, In KRPKR egtbs are just as likely to drop the pawn as not assuming the KRPKR ending is already drawn. My approach simply preserves whatever winning chances there are, thanks to the extra pawn, to give the opponent a chance to make a mistake and convert the draw into a win.

Somehow we are failing to communicate. A traditional search probes the egtbs/bitbases (depending on which you use) at interior nodes, but does a normal static evaluation at leaf nodes. Doing this, your approach is doomed, because you are not going to reach many of those leaf nodes, you keep getting cutoffs for "won position" at interior nodes. With no idea how to chose among the "won positions" to find the shortest mate, or at least make progress toward the mate.

If you use a completely different search, it might work, but what you seems to be trying to explain is not normal alpha/beta. The easiest solution is to take some known 5-piece winning positions where the mate is well beyond your normal search horizon, and then see if you can win them. From what I am reading in your posts, I don't see how you can do this since you are only rarely reaching endpoints where you do a normal eval.

I aleady explained that I do evaluate positions inside interior nodes before I return the mate score so I don't know why you are saying that
I am cutting the tree with "no idea" at all. Ok just think of the score composed of these things

Code: Select all

       a) Mate = 9000 , Lose = -9000 , Draw = 0
       b) Material => +300 if one side is a knight up etc...
       c) How far are we from root when we hit this mate =  factor * (PLY) 
       d) Piece closeness to the opponent king 
       e) pawn distance from 7th rank

In short it is just the actual bitbase score modified by whatever you have in your
regular eval() which helps drive the search. One might as well do just -Mate + eval()
without going into the trouble of writing a special eval. So there is absolutely
no difference at all whether I cutoff at interior nodes or at quiescence nodes. The only
difference being the relatively short cutoff point that is 2/3rd in my case (instead of the whole search depth),
which I mentioned previously. As I said in my previous response this is adjustable and I can make this the larger (say full search depth)
and get the same result as you. So the leaf nodes are just right there at the 2/3rd borderline for me. Do you oppose that this is less efficient other than the somewhat reduced search depth?

That is not how a "normal" search would look, so I assume that you have two different searches? What I suppose I am not following is "how are you merging the bitbase score with the above score?" And "how does this prevent you from just wandering around since you have absolutely no idea how deep the actual mate really is?" The depth from the root means nothing in this context. Just because you get a bitbase hit at ply N, the current depth doesn't tell you anything about how far the real mate is from this (or from the root) position. So how can you intelligently choose the path that makes progress if you don't have any way of actually measuring progress??? If you are really adding a "mate" score to the eval result, then that may well do the trick, assuming you have some actual code that measures progress. Normal isolated pawns and such is worthless. You need specific knowledge to make progress. For KRPKR, the winning side wants to get his king in front of the pawn while locking the opponent's king away from the pawn, etc...

The problem is you can't win positions you should be able to win. That's what I'm getting at. When you say "backs up a correct root move", that is _exactly_ what my code guarantees, because I _know_ that none of the root moves I search can lose (I am talking about swindle mode here). For drawing, one doesn't need a good evaluation. But for positions like KQ vs KR, or KRP vs KR, you do need some specific knowledge as bitbases can not possibly guide you to a winning line that doesn't fail the 50-move or repetition test, they just know this position is won with best play without regard to what has happened in the past, and without knowing how deep the win is. As you get closer and closer to a 50 move draw, you get more and more dangerous because you keep playing moves the bitbases say is won, but the path history proves is dead drawn...

Again you are not looking things from my perspective. I tried to look at it from
yours and concluded that you do need to cull the root moves. Because once you switch to
swindle mode search where you don't do probes , you might back up a wrong
root move if you don't do probes inside search. We do agree here right? Now for me since I do probes inside
search the right move is always backed up. So it really doesn't matter if cull/or not at the root.
The regular eval is _never_ called in my case. Rather the real bitbase score modified with the required eval terms. Therefore there is no way I will have a wrong root move as the regular eval is not called, which if called could tamper the score and result in a different wrong move.

[Daniel Shawul]

That is how I understood it. For draws things are pretty easy. Your swindle mode infact is the simplest it only considers material to choose between different draws. For example it doesn't try to consider where the draw occurs. We can do that to choose immediate draws rather than those further from the root. We can also try to choose KbK draws form a somewhat difficult KbnK draw. If you add all these then the +1 stuff doesn't really work because now you have many factors which should be tuned for optimum performance. That is basically what I am trying to do for mate/loss positons, where you have more factors to tune.

[Daniel Shawul]

hello bernhard
I don't have linux so I can't check it myself. I will ask someone to make
a compile and see if they get the same reslult.

thanks

[Daniel Shawul]

However, in my _first_ post I explained that I cull the non-drawing moves. That's the way swindle mode has always worked. I cull them because I am not going to use egtb's to guide the search, because I _know_ that the egtb result is draw at best. But egtbs have no concept of drawing in the most difficult-to-defend way possible, In KRPKR egtbs are just as likely to drop the pawn as not assuming the KRPKR ending is already drawn. My approach simply preserves whatever winning chances there are, thanks to the extra pawn, to give the opponent a chance to make a mistake and convert the draw into a win.

Your approach only consider material only as I have mentioned in my other post. Infact more factors could be incorporated there.

That is not how a "normal" search would look, so I assume that you have two different searches?

No

What I suppose I am not following is "how are you merging the bitbase score with the above score?"

All the factors I listed above are merged by weighing the different factors. Even the mate in N term has some factor in it, where most usually use -MATE + ply , I do -MATE + factor * ply.

And "how does this prevent you from just wandering around since you have absolutely no idea how deep the actual mate really is?"

My goal is not to solve all the mating values but _most_. So I don't see the point of your argument here at all. Ofcourse I can's solve every mate with just bitbases. You try to drive the 50 move rule away and hope the search finds winning moves soon. The weighted terms usually does work for me.

The depth from the root means nothing in this context. Just because you get a bitbase hit at ply N, the current depth doesn't tell you anything about how far the real mate is from this (or from the root) position. So how can you intelligently choose the path that makes progress if you don't have any way of actually measuring progress???

Again I said I evaluate the positons so how can you say I am not measuring progress? The evaluation infact does only those terms which are important for driving the king. The distance from the root has some importance also that is why I use a factor for that. I use larger factors for
distance from root, then for bigger material then for opponent closeness to king then for even smaller eval terms. Once can change the factors for specific positions depending on which works the best.

If you are really adding a "mate" score to the eval result, then that may well do the trick, assuming you have some actual code that measures progress. Normal isolated pawns and such is worthless. You need specific knowledge to make progress. For KRPKR, the winning side wants to get his king in front of the pawn while locking the opponent's king away from the pawn, etc...

Exactly what I am doing. I said this again and again, I use special eval plus the mate score. You are using the regular search with the regular eval.

Normal isolated pawns and such is worthless. You need specific knowledge to make progress. For KRPKR, the winning side wants to get his king in front of the pawn while locking the opponent's king away from the pawn, etc...

As a matter of fact, I have been trying to adjust weights for specifc positions whenever someone posts some positons whose mate can't be effected in the 50 move rule bound. It works for most so I don't usually care if it doesn't sometimes. My experience is on the good side so far.

[pedrox]

I have compiled a version of the dll for pocket pc. Now I have a version of danasah (4.21) for pocket pc that it can use bitbases (5 men). The bitbases are stored in the memory card (256 Mb).

If anyone wants egbbdll.dll for pocket pc can to contact me and I put the link.

Best,

Pedro

[Denis P. Mendoza]

Thanks Denis! Lets wait for some more tests before we make them
official. I tested with Toga and Bright here which worked successfully.
If no one comes up with more bugs in a weeks time, I will just take your
compiles (if you don't mind) and post it on my web page.

regards,
Daniel

You're welcome. If you mind, I had uploaded your new bitbases on my back-up site: http://computerchessengines.mylivepage.com

I'll also ask permission from Shaun Brewer if it's ok to upload it in our TDDB ftp site. We also have your previous egbb database there too. I'll just post the link here for those who missed.

Thanks again.