SF 191 Why not clear TT?

[Eelco de Groot]

Seeking an explanation in a bit different direction, I don't know anything about operating systems but is it not possible that clearing the hash might cause the operating system, presumably Windows if it's a match against Rybka, change the priority of the thread with the engine? A chessprogram will not always have the same priority if you start it up, I believe Bob posted that, it may take several tries of starting up before you get a good speed and this has to do with the priority given by the OS. Rybka is a process, not a threaded application and that might make another difference maybe. At least, something like this sounds a bit more probable to me than the engine getting hash hits from a previous game?

Regards, Eelco

[mcostalba]

Please feel free to repeat the test (we used 1'+0" TC) and take us to the wonderful world of real medicine

I don't like to do something without at least trying to understand why it might be beneficial.

On the other hand I see that don't understanding why it might be beneficial does not prevent you to joke other people work

[Ralph Stoesser]

Seeking an explanation in a bit different direction, I don't know anything about operating systems but is it not possible that clearing the hash might cause the operating system, presumably Windows if it's a match against Rybka, change the priority of the thread with the engine? A chessprogram will not always have the same priority if you start it up, I believe Bob posted that, it may take several tries of starting up before you get a good speed and this has to do with the priority given by the OS. Rybka is a process, not a threaded application and that might make another difference maybe. At least, something like this sounds a bit more probable to me than the engine getting hash hits from a previous game?

Regards, Eelco

It's proven that there are hash hits from previous games, and the ELO difference is evident. I think Marco is right here.

[micron]

Assuming that one plays all positions twice with inverted colors, it is clear that the second game might benefit slightly from the analysis of the first game if the TC is that short that an important part of the entire game tree can be held in the hash table.

But that is an immediate impact (every second game benefits from the previous game), and not the situation that you describe in the SF-Rybka3 match where "after several hundreds games" there would be some mysterious impact from not clearing the hash. It simply doesn't make sense.

Another short-term (and hence credible) impact could arise if the openings suite is not randomized. If, for instance, these two openings were played in succession:
[ECO "E92"]
[Opening "King's Indian"]
[Variation "Gligoric-Taimanov system"]
1.d4 Nf6 2.c4 g6 3.Nc3 Bg7 4.e4 d6 5.Nf3 O-O 6.Be2 e5 7.Be3 Ng4 8.Bg5 f6 9.Bh4 Qd7 10.Bg3 *

[ECO "E92"]
[Opening "King's Indian"]
[Variation "Gligoric-Taimanov system"]
1.d4 Nf6 2.c4 g6 3.Nc3 Bg7 4.e4 d6 5.Nf3 O-O 6.Be2 e5 7.Be3 Ng4 8.Bg5 f6 9.Bh4 Qd7 10.O-O *

there would be significant overlap of the search trees, and TT remnants from the first opening would be useful for the second.
Such an effect would disappear if the openings suite were randomly permuted before each engine-testing match.

Robert P.

[Ralph Stoesser]

Btw, speaking about king safety eval. You have the following bonus constants for safe non-contact checks

Code: Select all

  // Bonuses for enemy's safe checks
  ...
  const int QueenCheckBonus        = 3;
  const int RookCheckBonus         = 2;
  const int BishopCheckBonus       = 1;
  const int KnightCheckBonus       = 1;

I'd say the KnightCheckBonus should be higher than 1 because a safe check from a knight is more dangerous than a check from a bishop, because the only way to escape from knight's check is to move the king. KnightCheckBonus = 2 works for me in in ultra fast games. (~ +5 Elo)

[mcostalba]

Btw, speaking about king safety eval. You have the following bonus constants for safe non-contact checks

Code: Select all

  // Bonuses for enemy's safe checks
  ...
  const int QueenCheckBonus        = 3;
  const int RookCheckBonus         = 2;
  const int BishopCheckBonus       = 1;
  const int KnightCheckBonus       = 1;

I'd say the KnightCheckBonus should be higher than 1 because a safe check from a knight is more dangerous than a check from a bishop, because the only way to escape from knight's check is to move the king. KnightCheckBonus = 2 works for me in in ultra fast games. (~ +5 Elo)

Thanks Ralph, I will add your tweak to our test queue.

[zamar]

Btw, speaking about king safety eval. You have the following bonus constants for safe non-contact checks

Code: Select all

  // Bonuses for enemy's safe checks
  ...
  const int QueenCheckBonus        = 3;
  const int RookCheckBonus         = 2;
  const int BishopCheckBonus       = 1;
  const int KnightCheckBonus       = 1;

I'd say the KnightCheckBonus should be higher than 1 because a safe check from a knight is more dangerous than a check from a bishop, because the only way to escape from knight's check is to move the king. KnightCheckBonus = 2 works for me in in ultra fast games. (~ +5 Elo)

We will try to confirm your result.

[lech]

Btw, speaking about king safety eval. You have the following bonus constants for safe non-contact checks

Code: Select all

  // Bonuses for enemy's safe checks
  ...
  const int QueenCheckBonus        = 3;
  const int RookCheckBonus         = 2;
  const int BishopCheckBonus       = 1;
  const int KnightCheckBonus       = 1;

I'd say the KnightCheckBonus should be higher than 1 because a safe check from a knight is more dangerous than a check from a bishop, because the only way to escape from knight's check is to move the king. KnightCheckBonus = 2 works for me in in ultra fast games. (~ +5 Elo)

Thanks Ralph, I will add your tweak to our test queue.

Maybe it is worth to check this code too:

Code: Select all

// Enemy knights safe checks and queen proximity
        b = pos.attacks_from<KNIGHT>(ksq) & (ei.attackedBy[Them][KNIGHT] | ei.attackedBy[Them][ QUEEN]) & safe;
        if (b)
            attackUnits += KnightCheckBonus * count_1s<Max15>(b); 

instead of:

Code: Select all

// Enemy knights safe checks
        b = pos.attacks_from<KNIGHT>(ksq) & ei.attackedBy[Them][KNIGHT] & safe;
        if (b)
            attackUnits += KnightCheckBonus * count_1s<Max15>(b); 

In evaluate, I can see anything about danger queen proximity.

[rbarreira]

For testing purposes, it might be a bad idea to make games dependent by not clearing the hash (thus breaking the elo model).

[Eelco de Groot]

Seeking an explanation in a bit different direction, I don't know anything about operating systems but is it not possible that clearing the hash might cause the operating system, presumably Windows if it's a match against Rybka, change the priority of the thread with the engine? A chessprogram will not always have the same priority if you start it up, I believe Bob posted that, it may take several tries of starting up before you get a good speed and this has to do with the priority given by the OS. Rybka is a process, not a threaded application and that might make another difference maybe. At least, something like this sounds a bit more probable to me than the engine getting hash hits from a previous game?

Regards, Eelco

It's proven that there are hash hits from previous games, and the ELO difference is

evident. I think Marco is right here.

Hello Ralph,

Talkchess was very slow this morning, also ChessUSA was off the air for short periods so it must have been the provider or the connection to there and my reply had to wait. My thoughts this morning were that I supposed Marco's theory is possible, in theory , and if entries especially from the opening survive one game, they also have a finite chance of surviving more games and then the chance of "hitting"the same position, probably in the same or similar opening increase. Then you would get an effect that real learning can take place, the same opening position is searched at least one ply deeper than nominal because already in hash, position is stored again and because of the deeper draft can survive longer, gets a deeper draft next time etc.? I never studied the hashing conditions from Glaurung or Stockfish, so this is guessing about the exact mechanism. But it would explain why the effect would get stronger after a significant number of games, only then the chances of repeating openings, if you use a book with not too deep lines, will be great enough. And I think the effect would be much stronger at short timecontrols, because there are diminishing (playing strength-)returns from deeper searches and much more overwrites if there is limited hash compared to the total number of entries to be stored over those games.

Best, Eelco