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...
bob wrote: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 wrote: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.
bob wrote: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 wrote: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.
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.