Author: Robert Hyatt
Date: 06:25:48 01/24/00
Go up one level in this thread
On January 24, 2000 at 06:17:37, Amir Ban wrote: >On January 23, 2000 at 22:58:42, Robert Hyatt wrote: > >>On January 23, 2000 at 19:25:55, Tom Kerrigan wrote: >> >>>On January 23, 2000 at 19:20:14, Jeremiah Penery wrote: >>> >>>>>If you can give me an exact description of DB's eval function, I will pay you >>>>>$100 (possibly more), and I will release a program using that function in less >>>>>than a month. >>>>We don't have an exact description, but we do know a lot of what it does. Why >>>>aren't _any_ of the programs now doing certain things that DB _was_ doing? >>> >>>Like what? Please, just give one example. >> >>I mentioned one from Hsu's book: "potentially open files". I've never heard >>of anyone doing it. I have never seen any example of anyone appearing to do it. >>In one of the games in the last match, Hsu (in his book) mentions that a rook >>move (maybe R to the a file somewhere) was made because the eval termed the a >>file a "potentially open file" even though the search couldn't see it opening >>anywhere. This was something that I think Benjamin suggested. I will try to >>find the exact game/move he mentioned tomorrow when I get to the office... >> > >There's something like this in Junior, though defined in other terms. You can >verify that it prefers some closed files over others. Actually it's not >restricted to files only, but applies to other directions. The cost of >implementation in Junior's context is close to zero. I do something with this as well, and it isn't free. Because I evaluate which pawns can advance, which are absolutely blocked, which can't advance because they would be lost, etc. And then use that to evaluate potential pawn levers, etc. It isn't "free" the way I do it, although I do hash the stuff after computing it. But it is very measurably slower. But was necessary to stop the GM/IM approach of blocking the position and getting easy draws. > >I don't know if this is unique, and that's not the point. I guess everyone of >the top programs does things that to others would sound as science fiction, >either because they are not thinking about it in the right way, or because they >are assuming for no good reason that their context for programming such stuff is >the only one possible. > >I'll bet I have one or two good evaluation terms that Deep-Blue doesn't have. >I'll also bet that I have a few that are not practical for them to compute. We >are really in a symmetrical situation. It's true that their context is different >from mine, but it's equally true that mine is different from theirs. I suspect this is true of all. But the point still is, that they can do _anything_ they want. At zero cost. We can't... With us, it is a matter of trading search speed for knowledge content. For them it is a matter of trading _nothing_ for knowledge content. Which is a big advantage... > >I'll buy any statement by Hsu about what he does, but I don't need to buy from >him (or from you) the belief that nobody else does it. > >Amir > > >>There are other things dealing with king safety and pieces attacking around the >>king, through other pieces and pawns, etc.. that are extremely expensive to >>compute. _at the tips_. >>
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.