when to try zero window search

[Michael Sherwin]

I do not understand this stuff very well, but I read(?) somewhere that not using the hash to produce cutoffs in the PV was so no PV line would be truncated due to the hash. So, you get to see lots of long pretty PV's printed. And any downside seems to be negligible.

[bob]

That seems broken to me. Why ignore exact scores in the PV, which is the biggest part of the search, and then use them in non-PV moves and prune away moves that might be better or worse because of the drawing potential? It doesn't make sense to ignore useful information like EXACT scores, IMHO. It sounds like a kludge someone tried that solved a specific problem. But I'll bet it hurts far more than it helps, overall...

It should add minimal overhead to the search if all of the non-PV nodes are already in the hash (which they hopefully are). It does seem more "correct" to not return the scores, as the hash key ignores repetitions.

I can see two things happening:
1. Believing the PV is a draw, when its actually not - this could be pretty bad.
2. Believing the PV is winning/losing when it's actually drawing - seems less bad, but could still cause problems.

Now, whether this is a good tradeoff or not is an excellent question. I'd be very interested if you tried this change on the cluster with Crafty .

Tried that a couple of years ago when it first came up. Here's the issue. If you feel it is correct on PV nodes, then why not on every node you get a hash hit on. And also why just exclude EXACT scores since bounds are also wrong for the very same reason.

I will try to run 32K games with no PV EXACT hash hits to see what it does...

[gladius]

Tried that a couple of years ago when it first came up. Here's the issue. If you feel it is correct on PV nodes, then why not on every node you get a hash hit on. And also why just exclude EXACT scores since bounds are also wrong for the very same reason.

I will try to run 32K games with no PV EXACT hash hits to see what it does...

I agree, it's a tricky issue to decide on. I think the idea behind it in Fruit (which is where it first appeared?) was that he wanted PV nodes to be very precise, while all/cut nodes have more leeway for doing "incorrect" things.

Thanks for giving it a shot on the cluster! Actually being able to measure these sorts of changes is really cool, and will lead to a pretty big step forward in understanding I think.

[Alessandro Scotti]

it only uses the hash to prune in non-pv nodes. why not also in pv nodes? I don't understand that. (It uses the hash in pv nodes for move ordering only)

Helps getting nice, longer PV's and does not cost much for that.

[michiguel]

it only uses the hash to prune in non-pv nodes. why not also in pv nodes? I don't understand that. (It uses the hash in pv nodes for move ordering only)

Helps getting nice, longer PV's and does not cost much for that.

This reason alone is a huge benefit. People should think sometimes like chess players (customers) rather than programmers. A engine that is used for analysis is more useful if it says "why" a certain move is the best in that particular position. I cannot see why there is a measurable hit in performance.

Having said that, it is still in my to do list

Miguel

[bob]

it only uses the hash to prune in non-pv nodes. why not also in pv nodes? I don't understand that. (It uses the hash in pv nodes for move ordering only)

Helps getting nice, longer PV's and does not cost much for that.

This reason alone is a huge benefit. People should think sometimes like chess players (customers) rather than programmers. A engine that is used for analysis is more useful if it says "why" a certain move is the best in that particular position. I cannot see why there is a measurable hit in performance.

Having said that, it is still in my to do list

Miguel

I ran the test twice today to see what the effect is. It seems to be a -2 Elo change, but with 80,000 games total played, that is within the error bar so it isn't a dead cinch that it is worse. But two 40K game runs came out almost identical, so there is some confidence that it it a tiny bit worse...

[Dirt]

it only uses the hash to prune in non-pv nodes. why not also in pv nodes? I don't understand that. (It uses the hash in pv nodes for move ordering only)

Helps getting nice, longer PV's and does not cost much for that.

This reason alone is a huge benefit. People should think sometimes like chess players (customers) rather than programmers. A engine that is used for analysis is more useful if it says "why" a certain move is the best in that particular position. I cannot see why there is a measurable hit in performance.

Having said that, it is still in my to do list :-)

Miguel

I remember it took me years to figure out what was meant by a PV ending in <HT>. It's still a little annoying when there's little displayed except that.

[bob]

it only uses the hash to prune in non-pv nodes. why not also in pv nodes? I don't understand that. (It uses the hash in pv nodes for move ordering only)

Helps getting nice, longer PV's and does not cost much for that.

This reason alone is a huge benefit. People should think sometimes like chess players (customers) rather than programmers. A engine that is used for analysis is more useful if it says "why" a certain move is the best in that particular position. I cannot see why there is a measurable hit in performance.

Having said that, it is still in my to do list

Miguel

I remember it took me years to figure out what was meant by a PV ending in <HT>. It's still a little annoying when there's little displayed except that.

Right. But think of all the searching you _didn't_ have to do to get that best move and score, and you saved that time to use elsewhere in the search, perhaps going a ply deeper. Doing this is not free. Doesn't seem to be _that_ expensive, but it isn't free....

[Eelco de Groot]

it only uses the hash to prune in non-pv nodes. why not also in pv nodes? I don't understand that. (It uses the hash in pv nodes for move ordering only)

Helps getting nice, longer PV's and does not cost much for that.

This reason alone is a huge benefit. People should think sometimes like chess players (customers) rather than programmers. A engine that is used for analysis is more useful if it says "why" a certain move is the best in that particular position. I cannot see why there is a measurable hit in performance.

Having said that, it is still in my to do list

Miguel

I remember it took me years to figure out what was meant by a PV ending in <HT>. It's still a little annoying when there's little displayed except that.

With good old Rebel MS-DOS you not only saw the full PV, but Ed Schröder's machinecode output also displayed exactly what move was being searched and by following the variations develop you could watch how and where the search was doing its work, in real time. Not only good for understanding how a chessprogram works but you knew when the moves started to appear and disappear faster that soon a whole ply would be finished and could make a better guess how long the next plydepth PV would take. For the actual users of a chessprogram that is of course invaluable and worth a few elo, let alone its worth to the programmer for debugging purposes. Sadly in later Rebel versions the PV was constructed from the hashtable, like other programs did. Last Rebel program that gave full information about the search in progress was Rebel 9 I think. Maybe it's a bit faster this way but, in hindsight, it is just my opinion but I think this actually may have hurt Rebel's progress, because of the loss of transparency, maybe the same goes for several other programs.

Regards, Eelco

[wgarvin]

[..]

I remember it took me years to figure out what was meant by a PV ending in <HT>. It's still a little annoying when there's little displayed except that.

Right. But think of all the searching you _didn't_ have to do to get that best move and score, and you saved that time to use elsewhere in the search, perhaps going a ply deeper. Doing this is not free. Doesn't seem to be _that_ expensive, but it isn't free....

If it causes essentially no ELO difference over 80,000 games, and ends up having some user benefit not related to playing strength, then maybe its better than "free".