Author: Vincent Diepeveen
Date: 15:20:17 12/10/02
Go up one level in this thread
On December 10, 2002 at 12:19:25, Nicolas GUIBERT wrote: a good evaluation cannot use lazy evaluation, sorry. it means your positional score for a single position cannot be big. in DIEP in a normal position it is pawns big. crucial positions the king safety gets like 10 pawns penalty which takes care i don't need to see the mate but evaluate it already correctly as -10 (which gives such a fail low that no further search is lucky needed there). Even if you sacrafice then a piece it doesn't matter. Seems you do not do this in buggy to me. How can you have more than 4000 lines of eval code without having this problem? the difference between a lot of knowledge and a shitload more knowledge is not so big. Because most patterns can get skipped anyway by a single 'if then else' statement. It is kind of binary. The thing that eats system time is the very important patterns that get evaluated a lot of the times and especially loops like mobility loops and king safety loops (in case of chess). In draughts it is other loops that take system time. I can use lazy eval already hardly in napoleon. i still use it, but only a small % of the positions i use it. in diep i do not use it. instead evaluation is so slow that a special evaluation table helps diep to evaluate less positions :) >>I believe that 200 lines are not enough to have a top program but 2000 lines >>with the right knowledge and good search algorithm may be enough. >> >>It may be interesting to know how many lines do programs like >>Junior or Ruffian have. >> > >I probably have the same opinion as Vincent on this subject. Evaluation is >extremely important and very often one single line does the same as 30-40 plies >of search... we completely agree here. it is my feeling that evaluation is the most important thing. i won't say of course that it is possible to evaluate like a human *ever* with just some C code at the current form of computers. Yet other architectures are hundreds of years away from us, so i do not see how to do it otherwise at the moment. >The thing is also that when you know a lot about the game yourself you can't >stand seeing your program play a stupid move because it does not understand >something... And then you write down the thing on your to-do list... And finally >implement the necessary thing... > >You're never satisfied and so you keep adding things to your evaluation >function. > >Moreover, the full evaluation function needs not be used all the time. Lazy >evaluation does the job most of the time. For example, in Buggy, full evaluation >is not so much time-consuming because it is only used 1/4th of the times. > >I do not believe you can build a strong program without a lot of knowledge. > >But for that you need to see the holes by yourself. i partly agree and disagree. a lot of the knowledge you can get from others. but i agree in this sense that fixing knowledge brought by others is so time consuming that you simply either cannot do it or you are busy too long with a few patterns. As a chessplayer i know some things i can look to some positions whether it gives a bonus and i hardly need to look to those patterns again. They are 'in' and working. In Napoleon i still can make the patterns but i always have to check whether they work. So draw conclusions based upon test games. A big problem is of course i hardly can draw those conclusions, so what i do with chess someone else has to do with draughts for me. Me pretty lucky with marcel monteba here. But he makes mistakes there of course which i would never make with chess. for sure it takes more time. What takes biggest time is implementing patterns. When i implement them i need Marcel around and bug him with questions what happens when a piece is on a different place and whether he realizes that if a disk is there that the pattern applies and me as a beginner dislikes it. Best regards, 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.