Author: Miguel A. Ballicora
Date: 09:30:32 12/28/01
Go up one level in this thread
On December 28, 2001 at 10:41:42, Uri Blass wrote: >On December 28, 2001 at 09:45:15, Severi Salminen wrote: > >>>if you extend the qsearch too much you may get >>>often irrelevant positions that you analyze. >>> >>>The problem is that one of the players could win the game >>>by a move that is not included in the qsearch. >>> >>>The probability for it increases when >>>the number of plies increase and it seems clear >>>to me that if you search deep enough the score that >>>you have is often not relevant because you can be almost sure >>>that the score in the qsearch for one of the previous nodes >>>is wrong so you earn less information >>>from searching more nodes and at some point common sense >>>says that you need to stop because you pay more than you get. >> >>The problem is that you cannot safely terminate qsearch at some arbitary depth. >>There is no way to know when the qsearch info is complete or when it isn't. >>Qsearch is approximation and that's the way it's supposed to be. Limiting it >>will only create problems as you will _allways_ get a really bad score when >>limiting it during a capture sequence. And this will give totally wrong results >>as opposed to non-limited qsearch. But as soon as I get home I'll test it and >>report maybe some results. It is of course true that qsearch doesn't give >>totally accurate scores but it really shouldn't as it is selective in its >>nature. It's only function is to dynamically resolve the capture sequences in >>frontier nodes. It would be equally illogical to limit the number of attackers >>in a SEE function. The results would be also very wrong. Think qsearch as >>dynamic SEE, well, that's what I do. >> >>Severi > >I think that I will not continue to argue about this point >but it does not mean that I agree. > >I know that selective search is something that >I cannot be sure about but there is a difference >if there is a result that I can be sure in 90% that >it is correct tatctically and if there is a result that >I can be sure only in 40%. > >It may be interesting to look at many qsearches of more than >7 plies in order to find out how many of them have >a tactical mistake that means that >there is a better move at some ply >that is not considered in the qsearch. > >Uri The point is that this is always a trade off. The main question is: How many nodes on average do you save limiting the qsearch in this way? 5%? 20%? 80%? if it is 5% may be it is not worth it because what you save is too small to hace an effect on strength and you risk being blind in a certain capture fest position. You save 80%? then, there is something seriously wrong with your qsearch, but limiting would be good until you fix the original problem. Sorry Uri, your idea is not original. In fact, I believe that most of the ideas of everybody has been recycled somehow or were tried and discarded before or already implemented. But, if you want to have a top program it would not be wise to think that you have an original idea and hide it. Chances are that it is not entirely original and you will waste your time testing things that other people have already done. Rafael's idea of an incomplete flag is interesting. I have a similar design for a flag for other purposes (three repetition flag, so I do not store this position in the hash table). If the score is influenced by a 3 rep in the tree this position is not stored in the hashtable. It does not solve all the problems but I think that it solve some. I never heard of this, but I am sure somebody tried something similar. The general dea of a flag that returns information about tricky things done in the tree deserves to be explore. Rafael's case is interesting because it will return: "the score of the qsearch is x.xx, but, hey! this value depends on a branch I cut off!" If you think it is not practical, it will be of extreme help to debug your implementation. How many times this this flag will be set on at the root of your qsearch? 1:1000000000? then you can remove the flag altogether in the release version and keep on the debug version of your program. The general idea is interesting, not only for qsearch cases. Since I have the design already, maybe I will try it. Regards, Miguel
This page took 0.01 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.