Natural TB

Discussion of anything and everything relating to chess playing software and machines.

Moderators: hgm, Rebel, chrisw

syzygy
Posts: 5563
Joined: Tue Feb 28, 2012 11:56 pm

Re: Natural TB

Post by syzygy »

jhellis3 wrote:
there is no point in using TBs.
Mate with more than 6 pieces on the board?
If you quote half sentences, you get funny phrases.
jhellis3
Posts: 546
Joined: Sat Aug 17, 2013 12:36 am

Re: Natural TB

Post by jhellis3 »

Immaterial to my point, but sure I can edit the post...
syzygy
Posts: 5563
Joined: Tue Feb 28, 2012 11:56 pm

Re: Natural TB

Post by syzygy »

jhellis3 wrote:Immaterial to my point, but sure I can edit the post...
Well, I don't deny there are positions with non-TB winning paths.

The point is there are positions without non-TB winning paths and you don't have to be unlucky to find one. It would be quite unfortunate if a mere cosmetic improvement managed to hide a real (TB) win. In my view something is wrong if Qxf6 does not manage to overtake Rb7 when Rb7 does not yet clearly improve on the static eval of the root position.

Ideally, SF should stick to Qxf6 (known to be a win from iteration 4) until it finds a mate for Rb7 at iteration 25. This could be achieved by taking out Qxf6 once it is known to win and then search the rest in the normal way, but that would be a messy solution (and not really what you want anyway, because you also want to search Qxf6 deeper in order to find the shortest mate following that move).
jhellis3
Posts: 546
Joined: Sat Aug 17, 2013 12:36 am

Re: Natural TB

Post by jhellis3 »

The point is there are positions without non-TB winning paths and you don't have to be unlucky to find one.
It is not just that though...

I mean if you can find a position where fix 2 search settles on an incorrect move I'd be interested to see it, but....


I also do not doubt that a "better" solution exists. However, it will almost certainly be more than 3 lines of code, and I am willing to trust search as we normally do while feeding it perfect information and not allowing it to overwrite draws.
User avatar
hgm
Posts: 27790
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Natural TB

Post by hgm »

syzygy wrote:This could be achieved by taking out Qxf6 once it is known to win and then search the rest in the normal way, but that would be a messy solution (and not really what you want anyway, because you also want to search Qxf6 deeper in order to find the shortest mate following that move).
Which would be achieved by re-searching Qxf6 without probing the KRRKBB EGT, as the solution I proposed would do.
syzygy
Posts: 5563
Joined: Tue Feb 28, 2012 11:56 pm

Re: Natural TB

Post by syzygy »

Hmm, I guess the problem here is not really different from the usual "problem" that it is difficult for any non-PV line to overtake a PV line that is doing well. Qxf6 is doing really really well, and for good reasons, so it takes double the normal depth for another line to be discovered as even better.

Probably the only thing that would work is going to multipv = 2 in such a situation...
syzygy
Posts: 5563
Joined: Tue Feb 28, 2012 11:56 pm

Re: Natural TB

Post by syzygy »

hgm wrote:
syzygy wrote:This could be achieved by taking out Qxf6 once it is known to win and then search the rest in the normal way, but that would be a messy solution (and not really what you want anyway, because you also want to search Qxf6 deeper in order to find the shortest mate following that move).
Which would be achieved by re-searching Qxf6 without probing the KRRKBB EGT, as the solution I proposed would do.
Yes, and that is a lot of messy code. Detect that a move is winning, somehow detect that you're not happy with how it is winning, then take it out (or sabotage its search - don't forget to clean the TT) in order to hide the win and give other moves a chance. If nothing better comes up, then play the ugly win anyway.
User avatar
hgm
Posts: 27790
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Natural TB

Post by hgm »

Or make Qxf6 do less well, by re-searching it without probing the inferior EGT.

MultiPV=2 is really no guarantee; in general there would be other moves that make a winning conversion to the same EGT, but just later. And those would then pop up, continuing to mask the 'natural' line.

So any move that returns the TBwin score from conversion to an inferior EGT should be re-searched without such probing, and only the score from that re-search should be accepted as its score. Moves that do not find the TBwin even with probing should be discarded immediately, as they are not proven wins. For the pilot search you could use a null-window just under the TBwin score.

This is in fact very similar to PVS, where you also first search with a null window at the score of the first move. But there you increase beta when the first search fails high, while here you would move the entire window down to the non-probing best score (and switch probing to inferior tables off).
Michel
Posts: 2272
Joined: Mon Sep 29, 2008 1:50 am

Re: Natural TB

Post by Michel »

Probably the only thing that would work is going to multipv = 2 in such a situation...
Or perhaps more generically, not raising alpha at root when a move returns TBwin and beta=>TBwin?

It seems hard to justify this theoretically though...
Ideas=science. Simplification=engineering.
Without ideas there is nothing to simplify.
User avatar
hgm
Posts: 27790
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Natural TB

Post by hgm »

syzygy wrote:Yes, and that is a lot of messy code. Detect that a move is winning, somehow detect that you're not happy with how it is winning, then take it out (or sabotage its search - don't forget to clean the TT) in order to hide the win and give other moves a chance. If nothing better comes up, then play the ugly win anyway.
I don't think it is that bad. Whether probing is on or off should of course be worked into the hash key.

Code: Select all

SearchRoot()
{
  beta = +INF; // no aspiration
  for(depth=1; TimeLeft(); depth++) {
    alpha = -INF; provenWin = FALSE;
    for(ALL_MOVES) {
      int alpha2 = alpha;
      MakeMove();
      if&#40;provenWin && alpha < TB_WIN-1&#41; alpha2 = TB_WIN-1;
      score = -Search&#40;-beta, -alpha2, depth, PROBE_ON&#41;;
      if&#40;score == TB_WIN&#41; &#123; // winning move
        score = -Search&#40;-beta, -alpha, depth, PROBE_OFF&#41;; // re-search
        if&#40;!provenWin&#41; &#123; // it was the first winning move
          alpha = -INF; // forget all previous &#40;non-winning&#41; moves
          provenWin = TRUE;
        &#125;
      &#125; else if&#40;provenWin&#41; &#123; // non-winning move while we already have win
        score = -INF; // kludge to ignore it
      &#125;
      UnMake&#40;);
      if&#40;score > alpha&#41; &#123; // normal minimaxing
        alpha = score; bestMove = currentMove;
      &#125;
    &#125;
  &#125;
&#125;
I would not call that a lot of code.
Last edited by hgm on Mon Jun 13, 2016 12:06 am, edited 2 times in total.