Andscacs - New version 0.72

[cdani]

Detailed changes:

• Penalization for queen stopping passed pawn, in middlegame and endgame.
• LMR was starting only at iterative deep 5. Not anymore. Also I increased a little the reductions.
• Some bugs solved and added knowledge of endgames:

• o KRPKR
  o KRKB
  o KRKN
  o KRKP
  o KQKP
  o KQKR
  o KRPKB
  o KBPKB
  o KBPPKB
  o KBPPKN when the pawns are doubled
  o KNPK
  o KQKRP
  o KBPK
  o Two minors against one minor and some pawns are often draw.

• Move ordering. On quiets, if history of a move is 0, add various types of bonus depending of the move. Previously was doing the same irrespectively of the value of history.
• Modified capture extension so it lets extend more the first root move:
if (captured && is_pv && ((looking_first_root_move && current_iterative_deepening_depth <= initial_iterative_deepening_depth + 5) || current_iterative_deepening_depth <= initial_iterative_deepening_depth))
extend;
• Open king is worst if opposite castles.
• Time management:

• o If there are often changes in the best move, assign more time.
  o If it has more time than the opponent, assign more time.

• Do not do some one of the different types of prunes when is endgame.
• I realized that was not necessary to evaluate the position if it was check. So a slight improvement in speed.
• Rook/queen evaluation. Improved bonus for 6th, 7th, 8th rank.
• Calculate king safety only if it’s necessary.
• Try to guess if in the child node will be a prune thanks to the evaluation value, and do it before trying the move. So “eval prune, parent node”.
• Tried various combinations of pv limitations on alpha_beta stuff. So now:

• o Eval pruning - child node: it does not has it.
  o Futility pruning: child node: yes.
  o Razoring: yes.
  o Null move: yes.
  o Futility pruning v2: yes.
  o Internal iterative deepening: different depths depending of is_pv
  o Move count based pruning for the last depth: yes
  o Late move pruning: no
  o See pruning: yes
  o Futility pruning: parent node: no.

• Double move refutation, Discocheck-like.
• Some terrible big bugs
• Counter moves: refutation to piece to destination square.
• “Piece hash” or whatever the name is, if it exists. I did not find it anywhere. Is a hash of two moves (like killers) related to the hash of all pieces minus king and pawns. It’s just a first try and is not optimized. So in fact the key is (hash ^ pawn_hash). It has very little size to not bother other engines. I will try a lot more variations and bigger sizes. May be someone wants to try it and post his results. Seems that there is some strength to win for all the engines.

http://www.andscacs.com/

[mar]

Nice!

[Graham Banks]

Should be interesting to see the gains.

[op12no2]

Very interesting Daniel. I'm doing to have to steal not calling eval if in check...

[cdani]

Very interesting Daniel. I'm doing to have to steal not calling eval if in check...

Was not my idea. I found it in some engines.

[xmas79]

...I found it in some engines.

Hi Daniel,
it seems trivial to me... STM in check means not a quiet position, STM cannot stand pat there. I thought it was in all engines....

BTW, do you have any guess on the gain of all such changes? Huge improvements in IMHO! Congrats!

Natl.

[cdani]

Hi Daniel,
it seems trivial to me... STM in check means not a quiet position, STM cannot stand pat there. I thought it was in all engines....

It was simply like this from who knows when, and I never thought about it again

BTW, do you have any guess on the gain of all such changes? Huge improvements in IMHO! Congrats!

Thanks! Sure. I will publish more details.

[cdani]

BTW, do you have any guess on the gain of all such changes? Huge improvements in IMHO! Congrats!

I put here the approximated gains of each change. The first ones are at 30+0.04 seconds and the last ones as 25+0.03 seconds.

• Penalization for queen stopping passed pawn, in middlegame and endgame.
+10
• LMR was starting only at iterative deep 5. Not anymore. Also I increased a little the reductions.
+3 +4
• Some bugs solved and added knowledge of endgames:
o KRPKR
o KRKB
o KRKN
o KRKP
o KQKP
o KQKR
o KRPKB
o KBPKB
o KBPPKB
o KBPPKN when the pawns are doubled
o KNPK
o KQKRP
o KBPK
o Two minors against one minor and some pawns are often draw.
-1
• Move ordering. On quiets, if history of a move is 0, add various types of bonus depending of the move. Previously was doing the same irrespectively of the value of history.
+12
• Modified capture extension so it lets extend more the first root move:
if (captured && is_pv && ((looking_first_root_move && current_iterative_deepening_depth <= initial_iterative_deepening_depth + 5) || current_iterative_deepening_depth <= initial_iterative_deepening_depth))
extend;
+5
• Open king is worst if opposite castles.
+3
• Time management:
o If there are often changes in the best move, assign more time. +5
o If it has more time than the opponent, assign more time. +6
• Do not do some one of the different types of prunes when is endgame.
+3
• I realized that was not necessary to evaluate the position if it was check. So a slight improvement in speed.
+7
• Rook/queen evaluation. Improved bonus for 6th, 7th, 8th rank. And solved a bug.
-4
• Calculate king safety only if it’s necessary.
+10
• Try to guess if in the child node will be a prune thanks to the evaluation value, and do it before trying the move. So “eval prune, parent node”.
+9
• Tried various combinations of pv limitations on alpha_beta stuff. So now:
o Eval pruning - child node: it does not has it.
o Futility pruning: child node: yes.
o Razoring: yes.
o Null move: yes.
o Futility pruning v2: yes.
o Internal iterative deepening: different depths depending of is_pv
o Move count based pruning for the last depth: yes
o Late move pruning: no
o See pruning: yes
o Futility pruning: parent node: no.
+0
• Double move refutation, Discocheck-like.
+15
• Some terrible big bugs
+19
• Counter moves: refutation to piece to destination square.
+4
• “Piece hash” or whatever the name is, if it exists. I did not find it anywhere. Is a hash of two moves (like killers) related to the hash of all pieces minus king and pawns. It’s just a first try and is not optimized. So in fact the key is (hash ^ pawn_hash). It has very little size to not bother other engines. I will try a lot more variations and bigger sizes. May be someone wants to try it and post his results. Seems that there is some strength to win for all the engines.
+6

In total 105. At slower time controls I guess is less than this.

[Daniel Anulliero]

Very interesting Daniel. I'm doing to have to steal not calling eval if in check...

Was not my idea. I found it in some engines.

Hi
Lol never thought about it too

Then if we're Incheck in the start of qs, we need to test if mate/stalemate before stand pat and captures right?
If not ,some captures can be illegal moves and qs become false?
Thanks for your lights and sorry for my poor english!

[lucasart]

“Piece hash” or whatever the name is, if it exists. I did not find it anywhere. Is a hash of two moves (like killers) related to the hash of all pieces minus king and pawns. It’s just a first try and is not optimized. So in fact the key is (hash ^ pawn_hash). It has very little size to not bother other engines. I will try a lot more variations and bigger sizes. May be someone wants to try it and post his results. Seems that there is some strength to win for all the engines.

Would love to try, but I don't understand your explanation. The piece hash is the key restricted to pieces. OK. But what do you use it for?