Author: Ricardo Gibert
Date: 09:20:15 07/27/02
Go up one level in this thread
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. ;-(
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.