Limiting EGTB Probing For Short Search Times

[brianr]

I know EGTBs (Nalimov anyway) are cached, but what do others do, if anything, to skip EGTB probes for very short search times?

Crafty does something like this

Code: Select all

if (ply <= shared->iteration_depth && TotalAllPieces <= EGTB_use &&
      Castle(ply, white) + Castle(ply, black) == 0 &&
      (CaptureOrPromote(tree->curmv[ply - 1]) || ply < 3))

I guess the thinking is that short times are covered by ply < 3.

Tinker has been skipping EGTB probes for searches expected to be less than 2 seconds.
This seems too conservative to me.

Thanks,
Brian

[bob]

I know EGTBs (Nalimov anyway) are cached, but what do others do, if anything, to skip EGTB probes for very short search times?

Crafty does something like this

Code: Select all

if (ply <= shared->iteration_depth && TotalAllPieces <= EGTB_use &&
      Castle(ply, white) + Castle(ply, black) == 0 &&
      (CaptureOrPromote(tree->curmv[ply - 1]) || ply < 3))

I guess the thinking is that short times are covered by ply < 3.

Tinker has been skipping EGTB probes for searches expected to be less than 2 seconds.
This seems too conservative to me.

Thanks,
Brian

No... the ply < 3 just forces it to do egtb probes during the first 2 plies (assuming we are in a 5 piece ending). Normally it only does egtb probes after a capture, since if we were already in a 5 piece ending, we would have already probed and exited. But I need to probe for the first 2 plies even if the last move was not a capture, so that I get egtb scores in the search when I start out in an egtb position...

All I do is that for an N ply search, I only probe in the first N plies, which ignores extension-added depth...

[wgarvin]

I know EGTBs (Nalimov anyway) are cached, but what do others do, if anything, to skip EGTB probes for very short search times?

Crafty does something like this

Code: Select all

if (ply <= shared->iteration_depth && TotalAllPieces <= EGTB_use &&
      Castle(ply, white) + Castle(ply, black) == 0 &&
      (CaptureOrPromote(tree->curmv[ply - 1]) || ply < 3))

I guess the thinking is that short times are covered by ply < 3.

Tinker has been skipping EGTB probes for searches expected to be less than 2 seconds.
This seems too conservative to me.

Thanks,
Brian

No... the ply < 3 just forces it to do egtb probes during the first 2 plies (assuming we are in a 5 piece ending). Normally it only does egtb probes after a capture, since if we were already in a 5 piece ending, we would have already probed and exited. But I need to probe for the first 2 plies even if the last move was not a capture, so that I get egtb scores in the search when I start out in an egtb position...

All I do is that for an N ply search, I only probe in the first N plies, which ignores extension-added depth...

The idea of only probing after captures is interesting, but does it actually buy you anything? I would have thought that a good system for interior node recognition would make this unnecessary (probes would only be done for endings which you actually have a database answer for, and thus implicitly only for positions after a converting move).

OTOH, if you find it kind of expensive for Crafty to recognize the positions that are worth probing (or if, for example, it does a bunch of unavoidable work for 5-piece positions even if you don't have the particular database for them) then it sounds like a cheap way to avoid some of the cost.

All I do is that for an N ply search, I only probe in the first N plies, which ignores extension-added depth...

Is the idea that anything which could blow up the time taken by search extensions is bad?

[bob]

I know EGTBs (Nalimov anyway) are cached, but what do others do, if anything, to skip EGTB probes for very short search times?

Crafty does something like this

Code: Select all

if (ply <= shared->iteration_depth && TotalAllPieces <= EGTB_use &&
      Castle(ply, white) + Castle(ply, black) == 0 &&
      (CaptureOrPromote(tree->curmv[ply - 1]) || ply < 3))

I guess the thinking is that short times are covered by ply < 3.

Tinker has been skipping EGTB probes for searches expected to be less than 2 seconds.
This seems too conservative to me.

Thanks,
Brian

No... the ply < 3 just forces it to do egtb probes during the first 2 plies (assuming we are in a 5 piece ending). Normally it only does egtb probes after a capture, since if we were already in a 5 piece ending, we would have already probed and exited. But I need to probe for the first 2 plies even if the last move was not a capture, so that I get egtb scores in the search when I start out in an egtb position...

All I do is that for an N ply search, I only probe in the first N plies, which ignores extension-added depth...

The idea of only probing after captures is interesting, but does it actually buy you anything? I would have thought that a good system for interior node recognition would make this unnecessary (probes would only be done for endings which you actually have a database answer for, and thus implicitly only for positions after a converting move).

OTOH, if you find it kind of expensive for Crafty to recognize the positions that are worth probing (or if, for example, it does a bunch of unavoidable work for 5-piece positions even if you don't have the particular database for them) then it sounds like a cheap way to avoid some of the cost.

All I do is that for an N ply search, I only probe in the first N plies, which ignores extension-added depth...

Is the idea that anything which could blow up the time taken by search extensions is bad?

Assumption is that I have all the 3-4-N piece endings, where N is currently 4, 5 or 6. Anytime I make a capture, _and_ the number of pieces is <= N, then I do a probe. There is no need to probe after anything except a capture, if you have all the files up to N that you are using. Promotions are irrelevant since if you have a set for xxxxxp, then you already know the mate score, without needing to probe after xxxxxq is reached.

It saves a significant amount of time by limiting the number of probes that need doing...

[wgarvin]

No... the ply < 3 just forces it to do egtb probes during the first 2 plies (assuming we are in a 5 piece ending). Normally it only does egtb probes after a capture, since if we were already in a 5 piece ending, we would have already probed and exited. But I need to probe for the first 2 plies even if the last move was not a capture, so that I get egtb scores in the search when I start out in an egtb position...

All I do is that for an N ply search, I only probe in the first N plies, which ignores extension-added depth...

The idea of only probing after captures is interesting, but does it actually buy you anything? I would have thought that a good system for interior node recognition would make this unnecessary (probes would only be done for endings which you actually have a database answer for, and thus implicitly only for positions after a converting move).

OTOH, if you find it kind of expensive for Crafty to recognize the positions that are worth probing (or if, for example, it does a bunch of unavoidable work for 5-piece positions even if you don't have the particular database for them) then it sounds like a cheap way to avoid some of the cost.

All I do is that for an N ply search, I only probe in the first N plies, which ignores extension-added depth...

Is the idea that anything which could blow up the time taken by search extensions is bad?

Assumption is that I have all the 3-4-N piece endings, where N is currently 4, 5 or 6. Anytime I make a capture, _and_ the number of pieces is <= N, then I do a probe. There is no need to probe after anything except a capture, if you have all the files up to N that you are using. Promotions are irrelevant since if you have a set for xxxxxp, then you already know the mate score, without needing to probe after xxxxxq is reached.

It saves a significant amount of time by limiting the number of probes that need doing...

It seems odd to me, because I can't see how you can get into a situation where you are doing probes that fail, and don't cut off the tree? I suppose it could happen if your set of databases were incomplete, or if maybe there were a corrupt database? Anyway, whatever works.

When I think about probing databases from search, I think about it in the context of a complete set of engine-specific bitbases (which I realize is not the case for Crafty). With custom bitbases, interior-node recognizers would be needed to have good representations of the bitbases, and handle the different ways of accessing them and heuristically scoring the positions. But EGTBs don't need that because they are all stored in the same format and one code path can handle them all, and (Pieces <= N) is sufficient for recognizing them.

[bob]

That was my point. With complete tables, you only need to probe after captures that leave you with a total of N or less pieces on the board. If you don't get a hit there, you can't possibly get a hit by just moving a piece or promoting a pawn. But only if you have _all_ tables.