Author: KarinsDad
Date: 10:52:41 05/04/99
Go up one level in this thread
On May 04, 1999 at 12:55:48, Charles L. Williams wrote: >On May 04, 1999 at 11:26:29, KarinsDad wrote: > >>I was wondering how deeply most programs extended the search at a given ply for >>check. >> >>I implemented singular extensions, check extensions, and capture extensions into >>my code last night, but ran into the problem of check extensions potentially >>expanding the extensions into near infinity. >> >>How many checks do most programs consider is enough when extending? >> >>Thanks, >> >>KarinsDad :) >> > > >Do you check for repeating positions? A capture can't repeat, but checks can. >Maybe the same checks are happening more than once. I have not yet implemented draw by repetition (or my hash table for that matter). However, once I have a hash table, I can check each time I get a hit in the table and each time I create a new node (not all nodes will be in the hash table) in the table whether any of my parents have the same position (I could do this now, but it would involve comparing the positions as opposed to comparing the pointers). So, this will partially solve the repeat issue. However, you are right, the main problem here will be in repeats. The secondary problem (which is the one I was trying to address with my question, assuming everyone else checks for repeats in their code) is in positions such as KQK. Even dropping the repeats, most KQK positions could have maybe 63 x 59 positions * 20% of them checks (since only the queen can give check). This would still result in about 750 unique check positions (from one given start position) where most of them are relatively useless. And this is per extension. If you do not have most of these positions in your hash table, you could encounter them over and over again without knowing it in different extensions. Of course, I realize that for KQK, most of the check positions would be in the hash table (and due to the movement of the king, there would be many more check positions in the table) However, when you add in some other pieces, the number of responses to checks could get even greater for some positions (pieces could interpose, multiple different pieces could give check, etc.). So, where you may have 750 unique checks in a given KQK position, you may have 10,000 or more in a more complex position (again, not a large number, but I want to prune it wherever I can). So, this is not an overwhelming problem. It is often difficult to check the opposing king much anyway, so the check extensions would be minimal in a lot of positions with the exception of possibly endgames. Once I check for repeats and have a hash table, a lot of these nodes will be squashed. My question is more one of: at how many ply down does it start to become apparent that the checks are not doing much of anything (worse case possibly)? I could allow all check extensions to occur, however, once you add in capture extensions and singular extensions and possibly some others, this could involve quite a few ply deep where I doubt the gain is often worth the extension. Just a thought. > > >>PS. Will, we realized that our nps is way off. We were compiling the code in >>debug mode as opposed to optimized mode. So, our 100 knps went up to 209 knps. >>Duh! > > >You must have a fast machine. I'm getting around 14knps in release, but then >I've got a 133Mhz Pentium. Looks like I need to take a trip down to my local >computer dealer, and quite possibly optimize my move generation. :) This is on a P3 400 Mhz with super simple material evaluation code (for a lot of positions, the program is still real stupid). It will drop in half at least once I really implement the evaluation. Yes, it is easier to buy faster hardware than to improve the software. :) KarinsDad :) > > >Chuck
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.