Fork bug

[Henk]

Skipper lost a two minutes game because it played h5-f6? Should it extend pawn moves ? That probably won't help in other positions. Any suggestions.

[Maybe Ng4 is the cause]

[d] r1q1kb1r/ppp1pppp/2npb3/7n/2PPP3/2N1QN2/PP1B1PPP/2KR1B1R b kq - 2 10

Code: Select all

Depth  Value   Time(seconds)   Nodes
  7      0.14      10.00      169183   e6g4 h2h3 g4d7 d4d5 c6b4 a2a3 b4a6 
  6      0.54       3.28       52005   f7f5 f1d3 c6b4 d3f1 h5f6 
  5      0.54       1.92       31820   f7f5 f1d3 h5f6 e4f5 e6f5 
  4      0.54       0.40        4819   h5f6 f1d3 c8d7 d1g1 
  3      0.54       0.12         910   h5f6 f1d3 c8d7 
  2      0.54       0.08         527   h5f6 f1d3 
  1      0.74       0.04          75   h5f6 

[Henk]

Perhaps extend when queen in check. f7-f5 is a bad move too. Cause is probably f5-f4.

[Aleks Peshkov]

1) Any search should find the fork at depth 3.
2) Decent evaluation should avoid playing Bc8-e6.

[Henk]

Standing pat does not make that possible. When in a fork black simply chooses not to move. Evaluation does not penalize forks. I disabled all reductions/extensions bug still remains.

[Be6 was the first bad move of course]

[Joost Buijs]

The problem is that your search takes too much time to reach a reasonable depth.
There are some delaying moves like Ng4 and f5 that push the direct loss over the horizon.
Your PV at depth 7 looks very normal to me.

10 sec. for depth 7 is not normal, maybe this is plain minimax with everything else disabled?
My engine reaches depth 7 within 10 msec. on this position.

[Maarten Claessens]

The problem is that your search takes too much time to reach a reasonable depth.
There are some delaying moves like Ng4 and f5 that push the direct loss over the horizon.
Your PV at depth 7 looks very normal to me.

10 sec. for depth 7 is not normal, maybe this is plain minimax with everything else disabled?
My engine reaches depth 7 within 10 msec. on this position.

17 knps is a bit slow, so I guess move-generation and/or evaluation need to be more efficient. The number of nodes for a 7 ply search seem sort of ok.

[Joost Buijs]

The problem is that your search takes too much time to reach a reasonable depth.
There are some delaying moves like Ng4 and f5 that push the direct loss over the horizon.
Your PV at depth 7 looks very normal to me.

10 sec. for depth 7 is not normal, maybe this is plain minimax with everything else disabled?
My engine reaches depth 7 within 10 msec. on this position.

17 knps is a bit slow, so I guess move-generation and/or evaluation need to be more efficient. The number of nodes for a 7 ply search seem sort of ok.

17 knps is very slow indeed, I was more or less assuming that Henk doesn't count quiescence nodes otherwise it is difficult to understand.
Let's say that a slow engine written in C does something like 1 mnps on common hardware.
I believe Henk uses C# and CLR, that will be a few times slower, but to get at 17 knps you have to let it run at an RPI-1 or something like that.

[Henk]

Yes I was busy with adding extra evaluation terms. Their computation probably costs too much procession time. And perhaps the more I add the more it resembles a random number.

[Aleks Peshkov]

Fruit 1.0 evaluation is very simple, but it checks against moves like Be6.

[Daniel Anulliero]

I have a penalty when a piece block the pawn d7/e7-d2/e2