Queen mobility

[Henk]

Another misevaluation (See depth 6). In this position c7-c5 is a bad move. For it allows the queen to go to d5. Rb3 and black can resign.

Perhaps adding a "queen on open file" bonus is enough.

[d] 1k4r1/1pp4p/pb1p3P/5pB1/P1PP1P2/5R2/1P2P2q/2KQ4 b - a3 0 32

Code: Select all

Depth  Value   Time(seconds)   Nodes
  8     -0.70       7.64      162893   b8a8 b2b4 c7c5 b4c5 d6c5 d4d5 b6a5 
  7     -0.70       3.23       68546   b8a8 b2b4 c7c5 b4c5 d6c5 
  6     -0.70       1.23       26027   c7c5 d4d5 b8a8 f3e3 
  5     -0.70       0.51       10737   g8e8 e2e3 e8g8 
  4     -0.70       0.13        2488   b6a5 b2b3 a5b6 
  3     -0.70       0.03         759   b6a5 b2b3 a5b6 
  2     -0.70       0.01         377   b6a5 
  1     -0.70       0.00          84   b6a5

[Henk]

Yes adding a "queen on open file" bonus helped. (No c7-c5)

Code: Select all

Depth  Value   Time(seconds)   Nodes
  8     -0.90       6.44      150768   b6a7 f3f1 g8c8 e2e3 h2h3 d1e2 c8f8 
  7     -0.90       2.12       50541   b6a7 f3f1 g8c8 e2e3 c8e8 f1h1 h2f2 
  6     -0.90       0.84       18005   b6a7 f3f1 g8c8 e2e3 c8e8 
  5     -0.90       0.45        8390   b6a7 f3f1 b7b6 e2e3 g8c8 
  4     -0.90       0.20        3149   b6a7 f3f1 b7b6 
  3     -0.90       0.07         763   g8g6 f3a3 
  2     -0.90       0.05         246   g8h8 
  1     -0.90       0.04          79   a6a5 

[bob]

Another misevaluation (See depth 6). In this position c7-c5 is a bad move. For it allows the queen to go to d5. Rb3 and black can resign.

Perhaps adding a "queen on open file" bonus is enough.

[d] 1k4r1/1pp4p/pb1p3P/5pB1/P1PP1P2/5R2/1P2P2q/2KQ4 b - a3 0 32

Code: Select all

Depth  Value   Time(seconds)   Nodes
  8     -0.70       7.64      162893   b8a8 b2b4 c7c5 b4c5 d6c5 d4d5 b6a5 
  7     -0.70       3.23       68546   b8a8 b2b4 c7c5 b4c5 d6c5 
  6     -0.70       1.23       26027   c7c5 d4d5 b8a8 f3e3 
  5     -0.70       0.51       10737   g8e8 e2e3 e8g8 
  4     -0.70       0.13        2488   b6a5 b2b3 a5b6 
  3     -0.70       0.03         759   b6a5 b2b3 a5b6 
  2     -0.70       0.01         377   b6a5 
  1     -0.70       0.00          84   b6a5

I don't understand your output. How do you get a 3 ply PV with a 5 ply search? Whatever my nominal search depth is, I ALWAYS get a PV that long or longer... This is not so much an evaluation issue as it is a lack of depth issue. But before you can tackle that, you need to figure out what is wrong with your PVs themselves...

Also, unless you are running on a watch or blender processor, 20K nodes per second seems impossibly slow...

[D Sceviour]

I don't understand your output. How do you get a 3 ply PV with a 5 ply search? Whatever my nominal search depth is, I ALWAYS get a PV that long or longer... This is not so much an evaluation issue as it is a lack of depth issue. But before you can tackle that, you need to figure out what is wrong with your PVs themselves...

In Crafty for PV hash entries, the path from the position to the terminal node that produced the backed-up score is saved so that the PV can be completed on a different hash hit. If the save is not done then sometimes the entire PV cannot be seen after a hash hit. I am not sure about the theory here, but does the full PV remain in the hash table, and can be recovered on the next iteration? In other words, the PV display is merely cosmetic and does not mean the PV line is wrong.

[bob]

I don't understand your output. How do you get a 3 ply PV with a 5 ply search? Whatever my nominal search depth is, I ALWAYS get a PV that long or longer... This is not so much an evaluation issue as it is a lack of depth issue. But before you can tackle that, you need to figure out what is wrong with your PVs themselves...

In Crafty for PV hash entries, the path from the position to the terminal node that produced the backed-up score is saved so that the PV can be completed on a different hash hit. If the save is not done then sometimes the entire PV cannot be seen after a hash hit. I am not sure about the theory here, but does the full PV remain in the hash table, and can be recovered on the next iteration? In other words, the PV display is merely cosmetic and does not mean the PV line is wrong.

You can't have a hash hit after a 2 ply search. If you look at his early PVs they appear to be short every other iteration or so which suggests a bug. The Hash can't be the reason for the short PVs unless this search has a really serious bug.

[D Sceviour]

I don't understand your output. How do you get a 3 ply PV with a 5 ply search? Whatever my nominal search depth is, I ALWAYS get a PV that long or longer... This is not so much an evaluation issue as it is a lack of depth issue. But before you can tackle that, you need to figure out what is wrong with your PVs themselves...

In Crafty for PV hash entries, the path from the position to the terminal node that produced the backed-up score is saved so that the PV can be completed on a different hash hit. If the save is not done then sometimes the entire PV cannot be seen after a hash hit. I am not sure about the theory here, but does the full PV remain in the hash table, and can be recovered on the next iteration? In other words, the PV display is merely cosmetic and does not mean the PV line is wrong.

You can't have a hash hit after a 2 ply search. If you look at his early PVs they appear to be short every other iteration or so which suggests a bug. The Hash can't be the reason for the short PVs unless this search has a really serious bug.

No, a hash hit is not probable after ply 2 unless there are extensions. However, if the display path depth were the only thing wrong then a short PV display would not be a serious error. The PV path depth would be the ply of last hash hit, unless a special hash table for recovering the PV was used.

[bob]

I don't understand your output. How do you get a 3 ply PV with a 5 ply search? Whatever my nominal search depth is, I ALWAYS get a PV that long or longer... This is not so much an evaluation issue as it is a lack of depth issue. But before you can tackle that, you need to figure out what is wrong with your PVs themselves...

In Crafty for PV hash entries, the path from the position to the terminal node that produced the backed-up score is saved so that the PV can be completed on a different hash hit. If the save is not done then sometimes the entire PV cannot be seen after a hash hit. I am not sure about the theory here, but does the full PV remain in the hash table, and can be recovered on the next iteration? In other words, the PV display is merely cosmetic and does not mean the PV line is wrong.

You can't have a hash hit after a 2 ply search. If you look at his early PVs they appear to be short every other iteration or so which suggests a bug. The Hash can't be the reason for the short PVs unless this search has a really serious bug.

No, a hash hit is not probable after ply 2 unless there are extensions. However, if the display path depth were the only thing wrong then a short PV display would not be a serious error. The PV path depth would be the ply of last hash hit, unless a special hash table for recovering the PV was used.

That's not the point here. He is showing a raw search, and at depth=3 there is no way a 2 ply PV can happen unless it is a repetition or hash hit. And at depth=3 a hash hit is impossible. As I said, before worrying about queen mobility and evaluation, you have to start with a search that is correct, and this looks broken to me. Whether this is a bug in the display output, a bug in collecting the PV, or a bug in improperly backing things up in the search, it is still a bug that needs fixing, otherwise progress is going to be slow and difficult.

[Henk]

At least there was a bug in extension implementation. Extension became negative so it jumped into Quiescence Search.

Code: Select all

Depth  Value   Time(seconds)   Nodes
  7     -0.86       5.59      118053   g8e8 e2e3 b6a5 d1d3 e8f8 d4d5 h2g1 
  6     -0.86       1.86       36566   g8e8 e2e3 b6a5 d1d3 h2g1 d3d1 
  5     -0.86       0.64       11826   g8e8 e2e3 b6a5 d1d3 h2g1 
  4     -0.90       0.27        3921   g8e8 e2e3 e8f8 d1f1 
  3     -0.90       0.10        1181   g8e8 e2e3 h2g2 
  2     -0.90       0.06         324   g8e8 e2e3 
  1     -0.90       0.05          77   h2h5 

[bob]

At least there was a bug in extension implementation. Extension became negative so it jumped into Quiescence Search.

Code: Select all

Depth  Value   Time(seconds)   Nodes
  7     -0.86       5.59      118053   g8e8 e2e3 b6a5 d1d3 e8f8 d4d5 h2g1 
  6     -0.86       1.86       36566   g8e8 e2e3 b6a5 d1d3 h2g1 d3d1 
  5     -0.86       0.64       11826   g8e8 e2e3 b6a5 d1d3 h2g1 
  4     -0.90       0.27        3921   g8e8 e2e3 e8f8 d1f1 
  3     -0.90       0.10        1181   g8e8 e2e3 h2g2 
  2     -0.90       0.06         324   g8e8 e2e3 
  1     -0.90       0.05          77   h2h5 

There you go. That looks rational from a search perspective. I assume this is a minimal eval test (or material only)? The individual moves seem a bit off the wall. g8e8 e8f8, for example.