Author: Ratko V Tomic
Date: 19:00:32 10/13/99
Go up one level in this thread
>>Even the 18 plies in complex middle game (which may be 2-3 years off) still >>hinge on the same old simple-minded evaluation of the terminal nodes. > >You think DB uses 'the same old simple-minded evaluation'? > I would say the terminal node evaluation (excluding the table-base lookup, of course) in any program is simple-minded comapared to human judgment. By itself, this evaluation makes it roughly equivalent to one ply "search" setting, which should lose to just about any chess player. Regarding DB vs other chess programmers, I would think that the best commercial programs use more sophisticated algorithms than DB. That's human nature -- if hardware will do 200 Mnps without programmer breaking a sweat, the drive to conceive something new here to squeeze an extra 10 or 50 Mnps won't be nearly as strong as if you're using 40 knps micro (as in case of Hiarcs on a 400 Mhz Celeron). Thus the micro chess programmers have to think much harder to produce the highest quality evaluation functions, while DB programmers can stuff almost anything that comes to mind, and very likely don't put nearly as much thought and creativity into it as the micro guys do. As the saying goes, the necessity is mother of invention. >>If I (a mere 2100 player over a decade ago) can get Fritz 5.32 etc to just >>shuffle rooks on the back rank with no clue what to do next, > >But if you let Fritz search more ply (15, 20, ...ply), it will eventually find >something better to do than shuffle rooks. Other programs may not have this >problem at all. > Depends on type of positions. In some positions there is virtually no (humanly) non-obvious tactics hinging critically on a move choice 20-30 plies earlier. Whether at ply 20 Fritz will find something (that's still at least 5 years from the current full depths, though), depends on what it is looking for. It may find how to gain an attack on one extra square, which may mean nothing, or may even make things worse 15 plies later. While deeper is on average better, if it were always better, the same program running on a two times as slow machine would always lose to the program on the faster machine. That's not true, though. If, say, the factor 2 in speed brings 70 ELO points, the (W-L)/(W+L)=70/400=0.175, giving then W/L= 1.42 or giving percentage wins about 60% for the faster version. So quite a good deal of time the shallower search gave _ultimately_ better moves. Now if one were to develop more systematic theory (for human use) on what kind of positions have such property and strategic methods to go along to produce such positions, that could negate much of the computer depth gain. There are also artificially constructed (for this purpose only) games where deeper search produces mostly worse moves (than e.g. a random pick of moves). The reason for all these counterintuitive phenomena is that minimax as used in chess is not really picking the best among the exact values of the nodes but the best of the guessed values (guessed by some rules of thumb, which are nowhere near 100% valid). The programs also have no idea how much error is involved in these estimates but treat them as if they were true values to be minimaxed. A program will, without a second thought, go for massive complications, showing near term win of additional material, even when their current material is already winning for any half good player. A rational human player will convert the advantage to a whole point in the most safe, least double edged way. >> You don't need the best move to win, just a good enough move (chess >> programmers don't seem to know this, as yet). > >So do you want the chess programs to say "Ok, I have 3 choices for moves, and >all look like they're 'good enough'. I think I'll choose the one that I think >is the worst of the 3, because it's still 'good enough'." ? > No, I didn't say that. What I said is that if, say, a program sees a 12 ply sure win of a piece, with otherwise quiet and "normal" position, then there is no need to pursue alternatives to its choices which at ply 14 might gain a piece plus pawn. It should pursue deeper only the branch which it already discovered winning a piece, to verify the gain isn't poisoned, otherwise it should be happy to have found one very likely way to the whole point. Programs seem to calculate as if your score will go up point and half if you can win in 30 moves instead of 45 moves. As of now, it won't, thus no need to waste its time (which may be needed later in the game if the oponent tries something desperate) as if it will. (Of course, being happy with "good enough" would have to be turned off when solving test suites, otherwise they might not find the solution.) >A different move almost always is better if it's found at greater depth. If that were so, the same program on 400 Mhz PII would win "almost always" to the program on 200 Mhz Pentium, and that's not the case at all, while in fact the faster one will win only about 60% of games. >> I'll >use your example: Say at depth 10, the program sees that it can do Qxb2, >winning a pawn. If it searches to depth 11, say, it may see that it's getting >attacked, since it doesn't have its queen to defend. So it picks a different >move, that doesn't win the b2 pawn, but does prevent your attack. > >Is this not a better move, found because of greater depth? > But at ply 1-9 it may have not seen a win of the pawn at all, so it wouldn't have gotten drawn into the queenside pawn hunting at all. As suggested earlier, it all depends on types of positions, and while the typical present-day human style positions may be vulnerable to deeper search in a statistically significant number of cases, I have no doubnt that a different style, from openings to strategic guidlines, exist which would shift the probabilities making the extra depth, while not necessarily do more harm, but at least do not much good for the typical alpha-beta searcher.
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.