Changes in Andscacs 0.70

[cdani]

Hi.
I explain some things I changed in Andscacs for this new version. May be someone is interested.

First and most important it’s the move generation part, that now it’s very similar to any modern engine, and of course a lot faster than before. I want to comment that in the function of calculating attacks I prepare a bitboard that contains the valid destination for pieces when the king is in check, so to be able to detect the evasions very quickly simply and’ing the destination with this bitboard. Of course its value is 0 in case of double check.

In the move generation part, in alpha beta now I do:
• Hash move.
• Good captures and promotions.
• Evasions.
• Null move threat, killer 1, killer 2.
• Quiets.
• Bad captures.

And in quiescence:
• Hash move, even if it’s a quiet move. I tried only captures and promotions, and it was clearly weaker.
• Evasions.
• Good captures and promotions (queen, and knight only in case of check).
• If it’s the first level, checks.

I added a hash table for the pawn evaluation that also keeps the king position as a key, as in many other engines. For the moment I use it to store the passed, weak, and supported pawns. Also the two pawn structure bytes (one for white and one for black), that is the primary way I use for evaluating it (one bit per column).

Most work of passed pawns is done every time because it depends for example of the position of other pieces, so it’s not cached except for the general hash table that contains the general evaluation of the position.
This pawn hash is of 1 MB, as I found that increasing it to 2MB helps very little.

I improved the material table:
materialtable[maxqueenw][maxrookw][maxbishopw][maxknightw][idem black]… {
• Value of imbalance
• Value of phase between middle game and end game to not calculate every time
}

General improvement on null move pruning. It’s more aggressive, also reducing to quiescence search, and I used the useful trick of detect if the move is connected to the previous reduced one, to research with full depth.
Added again SEE pruning. Until now I did not fully understand the power of this reduction. It’s really very aggressive and elo wining.

These changes of null move and see pruning had helped a lot to increase the depth of search compared to previous version. Apart from the general speed improvement, it’s the principal cause of strength win on this new version.

Other changes:
• The penalization in move ordering for a piece returning back, it’s not applied if the piece it’s menaced by a pawn.
• For the king safety, count the number of squares attacked In the section of 4x4 squares where the king is (6 sections).
• Diminish the penalization of the king if there are few attackers.
• For mobility, do not count the squares where there are own pawns and king. Also was a big gain, and I’ve seen other engines do like this.
• The pieces that are pinned now have less mobility value.

[Evert]

And in quiescence:
• Hash move, even if it’s a quiet move. I tried only captures and promotions, and it was clearly weaker.

I've wondered about this, but never tried it. How much is this worth?

Most work of passed pawns is done every time because it depends for example of the position of other pieces, so it’s not cached except for the general hash table that contains the general evaluation of the position.

Which passed pawn evaluation terms depend on other pieces?

[cdani]

And in quiescence:
• Hash move, even if it’s a quiet move. I tried only captures and promotions, and it was clearly weaker.

I've wondered about this, but never tried it. How much is this worth?

I decided to try it again so the version I have done it was substantially different. But again the difference was clear. Trying only captures and promotions it's easily 10 elo worst.

Most work of passed pawns is done every time because it depends for example of the position of other pieces, so it’s not cached except for the general hash table that contains the general evaluation of the position.

Which passed pawn evaluation terms depend on other pieces?

* Pieces that support the advance or block the pawn.
* No piece controlling the advance.
* Rook or queen stopping it from behind.

[tpetzke]

• Hash move, even if it’s a quiet move. I tried only captures and promotions, and it was clearly weaker.

Hmm, how often do you get a quiet hash move in QS? How does it enter the hash table ? It should come from the main search of the N-1 iteration so one would expect in the Nth iteration the position is hit well before QS.

I can imagine some cases where one line was extended at N-1 that is not extended anymore in N so you might find a hashed position with a quiet move, but does that really happen that often to make a difference.

[PK]

Regarding non-capture from hash table in qs: half a year ago I have coded something like that accidentally, results were equal, so I deleted it. At that time Rodent wan't using check evasions in qs, so move had to come from normal search and hashed value had to be too low for a beta cutoff. Depending on the engine, such a move can still dispel a threat that quiescence search is structurally unable to deal with, so I imagine there might be some gain from it. Not for me, though.

[tpetzke]

so move had to come from normal search and hashed value had to be too low for a beta cutoff

Yes, but if the position was already encountered in the normal search and you encounter it again in QS I just stop searching this branch and return a DRAW score.

I probe the hash in QS and if I find a hash move I use it (no matter what). It just never occurred to me that this hash move might be quiet (except in the evasion case of course).

[hgm]

And in quiescence:
• Hash move, even if it’s a quiet move. I tried only captures and promotions, and it was clearly weaker.

I did this in Shokidoki, due to a bug. (If there were no captures, it would still search one move.) The result was that it would occasionally crash, due to an infinite recursion.

[PK]

Yes, but if the position was already encountered in the normal search and you encounter it again in QS I just stop searching this branch and return a DRAW score.

"in a normal search" does not necessarily imply "in the sequence of moves leading to the current position"

[lucasart]

And in quiescence:
• Hash move, even if it’s a quiet move. I tried only captures and promotions, and it was clearly weaker.

Interesting. Testing in SF:
http://tests.stockfishchess.org/tests/v ... 75593e5d7b

[cdani]

Analyzing all you have said, I found a bug
I will do some tests and explain the results.
Thanks!