A van Kessel wrote: >> decades it has been understood that a chess program with a better >> evaluation function improves MORE with increasing depth than one with a >> lesser evaluation function so it appears that Go is not unique in this >> > > Well, isn't that trivial? > I don't think it is. It took us 20 years to learn this. This is not the same as saying that it's better to have a strong evaluation function, this was never in question. What wasn't always understood is that stronger evaluation functions scale better.
I think most people had the opposite intuition because it seems reasonable to believe that a weaker evaluation function "should respond more to depth in order to solve problems a stronger evaluation function wouldn't have." It turns out this is not true, but until you know better, it's not obviously silly to think that. I would even say that for about 20 years or more programmers chased the illusion that speed mattered more. I think you can answer the question of what is more important by just answering the scaling question. In chess evaluation quality is more important than speed. (However, in both games speed is still important - you cannot have an arbitrarily slow evaluation function just because it is slightly "better" than a fast one.) At the highest end of the scaling curve, it must be the case that a weaker evaluation function improves more than a strong one, simply because a strong one may already be very close to perfection. At some point, when perfect play is reached, they perform equally. That reasoning once caused me to believe that weaker evaluation functions would ALWAYS tend to close the gap with increasing CPU power, but evidently the gap widens until some point is reached at which it then gradually converges. - Don > suppose, you have a "perfect" evaluation function, but you > add a random value to each of it's evaluation values. > Once your S/N value reaches 1/1, adding more probes/playouts will > not yield a better signal. So you reach a "soft horizon": you got > > stuck in the fog. > Adding false heuristics (cutting corners) such as pseudo-liberties, > or don't-play-inside-own-territory may even worsen the case. > > IIRC this has been described before on the the mailinglist, > when alpha/beta was still fashionable. > > AvK > _______________________________________________ > computer-go mailing list > [email protected] > http://www.computer-go.org/mailman/listinfo/computer-go/ > > _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
