Dirt wrote: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....
I wasn't trying to convince you to change. Now that I understand it's only rarely even a minor issue.
Still, you might consider helping out future neophytes by explaining <HT> and <EGTB> in the crafty.hlp file, or somewhere else. It's not a piece of information that is easy to search for.
AndrewShort wrote: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...
Interesting, so it's a small strength hit even. That's good to know.
Thanks again for running the test, always good to have more information . I use this in GarboChess, and I had assumed it would help more than hurt, but now I might have to look at only doing it near the root so the PV can still be acquired.
Zach Wegner wrote:They're two different approaches that are basically equivalent. I think it's the difference between PVS and negascout, but I'm not sure which is which (nor do I care ). The advantage of Glaurung's method is that the node might actually be a fail low. If it is, then the >alpha method will search every move with an open window, which wastes time. For the moves>1 method, however, if the node is really a PV node and the best move is not the first, it will waste time researching that move.
Both methods end up searching just about the same amount of nodes. What you might try (though I haven't) is searching with a zero window if either moves>N or best_score>alpha.
I am definitely am going to play with this. Glaurung's method does _way_ less work for "all" nodes (nodes whose moves don't raise alpha).
And as for "pv" nodes (where alpha is raised and there is no beta cutoff), then glaurung's method is the same as PVS if the pv move happens to be the first move. As you say, only issue is if the pv move is not the first - then Glaurung's method does more work, because it will unsuccessfully try a zero window search on moves 2-x, and have to retry with an open window on those moves. I would think that Glaurung's huge superiority with "all" nodes would more than offset the cost of pv nodes where the pv move is not first. That's just my intuition, based on the percentage of nodes that are 'all' nodes, and the % of pv nodes where the pv move is not first (or in first n moves, as you suggest trying). Has this been tested on Bob's famous cluster?
AndrewShort wrote:another thing i noticed in the source:
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)
Because it would truncate my PVs and make my transposition table code somewhat more complicated (I would have to add a PV node flag to the transposition table entries, in order to avoid using the results of a non-PV-node search at a PV node) without giving me anything in return. I did a few speed tests long ago, and couldn't measure any difference at all between using and not using TT pruning at PV nodes. Bob's test results (found elsewhere in this thread) seem to confirm this.
