Author: Stuart Cracraft
Date: 08:10:10 08/08/04
Go up one level in this thread
On August 07, 2004 at 18:42:03, Dan Honeycutt wrote: >On August 07, 2004 at 17:06:30, Stuart Cracraft wrote: > > >>I still think it is due to my use of material-only/pc-sq and >>an attack-finding routine, in support of see, that is as slow >>as doing a makemv(). > >Stuart: > >I don't think so. Put your draw detection and incheck verification in the >quies() I posted elsewhere and try that. Even with a simple eval(), not >searching captures that don't have a snowball's chance has got to help you. If >you think your see() is too slow try a poor man's see: > >if(captured_piece_is_defended) value = victim_value - attackor_value; >else value = victim_value; > >You can use something like your incheck() routine for >captured_piece_is_defended. I used this till I had my see() working and it did >just about as well. It's fast but obviously not as accurate as a full see(). >But even a full see() is just a guess - its not that often that a sequence of >exchanges plays out on a single square. > >Dan H. See most recent thread on SEE. In longer searches of a minute or so, SEE is saving 50% on nodes and time for the same ply. Given this, I am certainly more than willing to admit it would produce good tournament results. This is for when the tree has enough nodes in the quiescence to make SEE valuable... this occurs when there are longer searches. For my testing of 300 problems at 1 second per problem, the overhead of SEE, my attacker/defender-finder results in a poorer score. But at 5 seconds per problem, the result is 2% better for SEE in terms of total problems solved. I suspect the difference would be even higher for great time per problem. So the SEEers have convinced me and I thank them all for their patience and input. Stuart
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.