Author: Sune Fischer
Date: 11:04:52 01/19/04
Go up one level in this thread
On January 19, 2004 at 12:28:09, Robert Hyatt wrote: >>It works just fine. >> > >I will say this again with authority: It works just fine _most_ of the >time. But _not_ all of the time. I've explained why, carefully. Unless >you have some way to realize that a table entry is a PV entry when you store >it, so that you can say "never overwrite this entry" then you _will_ suffer >losses. You will get short PVs. And you will get PVs with wrong moves.. > >There is simply nothing you can do about it, any more than you can fix the >draw problem with hashing... You can say it with all the authority you want, but you can't prevent me from testing it and making up my own mind about it. It's not perfect, I never said it was, but it is a good compromise. How often do you actually study the moves 12 plies out in Crafty's PV when the lines scroll down? ..yes, that's what I thought. :) >>My explanation is that once the PV has actually reached that kind of depth the >>search has been going on for so long that old PV entries have been replaced. > >That is certainly the problem in any of the cases being discussed. The only >solution is to have a table so big you _never_ overwrite, and then on top of >that you need a replacement policy that _never_ replaces an existing entry >even if the hash signature matches, if the existing entry is a PV position. Of >course I know of no way to identify a PV position at the point you store it... Actually, it seems to work just fine doing nothing out of the ordinary :) >>>I now do it the correct way, backing the PV up along with the score... >> >>IMO the PV is a non-essential feature, having to do it "correctly" messes up the >>code and slows down the engine. > >It doesn't cost .1%. Just add the code, and then see how many times you >actually use it. Hint: only when alpha < score < beta. With PVS that >is essentially _never_. > >You might think it is used all the time, but in reality it is not very >frequent. Hehe, and this from the guy who allows illegal king captures in the SEE :) Trust me Bob, there are many things that could make the program stronger by being more accurate, however the PV output string isn't one of them. >>And? >>All engines produce not very bright move way out in the PV. > >Yes, but the moves they display are the moves that led to the position that >produced the score that was backed up. Unless you get a hash cutoff, that's bad or is it? Ironic really. :) >Using the HT to produce the PV doesn't >guarantee that. There is a small chance another PV can overwritte the original PV entry, with the same position and store a different move. However, if you think about that the chance is not very big, and if one really cared one could assert that the depth stored was enough as well, if deeper that's good if too shallow cut the PV. >It is not about the quality of the moves. It is about the correlation of the >moves to the score being scored. That was what Martin first pointed out. A >piece was hanging according to the PV. According to the score all was even. I can't speak for Shredder, have no idea what it is doing. Perhaps there is no other way to extract the PV. >>You can't really rely on anything but the first few moves to be good, unless it >>ends in a mate or or tactical win. >> >>As long as you extract PV moves you won't see outright blunders, if you do you >>need to debug your search :) > >You can definitely see outright blunders. When you probe to find the PV >move at ply=11, the entry you find will usually be for the right position, >but the wrong depth. That can certainly produce a blunder, such as leaving >a mate in 1 that the q-search couldn't find. If it's a PV move it's a PV move, which means the search thinks it is a good move for _both_ sides. How can that possibly be a blunder unless your search is broken? (Again, have no idea what is going on in Shredder). -S.
This page took 0.02 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.