Reduction Question

[jd1]

Hi,

Just a quick question. I just tried adding a reduction into the engine that I'm working (Toga II). However, contrary to my expectations, the time-to-depth increases slightly. Does that mean the idea is no good? It is a gain of 5 elo after 10000 games in testing.

Jerry

[Don]

Hi,

Just a quick question. I just tried adding a reduction into the engine that I'm working (Toga II). However, contrary to my expectations, the time-to-depth increases slightly. Does that mean the idea is no good? It is a gain of 5 elo after 10000 games in testing.

Jerry

Toga already does reductions, so it would be helpful to know exactly what you added.

How did you time the speedup/slowdown? There can be significant error in timings (just like tests) so what you see as a slowdown might actually be a slight speedup.

Also, it is possible for a change that "should" make the program faster to make it slower. This can happen for a number of reasons. If you thrown out captures in quies you can slow down the search (if you throw out the wrong ones) for example.

[jd1]

Thanks for your help, Don. The idea is to reduce moves as follows:

Code: Select all

if (!reduced // not already reduced
      && new_depth < depth // or extended
      && depth >= 5 
      && SearchCurrent&#91;ThreadId&#93;->null_no_threat 
      && SearchCurrent&#91;ThreadId&#93;->height_no_threat == height 
      && played_nb >= 1
      && !move_is_tactical&#40;move,board&#41; && !move_is_dangerous&#40;move,board&#41;
      && eval&#40;board,alpha-ValuePawn,alpha-ValuePawn+1,ThreadId&#41; <= alpha - ValuePawn&#41;&#123;
          new_depth --;         
          reduced = true;                                   
      &#125;

The two "strange" conditions are that if the null-move search returns a value < beta && value >= alpha (with alpha-1 = beta), with a fail soft framework we can (and often) get value < alpha. So my thinking was that if value == alpha our position is probably still quite good, we can give a null move and our position only just fails low. Therefore I am reducing in the next ply (if the depth is high enough and eval is <= alpha-margin) all moves except for captures, passed_pawn_moves and the first move. If the move we made was not good usually the first move refutes it. Does this make sense?

I have just checked more thoroughly, also with a longer time control and the time to depth does become less - the problem was I just tried "go depth x" from the starting position.

Jerry

[lucasart]

I also did double reductions in DiscoCheck, but my conditions are somewhat different:
- only reduce quiet moves by 2 plies, never captures (captures with SEE < 0 are reduced by 1 ply)
- use a counter that only counts quiet moves, not captures, call it cnt
- the cnt threshold should be an increasing function of the depth
- also added a safeguard against reducing moves that threat the queen in a credible manner. although that part of code was eventually removed later, after more proper testing proved it useless.
https://github.com/lucasart/chess/commi ... 60ed391c63

[jd1]

I also did double reductions in DiscoCheck, but my conditions are somewhat different:
- only reduce quiet moves by 2 plies, never captures (captures with SEE < 0 are reduced by 1 ply)
- use a counter that only counts quiet moves, not captures, call it cnt
- the cnt threshold should be an increasing function of the depth
- also added a safeguard against reducing moves that threat the queen in a credible manner. although that part of code was eventually removed later, after more proper testing proved it useless.
https://github.com/lucasart/chess/commi ... 60ed391c63

Thanks Lucas! I think I will try your way and see whether it works for me.

Jerry