Author: Vincent Diepeveen
Date: 12:59:29 08/09/99
Go up one level in this thread
On August 09, 1999 at 10:13:29, Robert Hyatt wrote: >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... What eval? I just incremental counted piecevalues. Actually 22 ply would be bad. 30 ply should be no problem either. I got at my P100 with such a proggie already without hashtables 17 ply from openingsposition. You simply nullmove everywhere. But yes, it played 1.a3. It only had killermoves to prevent falling for tactical jokes, after that the trick was it first generated pawnmoves, starting with a-pawn to a3. etcetera. I forgot what i did with captures, i bet i took a few, but not too many as i hardly sorted the moves, cuz it took too much systemtime. Prog ran at a P100 at 250k nodes a second. When i added these 'sophisticated' ways of sorting, killermoves, and getting captures the speed dropped to only 110k nodes a second, same speed also for the one WITH piece square table, but that one just searched 9 ply or so. What i did in qsearch for this dumb&stupid proggie were 2 captures to any piece then only recaptures and captures to higher or equal pieces. So it didn't use SEE yet, which would give at least another few plies, and it didn't use forward pruning yet. After this experiment i realized how much tricks are found by just the positional part of my prog, and how much qsearch (rebel qsearch as example?) and extensions near leafs (genius?) pick up. It took a long time to see for example that it can't take the pawn with Nxe5?? after 1.e4,e5 2.Nf3,Nc6 3.Bc4,Nd4 reason for that was of course becuz i didn't extend checks, as that was way too expensive initially. Just checking whether the piece that moves gives a check appeared to be quite cheap later. >>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.