Author: Tony Werten
Date: 11:11:14 07/27/02
Go up one level in this thread
On July 27, 2002 at 12:20:15, Ricardo Gibert wrote: >On July 27, 2002 at 01:09:16, Uri Blass wrote: > >>On July 26, 2002 at 22:06:26, Ricardo Gibert wrote: >> >>>We don't very often hear about new ideas in chess programming at this forum. I >>>think this is true for 2 basic reasons: >>>(1) Programmers do not want to part with their good ideas. They keep them as a >>>secret weapon against other chess programs. >>>(2) The idea is discarded as bad. >>> >>>I don't realistically expect programmers to share their good ideas. So what I am >>>requesting here is they share their "bad" ideas instead. Why? The expression, >>>"One persons junk is another persons treasure." The following may be possible >>>with "bad" ideas: >>>(a) It may be that a "bad" idea can be transformed into a good idea with some >>>modification. >>>(b) It may be that 2 "bad" ideas can be combined into one good idea. >>>(c) It may be the idea does not work well for the game they are interested in, >>>but may work very well in another game. Null move is an example of this. >>>(d) The idea is truly bad and sharing and discussing it can save other people >>>time and effort when they get the same idea. >>> >>> >>>I'll offer the following to get things started with an idea I'm not sure is bad, >>>but I don't consider it particularly promising in any case. I'd be happy to be >>>wrong. The idea is basically this: >>> >>>Have the program perform a search that is super selective for one side, but is >>>conservative for the other side and interpret the score returned as an upper >>>bound for the conservative side. You then repeat this search in a 2nd search by >>>switching conservative and selective sides to obtain a lower bound. The idea is >>>you make a gamble. If both return the same PV and score, the gamble pays off and >>>you have saved yourself from searching a lot of nodes you would have otherwise >>>have had to search. >>> >>>If both return a different PV and score, you use the bounds for an aspiration >>>search. You end up searching more slowly overall in this case, but you make the >>>gamble that this won't happen very often. You hope for a net gain on average. If >>>you are short of time and the bounds are close together, you can skip the >>>aspiration search and just assume the lower bound score is correct and use the >>>best move from the 2nd search. The 2nd search will probably be more accurate, >>>since it benefits from the results of the first search via the hash table. >>> >>>So how to search super selectively for one side and conservatively for the >>>other? You can use null move with R=2 for the conservative side and null move >>>with perhaps R=6 for the super selective side. >>> >>>A variation on the above would be to make it "adaptive". If the gambles are >>>paying off almost all the time, the super selective side can automatically >>>increment R. For example an R=6 would increment to R=7. If the gambles are not >>>paying off often enough, the program can lower R a notch for the super selective >>>side. >>> >>> >>>So what are your "bad" ideas? >> >>I had a bad idea about testing adding checks to the first plies >>of the qsearch. >>I believed that if I get better result in the GCP test suite and >>similiar results in games then it means that my implementation >>has no bugs and I was wrong. >> >>I found only after a game that Movei lost on time that the bug >>of losing on time was a result of adding checks in the qsearch >>and the first version that is losing on time was the version >>when I added checks to the qsearch. >> >>The problem is that movei in small part of the cases >>returns beta in the qsearch when it is not justified and in >>the position that Movei lost on >>time it returned a score of mate in 0 in the first ply >>so it stopped to search when it did not have a pv. >> >>I am surprised that the latest version with that >>kind of behaviour could beat GNUchess convincingly. >> >>Uri > >Thanks for responding. > >I was hoping for more participation in this thread, but it looks like I >unwittingly presented two bad ideas instead of just the one intended. ;-( I guess too many people hope their bad ideas will prove to be good some day. I'll give you 2 more. But I leave it up to you to find out why they are bad. 1) Use double nullmove and in your evaluation, give points for the ammount of nullmoves you made. The idea is that if you can reach a normal position wich is 50 centipawns, it's better to reach a position wich is 35 cp but did include 2 nullmoves since obviously your position would be even better if those 2 had been real moves. 2) If you are researching a position ( fe after fail high) and the bestmove from hashtable is a non-capture then don't bother trying capture moves. Since last time there was no capturemove better then the noncapture so it won't be now either. cheers, Tony
This page took 0 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.