Author: Uri Blass
Date: 10:46:32 12/28/01
Go up one level in this thread
On December 28, 2001 at 12:30:32, Miguel A. Ballicora wrote: >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. I guess it is usually not more than 5% but there are practical positions when it can be also 80%. The risk of being blind already happens if the line of the qsearch is long and reducing the risk does not give as much as it gives in the root position. Other ideas like limiting the number of moves in the qsearch when the qsearch is deep enough may be also productive and I think that I am going to use them. I have the feeling that most programmers of the free programs and also part of the programmers of the commercial programs simply copy algorithms without thinking if it is a good idea to change them. The motivation that I have to write a chess program is mainly because of the fact that I believe that there are typical mistakes that chess programs(including commercial programs) do. 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 I may consider that idea but I think that before considering it there is another thing that can help me to improve my program. It is a program that writes my chess tree as a pgn file in a language that Fritz or Junior interface can understand. I already asked in another post if there is a free program that does it and got no response. The program may get every new legal move as a string(e2e4 or e8g8) It can also get the depth of the node as a parameter and based on this information it should generate a pgn file that Fritz interface can understand. I believe that looking at the trees of my program can help me to think about better ideas but I cannot imagine the position clearly based only on the text of the moves and looking at the positions in Fritz's interface can help me. I have almost no experience with writing into text files in C and this is one of the reason that I did not try to do the relevant program by myself and prefered to concentrate on other things. Uri
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.