Author: Tony Werten
Date: 11:14:59 07/27/02
Go up one level in this thread
On July 27, 2002 at 14:11:14, Tony Werten wrote: >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 PS if someone manages to make these bad ideas good, I'd appreciate an email on the how. 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.