Author: Vincent Diepeveen
Date: 09:51:41 10/11/02
Go up one level in this thread
On October 11, 2002 at 11:32:11, Jeremiah Penery wrote: >On October 11, 2002 at 11:15:14, Vincent Diepeveen wrote: > >>On October 11, 2002 at 11:11:01, Jeremiah Penery wrote: >> >>>On October 11, 2002 at 10:46:16, Gian-Carlo Pascutto wrote: >>> >>>>On October 11, 2002 at 10:38:12, Jeremiah Penery wrote: >>>> >>>>>On October 11, 2002 at 08:09:59, Vincent Diepeveen wrote: >>>>> >>>>>>you skip one important point. Because of a simplistic evaluation >>>>>>it was able to get 12.2 ply. If you use a more complex evaluation >>>>>>then you do fullwidth not get 12.2 ply at all, but more like 10.5 ply. >>>>> >>>>>It did evaluation in hardware. The complexity of the function has NOTHING to do >>>>>with the speed of computing it. This is obviously something you don't >>>>>understand, or you wouldn't be writing crap like the above, or the below. >>>> >>>>You missed Vincents point. His point was that a more complicated >>>>evaluation (with bigger positional scores) will slow down the search >>>>compared to (for example) a piece-square evaluation, because it causes >>>>more instability. >>> >>>Having a more complicated evaluation does not require having bigger positional >>>scores, but I agree that in the general case that is what happens. However, >>>search instability depends on the correctness of your evaluation function and >>>your move ordering - the variability of the evaluation function is secondary. >>>If your evaluation is very complex, but also extremely accurate, it will be far >>>more stable than a simpler but less accurate evaluation will yield. >> >>If you always return 0 as score, then any move will give a cutoff. > >I wouldn't call that an evaluation function. > >>If you are material based, just material, then capturing a piece will >>give usually a cutoff. > >For the overly simple case(s) (only material or similar), you're correct. I was >using 'simple' evaluation to mean something like piece/square tables plus a few >basic positional things. Material only is uninteresting. > >>If you have a complex evaluation, then you do not know in advance whether >>trying a capture is going to give a cutoff. Obviously it's harder to order >>moves too. If you knew ahead which move would going to give a cutoff for you, >>why the hell would you do a search anyway? > >Why is it harder to order moves when you have a more complex evaluation? It >would seem to depend more on the accuracy of the evaluation, rather than the >complexity. With your example of a piece square table move ordering is still pretty trivial: expected best move = material + SEE(position) + psq[to] - psq[from] The more factors add to your evaluation function the harder it is to predict which branch is better. The above way to order moves is very quick. Of course it's possible to get a better move ordering, for example in DIEP, by statically evaluating all moves first. That drastically reduces number of nodes needed to finish a ply. However you evaluate a lot of positions there extra. It slows down my nodes a second by more than a factor 2.
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.