Author: Robert Hyatt
Date: 14:15:25 08/09/99
Go up one level in this thread
On August 09, 1999 at 15:59:29, Vincent Diepeveen wrote: >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. > Your math is sucking. even with a branching factor of 3, tell me how big the tree is with alpha/beta going to 30 plies. You are _never_ going to get to 30 plies, full-width, I don't care if you can do your eval, make and unmake in zero cycles. Search alone will prevent you from getting that deep. A 30 ply search is absolutely staggering in total nodes searched... >I got at my P100 with such a proggie already without hashtables 17 ply >from openingsposition. > >You simply nullmove everywhere. this is an _exponential_ problem. 17 plies is _not_ 30 plies. > >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.