New Scorpio bitbase files

[bob]

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.

Not quite. "swindle mode" doesn't have draw scores in it, unless it physically sees repetitions or 50-move draws approaching. In fact, it usually thinks it is winning because it is often material ahead, which is where swindle mode helps. the "material-based draw score" works everywhere and has nothing to do with swindle mode itself... Since the program is material ahead, it will always try to avoid simple draws (like trading into a KB vs K ending since it knows that is a draw, where KRB vs KR can be won in many cases. That's the idea of swindle mode, as egtbs will think that KRB vs KR (where the starting position is a draw) is no better or worse than KB vs K. Yet the latter is trivial to draw, while the former takes a lot of understanding on what not to do to avoid losing... Swindle mode gives the opponent the chance to do those "bad things"...

[bob]

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.

You keep saying this but it is _still_ wrong. My approach only includes drawn moves at the root. I then start the search with egtbs disabled, and use a nornal search, normal evaluation, etc. Which includes Crafty's endgame analysis of pawns, and special cases like KRPKR, KRBKR, and others. And these searches don't produce draw scores in general because it usually thinks it is winning and is hoping for an opponent mistake to make that come true.

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.

[Daniel Shawul]

This is getting boring now.
I was talking of this part of your egtb code which adjusts the draw score by +1 or -1 by looking at material only. Ofcourse when you do search you are going to use your eval() because you turnoff bitbase probes there. That has been discussed to death throught this discussion. If I thought that you don't use the eval() , I wouldn't have said many times that doing the full search like you do might spot better drawing/winning chances....

Code: Select all

#if !defined(NOEGTB)
  if (ply <= iteration_depth && TotalAllPieces <= EGTB_use &&
      Castle(ply, white) + Castle(ply, black) == 0 &&
      (CaptureOrPromote(tree->curmv[ply - 1]) || ply < 3)) {
    int egtb_value;

    tree->egtb_probes++;
    if (EGTBProbe(tree, ply, wtm, &egtb_value)) {
      tree->egtb_probes_successful++;
      alpha = egtb_value;
      if (abs(alpha) > MATE - 300)
        alpha += (alpha > 0) ? -ply + 1 : ply;
      else if (alpha == 0) {
        alpha = DrawScore(wtm);
        if (Material > 0)
          alpha += (wtm) ? 1 : -1;
        else if (Material < 0)
          alpha -= (wtm) ? 1 : -1;
      }
      if (alpha < beta)
        SavePV(tree, ply, 2);
      tree->pv[ply].pathl = 0;
      HashStore(tree, ply, MAX_DRAFT, wtm, EXACT, alpha,
          tree->pv[ply].path[ply]);
      return (alpha);
    }
  }
#endif

I do the egbb probe and evaluation at the same place. You do it separately fine. PLEASE understand that *not anywhere* did I say your method doesn't work.

As I have mentioned before mine has advantages

a) I don't need to cull root moves which is a _must_ for your case.
b) Another is your eval() might screw up the move you found out with the egtbs. If you suddenly switch to bitbase-less search then it might be blind
again because all you have is your eval(). I use the eval + the probed bitbase score so for me no problem. You cull the loosing root moves which make your swindle move work so no argument there. Don't say you have a drawing move at the root because I know that your method works for what it is supposed to. I am just thinking of the general situation where we want to progress wins/losses/draws as much as possible not only draws.

A move which you have is good because in some cases you do not want
to use your eval. Take KBNK or KRPKR for example, your regular eval can't differentiate all the draws and wins. So what I do is check if it is a draw or win then modify it by looking at some factors which are good for progress. For a won kBNK it is +6.00 with some modification and for a draw it is +0.00 with some modifications. For your case though this will always be +6.00 with some modifications, so don't you think the former is better?

Please understand that I am not here just for the sake of argument you on the other hand just ignore a lot of staff I wrote down there explaining how mine works (Remember you said mine will not work! ). So I really don't want to discuss like that If I don't get response when I took the effort to explain. Sorry if I misunderstood your intention.

Daniel[/i]

[Daniel Shawul]

That is great Pedro! I guess that is one advantage of the reduced size which I didnt think of . I tried the old ones on a 1GB flash disk once and they seemed to be faster. Any speed increase there?
I might be able to further comperss them down by using predictions which I have not taken advantage of right now.
cheers
Daniel

[bob]

This is getting boring now.
I was talking of this part of your egtb code which adjusts the draw score by +1 or -1 by looking at material only. Ofcourse when you do search you are going to use your eval() because you turnoff bitbase probes there. That has been discussed to death throught this discussion. If I thought that you don't use the eval() , I wouldn't have said many times that doing the full search like you do might spot better drawing/winning chances....

The part of your post that is causing the problem is that you keep using the terms "swindle mode" and "material-based draw score" where the two terms are completely unrelated. That was my point. In swindle mode, I generally don't see draw scores for a _long_ time, because I think I am material ahead, and the evaluation does not say KRP vs KR is a draw, it just evaluates the positions of the kings and knows which positions are "more drawish" than others.

Code: Select all

#if !defined(NOEGTB)
  if (ply <= iteration_depth && TotalAllPieces <= EGTB_use &&
      Castle(ply, white) + Castle(ply, black) == 0 &&
      (CaptureOrPromote(tree->curmv[ply - 1]) || ply < 3)) {
    int egtb_value;

    tree->egtb_probes++;
    if (EGTBProbe(tree, ply, wtm, &egtb_value)) {
      tree->egtb_probes_successful++;
      alpha = egtb_value;
      if (abs(alpha) > MATE - 300)
        alpha += (alpha > 0) ? -ply + 1 : ply;
      else if (alpha == 0) {
        alpha = DrawScore(wtm);
        if (Material > 0)
          alpha += (wtm) ? 1 : -1;
        else if (Material < 0)
          alpha -= (wtm) ? 1 : -1;
      }
      if (alpha < beta)
        SavePV(tree, ply, 2);
      tree->pv[ply].pathl = 0;
      HashStore(tree, ply, MAX_DRAFT, wtm, EXACT, alpha,
          tree->pv[ply].path[ply]);
      return (alpha);
    }
  }
#endif

I do the egbb probe and evaluation at the same place. You do it separately fine. PLEASE understand that *not anywhere* did I say your method doesn't work.

As I have mentioned before mine has advantages

a) I don't need to cull root moves which is a _must_ for your case.

How is that an advantage? In fact it would be better if you did it that way as well. Why? Less stuff to search at the root turns into deeper searches, only on the moves that actually lead to a win. So I don't get the "mine has advantages" where I see none at all, and in reality I see a significant disadvantage since you are searching moves you _know_ lead to a draw or loss, for 2/3 of the tree, before you enable a bitbase probe which will instantly reject those losing / drawing lines.

b) Another is your eval() might screw up the move you found out with the egtbs. If you suddenly switch to bitbase-less search then it might be blind
again because all you have is your eval(). I use the eval + the probed bitbase score so for me no problem.

Still missing the point. If you exclude losing / drawing moves at the root, you can't _possibly_ make a mistake and lose. You can always draw by 50 moves or repetitions, but you can still do that anyway as that is a problem when the bitbases can't help you find the shortest mate and you depend on your evaluation instead.

We both depend on our eval to make progress. I just exclude the losing moves since there is absolutely no point in searching them as they convert a draw or win into an outright loss. So my eval can't lose the game, ever. But it can run into a 50 move rule. And for me, that's ok, because the initial position is already known to be a theoretical draw by egtbs. But when you have a forced win, you want to do everything possible to preserve it, which with bitbases leaves the implementation of this to the evaluation, which had better be up to the task.

You cull the loosing root moves which make your swindle move work so no argument there. Don't say you have a drawing move at the root because I know that your method works for what it is supposed to. I am just thinking of the general situation where we want to progress wins/losses/draws as much as possible not only draws.

Hence my suggestion. If you know your root position is won, why bother searching the losing/drawing root moves at all? Total waste of time. And by spending your time searching only the moves that are known to win, you can go deeper and perhaps find a better way to make progress. Without wasting any effort on things you already know are bad from the start.

A move which you have is good because in some cases you do not want
to use your eval. Take KBNK or KRPKR for example, your regular eval can't differentiate all the draws and wins. So what I do is check if it is a draw or win then modify it by looking at some factors which are good for progress. For a won kBNK it is +6.00 with some modification and for a draw it is +0.00 with some modifications. For your case though this will always be +6.00 with some modifications, so don't you think the former is better?

If that were how my code worked, maybe. But it isn't. My evaluation has specific code for endings and how to make progress. It knows that in KRP vs KR the winning side wants to keep the losing side's king as far away from the queening square as possible, while advancing the pawn (with king support) as quickly as possible. For KBN vs K, it knows which corner the losing king wants to avoid, and it makes progress by driving it toward that corner. It can win this ending with a very shallow search, even against an opponent with EGTBs. Ditto for KQ vs KR which is an easy position to win with some simple endgame knowledge.

In current crafty, which doesn't use bitbases, if I am winning at the root I don't do a search of any kind. If I were doing bitbases, and discovered I am winning at the root, I would do exactly what I do in swindle mode. It is simply more efficient than what you are doing.

(1) You search all root moves, including moves that lose or draw, and depend on the bitbases to kick in 2/3 of the way to the leaves and cull those lines. I don't even search those lines from the root at all.

(2) I cull the losing moves (there are no winning moves if I see draw at the root) and I would (if I used bitbases) cull the drawing moves as well, leaving only winning moves. Now I only search those since I don't care to play any move that leads to a known etgb/bitbase loss or draw since I am winning before I make a move.

I don't see how you can make a case that searching the lemon moves is better.

If I am winning, I only search winning moves and use my eval to guide me to make progress. If I am drawing, I only search drawing moves, and use my eval to keep the game as complicated as possible by not giving up any of my material advantage unnecessarily which makes a draw easier for my opponent.

Seems to me the same idea works well in _both_ cases. I don't see anything wrong with probing bitbases way out in the search, as you suggest. As that helps to cull the losing drawing lines that can occur with sub-optimal moves, even if the root move is a winning move. But I don't see anything good about searching root moves that are known to be bad, since you already know you have winning moves you can play.

Your goal is to play the winning move that makes the most progress here. No mention of losing or drawing moves.

Please understand that I am not here just for the sake of argument you on the other hand just ignore a lot of staff I wrote down there explaining how mine works (Remember you said mine will not work! ). So I really don't want to discuss like that If I don't get response when I took the effort to explain. Sorry if I misunderstood your intention.

Daniel[/i][/quote]

You did not explain the bitbase + eval() mechanism in a clear way to start. That's why I said it would not work. I have looked at several bitbase programs and have not found one that does anything other than use a mate or draw score, since traditional programs don't do evaluations in the interior nodes. Your idea makes sense to a point, so no argument there. But you could make it even better by selectively searching the right root moves, not all of them.

[Daniel Shawul]

How is that an advantage? In fact it would be better if you did it that way as well. Why? Less stuff to search at the root turns into deeper searches, only on the moves that actually lead to a win. So I don't get the "mine has advantages" where I see none at all, and in reality I see a significant disadvantage since you are searching moves you _know_ lead to a draw or loss, for 2/3 of the tree, before you enable a bitbase probe which will instantly reject those losing / drawing lines.

It is an advantage in the sense that mine works even if I have a 6 or 7 man egtb at the root. In that case you can not cull moves at the root,
so you do your normal search as usual by probing your egtbs. Now for your case it is pretty safe because if you return at the 3rd ply of search
with a mate score you can still progress because the EGTBs have the "mate in N" term in them. But for my case where that is lacking
it will be difficult to progress because all I have is a mate. Before I did this, I have observed many cases where it can not progress from
a 6man,7man endgame to a simple 5man endgame. Sometimes when you have too many winning moves at the root for the 6man endgame, it keeps on returning a random winning move (not exactly the shortest) with a huge score and yet not making progress. It goes on like that until it starts to realize the 50 move rule in which case it suddenly starts choosing those winning moves which does lead to the exchange and hence the 5man endgame. In the worst case it misses it all in all and let the win go to a draw. That is why I have the "not probe case within the 2/3 depth" unless it is a capture/pawn pushe etc.

So tell me clearly if your method will work if for 6man at the root and using _bitbases_ only. I say _not_ from my experience. If you agree ,then that is the advantage I was talking about.

Still missing the point. If you exclude losing / drawing moves at the root, you can't _possibly_ make a mistake and lose. You can always draw by 50 moves or repetitions, but you can still do that anyway as that is a problem when the bitbases can't help you find the shortest mate and you depend on your evaluation instead.

I was afraid that you might say that and that is why I "pre-told" you that
I do understand what you are doing. Here is a quote from my previous post. See i didn't miss the point at all.

You cull the loosing root moves which make your swindle move work so no argument there. Don't say you have a drawing move at the root because I know that your method works for what it is supposed to. Smile I am just thinking of the general situation where we want to progress wins/losses/draws as much as possible not only draws.

Hence my suggestion. If you know your root position is won, why bother searching the losing/drawing root moves at all? Total waste of time. And by spending your time searching only the moves that are known to win, you can go deeper and perhaps find a better way to make progress. Without wasting any effort on things you already know are bad from the start.

I don't disagree but one may choose to ignore going into the trouble of
culling the loosing root moves if he is sure that no wrong moves will be backed up to the root. Infact the question shoud be why would one do that? For your case it is a _must_. For me I may (for a relatively faster search at the root, and someimes faster forced move replies) or may not (just because I don't want to write the extra code).

In current crafty, which doesn't use bitbases, if I am winning at the root I don't do a search of any kind. If I were doing bitbases, and discovered I am winning at the root, I would do exactly what I do in swindle mode. It is simply more efficient than what you are doing.

It can't handle a 6man/7man at the root so it is not more efficient.

(1) You search all root moves, including moves that lose or draw, and depend on the bitbases to kick in 2/3 of the way to the leaves and cull those lines. I don't even search those lines from the root at all.

But you have to if you want to handle 6men/7men at the root.

(2) I cull the losing moves (there are no winning moves if I see draw at the root) and I would (if I used bitbases) cull the drawing moves as well, leaving only winning moves. Now I only search those since I don't care to play any move that leads to a known etgb/bitbase loss or draw since I am winning before I make a move.

I don't see how you can make a case that searching the lemon moves is better.

I said I don't do that because I _can't_ (not because I don't want to) do it for 6man/7man. For 5 man one may or may not do it depending on what he uses.

You did not explain the bitbase + eval() mechanism in a clear way to start. That's why I said it would not work. I have looked at several bitbase programs and have not found one that does anything other than use a mate or draw score, since traditional programs don't do evaluations in the interior nodes. Your idea makes sense to a point, so no argument there. But you could make it even better by selectively searching the right root moves, not all of them.

I guess the basic difference between us is clear now. I want it to work for general cases 6man/7man at the root, so I can't do it like you (cull the loosing root moves).

[Tony]

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

You should remove c) because it will only result in shallower searches being favoured ( and kill your search efficience. Check out your ebf when in a bitbase position)

Replace it with the highest value the 50 move counter got before it was reset the first time in the current line. That way it doesn't mess up the hashtables. ( If you clear the hashtable scores after the 50 move counter was reset at the root)

Tony

[Daniel Shawul]

The reason why I use the distance from root is to avoid silly moves like this.

[d] 8/6k1/pK6/8/8/3R4/8/8 w - - 0 1

Now in this position white should just capture the black pawn and move on. But before I added the PLY factor, it evaluates almost all moves as equal. That is Kxa6,Ka5,Kc5,Kc6 etc are all the same, but obviously Kxa3 is the best because it happens earlier. The 50 move rule can not help us here because the other moves can also capture the pawn quite easily. For example Ka4->black king moves->Kxa3 (or could still move to Kb6 and continue forever until it starts looking at the 50 move rule). This turned out to be a big factor most of the times, but in some cases other factors could govern also.

One thing I forgot to mention as regards material, bonus will be given when a side is ahead in material and _also_ when the number of pieces is lower. For example a KQBKB is less prefered than a KQK even though they both have the same material differene. This is I think the other term which has a big factor.

Edit: I want to add that the example I gave above is very simple. But the white king could be further from the black pawn. In that case the white king should go for the shortest path possible to capture the black pawn.
What I experienced is since there are many ways to capture the black moves even if you make non-optimal moves, it stops making distinction between the different paths. I found the PLY factor suitable for that purpose.


Daniel

[bob]

The reason why I use the distance from root is to avoid silly moves like this.

[d] 8/6k1/pK6/8/8/3R4/8/8 w - - 0 1

Now in this position white should just capture the black pawn and move on. But before I added the PLY factor, it evaluates almost all moves as equal. That is Kxa6,Ka5,Kc5,Kc6 etc are all the same, but obviously Kxa3 is the best because it happens earlier. The 50 move rule can not help us here because the other moves can also capture the pawn quite easily. For example Ka4->black king moves->Kxa3 (or could still move to Kb6 and continue forever until it starts looking at the 50 move rule). This turned out to be a big factor most of the times, but in some cases other factors could govern also.

One thing I forgot to mention as regards material, bonus will be given when a side is ahead in material and _also_ when the number of pieces is lower. For example a KQBKB is less prefered than a KQK even though they both have the same material differene. This is I think the other term which has a big factor.

Edit: I want to add that the example I gave above is very simple. But the white king could be further from the black pawn. In that case the white king should go for the shortest path possible to capture the black pawn.
What I experienced is since there are many ways to capture the black moves even if you make non-optimal moves, it stops making distinction between the different paths. I found the PLY factor suitable for that purpose.


Daniel

You are creating ad-hoc rules that can fail. For example, in a knn vs kp ending, if you go gobble the pawn, you throw away the win. Even worse, you may well need that capture much later to reset the 50-move counter when a mate is going to stretch beyond 50 full moves...

[Daniel Shawul]

You are creating ad-hoc rules that can fail. For example, in a knn vs kp ending, if you go gobble the pawn, you throw away the win.

That will _never_happen becasue the bitbases are checked after the capture. Only if the capture is winning will it be considered in the first place.

Even worse, you may well need that capture much later to reset the 50-move counter when a mate is going to stretch beyond 50 full moves...

What could you have done in my situation?? Do you expect me to delay
the capture in the hope that it will help in avoiding the 50 move rule later?
You can only find such kind of exact information (where exactly the capture should happen) in EGTB with the mate in N condition. Assuming we have only bitbases, then all I can do at best is to weigh the different factors in to condsderation. If you have other ideas , lets hear it. Other wise stop making such silly claims which are easily refuted.