Author: Robert Hyatt
Date: 07:13:29 08/09/99
Go up one level in this thread
On August 09, 1999 at 06:46:21, Vincent Diepeveen wrote: >On August 09, 1999 at 05:55:49, Frank Schneider wrote: > >>On August 07, 1999 at 08:17:49, Vincent Diepeveen wrote: >> >>>On August 05, 1999 at 22:43:29, Robert Hyatt wrote: >>> >>>>On August 05, 1999 at 17:13:28, Tom King wrote: >>>> >>>>>On August 04, 1999 at 20:00:49, Robert Hyatt wrote: >>>>> >>>>>[snip] >>>>>> >>>>>> >>>>>>I find the following: >>>>>> >>>>>>using SEE to order captures in the q-search, without eliminating any, will >>>>>>shrink the tree about 10% over using something simple like MVV/LVA. But the >>>>>>SEE code will likely cost you more than 10% (unless you are a bitmap program >>>>>>where this can be done fairly efficiently). >>>>>> >>>>>>using SEE to eliminate losing captures can speed you up another 50%, or a factor >>>>>>of two, which is very significant. And no matter how slow your SEE code is, >>>>>>that become a 'winner' of an idea. >>>>> >>>>>I'm seeing a big speedup - it's just the (possible) loss of accuracy which >>>>>concerns me. Having said that, my Q search is pretty "quick and nasty" anyway, >>>>>although I do still do things like probe the hash tables. >>>> >>>> >>>>This is only my opinion, but I spend my time working on the full-width part of >>>>the search (extensions, etc.). The q-search already has _so many_ errors in it >>>>(it is highly selective since throwing out everything but captures is a drastic >>>>step, of course) that I don't trust it at all. I just want it to handle simple >>>>hung pieces and not much else... I'll trust my extensions to find the deep >>>>tactical tricks since then I won't be overlooking pins, forks, skewers, etc. >>>> >>>>When you think about it like that, shrink the q-search and use those nodes in >>>>places where they are more useful. >>>> >>>>Just an opinion, of course... >>> >>>Right, my opinion is different. A good qsearch will give more accurate >>>scores for leafs, so in a set of leafs X, for all leafs x in X we will have >>>a more reliable score. >>> >>>So whatever plydepth we get, we will get a positional more trustworthy score, >>>which with backtracking will result in a better and more reliable score. >>Thats right, but without SEE it is very difficult to get as deep. And a depth >>n+1 score with SEE is probably better than a depth n score without SEE. >>Thats the tradeoff, I think. >> >>Frank > >My god you gotta be joking. Of course you can search easily very deep >with a SEE. > >If you make your program another few clocks more stupid then you can >search with a million nodes a second at PII450. > >As it's so damned stupid you can safely forward prune last few plies too. > >Then you can also remove all extensions from it including >most check extensions. > >Then you invent you can search even deeper by completely stripping >all knowledge including piece square tables. You just search >material based. > >Should get like 22 ply at tournament level easily. > Not a prayer of getting that deep. Even if your eval is 90% of the total search, you would only go 10X faster. That is _not_ 22 plies deeper. Even without search extensions... >Don't ask me how poor it plays though. > >SEE is a virus which worked in the past a little, but will slowly >die next few years. > :) This virus can be "deadly". >>> >>>Greetings, >>>Vincent
This page took 0.01 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.