Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Crafty Static Evals 2 questions

Author: Robert Hyatt

Date: 07:52:27 02/25/04

Go up one level in this thread


On February 25, 2004 at 05:56:16, martin fierz wrote:

>On February 24, 2004 at 11:25:23, Robert Hyatt wrote:
>
>>On February 24, 2004 at 11:17:32, martin fierz wrote:
>>
>>>On February 24, 2004 at 11:06:00, Robert Hyatt wrote:
>>>
>>>>On February 24, 2004 at 10:37:21, martin fierz wrote:
>>>>
>>>>>On February 24, 2004 at 10:19:51, Anthony Cozzie wrote:
>>>>>
>>>>>>On February 24, 2004 at 09:32:08, martin fierz wrote:
>>>>>>
>>>>>>>On February 23, 2004 at 23:05:58, Robert Hyatt wrote:
>>>>>>>
>>>>>>>>On February 23, 2004 at 18:52:36, Geoff Westwood wrote:
>>>>>>>>
>>>>>>>>>Hi
>>>>>>>>>
>>>>>>>>>I was perusing the latest table of results, Crafty's static eval of 2 of the
>>>>>>>>>passed pawn positions were interesting.
>>>>>>>>>
>>>>>>>>>Assuming I havent made a mistake in the cutting and pasting
>>>>>>>>>
>>>>>>>>>Position 1
>>>>>>>>>8/4k3/8/7P/1P6/3p4/4p3/4K3 b - -; id "PP-00004"
>>>>>>>>>
>>>>>>>>>[D]8/4k3/8/7P/1P6/3p4/4p3/4K3 b - -
>>>>>>>>>
>>>>>>>>>Crafty reckons this is +4.8 (good for white). This is rather clever as although
>>>>>>>>>the black king could catch either of the white passed pawns, it cannot stop
>>>>>>>>>both. Also blacks 2 advanced pawns cant do anything as the white king gobbles
>>>>>>>>>them up easily. Only Crafty and Tinker understand this position statically. Any
>>>>>>>>>tips on what the algorithm is to sort this one out ?
>>>>>>>>
>>>>>>>>
>>>>>>>>This is the idea I have reported here before, pointed out (demanded to be fixed
>>>>>>>>in fact) by a GM friend of mine.  The idea is that the two separated pawns are
>>>>>>>>better than the two connected passers.  The king stops the two connected passers
>>>>>>>>easily until the enemy king supports them, meanwhile the split passers walk on
>>>>>>>>in...
>>>>>>>
>>>>>>>i don't like the generality of your statemtent here, but - it is a small price
>>>>>>>to pay if it's right in most cases. which perhaps is the case. anyway, here's my
>>>>>>>question:
>>>>>>>
>>>>>>>what does your static eval say for the black king on e6/e5/e4/e3 ? i wouldn't be
>>>>>>>surprised if it got it wrong in some cases now...
>>>>>>>
>>>>>>>cheers
>>>>>>>  martin
>>>>>>
>>>>>>The question is always "what do you put in the search, what do you put in the
>>>>>>eval" <shrug>.
>>>>>
>>>>>sort of - for me the answer is clear. the point i wanted to make (not the first
>>>>>time, BTW) is that returning huge evaluations in positions like this may not be
>>>>>a good idea because they are *very* sensitive to details like king position.
>>>>>e.g. if i got it right, then it's a white win with the king on e6, but a black
>>>>>win with the king on e5. do you really want to allow your static eval to return
>>>>>a white win when it might be a black win?
>>>>>of course you can say that if you get it right 60% of the time, it is better
>>>>>than returning an equal eval in this kind of position. but wouldn't it be better
>>>>>then to return something like +- 1 so that you never blunder into this when you
>>>>>are e.g. a piece up and see this type of transition?
>>>>>i generally try to return huge evals only when i am very certain that they are
>>>>>correct.
>>>>>
>>>>>cheers
>>>>>  martin
>>>>
>>>>You are looking at this the wrong way.  If you want 100% accuracy, you will die
>>>>from it.  :)
>>>
>>>hehe, i never claimed i wanted 100%. i think your score should reflect the
>>>amount of certainty you have.
>>>
>>>>If you don't do what I do, you will like connected passers, and in 90% of the
>>>>games I will beat you when that comes up.
>>>
>>>nope. your rule "connected passers are strong when there are many pieces,
>>>separated passers when there are few pieces" is good in some cases. but it is
>>>not good in quite a lot of cases IMO, with no disrespect to your GM friend. if i
>>>make a more accurate version of that rule, i will beat you when it comes up :-)
>>>
>>
>>Perhaps you misunderstood my idea.  Connected passers are better when there are
>>any pieces on the board.  But split passers are better when there are none.  I
>>just have a smooth transition from one to the other to avoid yet another problem
>>called "an evaluation discontinuity"..
>
>yes, in this case i misunderstood, but i think my misunderstanding is better
>than your understanding :-)
>connected passers are better with many pieces, split passers are better against
>*some* pieces. and of course when there are no pieces left. split passers which
>are one file apart are worse than connected passers usually. it all depends on a
>lot more than just a one-line-rule...

I don't usually do "one line rules".

First, I don't agree with the first part of your statement.  I don't think split
passers are better than connected passers with "some pieces" on the board.  I
just think they are better as pieces come off.

Second, if you look at my code, split passers are better as the distance between
them goes up.  One file apart is no good.  2 or more gets progressively better
as they become progressively harder to stop with a lone king.

>
>i don't know whether i should believe the eval discontinuity thing. i know
>somebody recently quoted a paper on this, but it's just a fact: exchanging any
>pieces necessarily changes the evaluation. sometimes not by very much. big
>changes are usually the exchange of the queen, the exchange of the last rook,
>the exchange of the last piece. these eval discontinuities are *real*. i don't
>believe in smoothing them out. perhaps if you write an eval with discontinuities
>it's harder to get it right that everything fits in with each other, and that's
>why it's supposed to be bad?!

No.  When you have a discontinuity, you give the search something to play with,
and it can choose when to pass over the discontinuity, sometimes with
devastating results..

You are free to feel however you like of course, since as you write your own
program you have to make decisions.  But you will eventually conclude that this
is a problem that has to be addressed, as the skill of your program begins to
peak.





>
>
>
>>
>>The king distance is an easy one to fix.  IE my passed pawn race code already
>>handles it correctly, in that a pawn can "run" if the king is close enough to
>>defend the queening square before the opponent's king can get there, as one
>>example of multiple special cases I handle...
>>
>>
>>
>>>> Do you want to be right 100% of the
>>>>cases you recognize, leaving 95% as "unclear and probably lost" or do you want
>>>>to be right in 90% of the total cases?
>>>>
>>>>I choose the latter...
>>>>
>>>>No doubt it can be made more accurate.  But no doubt that without it, it is even
>>>>less accurate...
>>>
>>>that wasn't my point. i assume you are returning a +5 for white even with the
>>>black king on e5 and you can lose games where you are completely winning because
>>>of this.
>>
>>Maybe.  But most likely not.  Wait for my hash collision paper to come out, for
>>some _eye-popping_ information about the overall tree search space and how
>>resistant to errors it really is.
>
>it won't pop *my* eyes. i once reduced hash key sizes in my checkers program
>beyond all sensible settings, because there was a discussion here about whether
>you really need 64-bit keys. in my checkers program, i have 64 bit keys, but
>effectively it's only using about 52 bits. i have about a 20 bit part which is
>used for the hashindex with %, and of the remaining 44 bits i store only 32 as a
>check. i reduced those 32 down to about 8 (!!) bits and in 100 test positions
>only saw one different move played IIRC. ridiculous, i must have lots of
>collisions there. unfortunately, i didn't count the collision number, or write
>down the results - but i know what you're talking about!
>
>> But that aside, remember that I do a decent
>>search as well, _before_ doing static evaluations.  If you put the king at e4,
>>it doesn't take much of a search to see that black wins, and the eval can't hide
>>that because I only evaluate positions reached in the q-search.
>
>right, if you are already in this position. but there was a position about 12-16
>ply before this, and there you just might have chosen the wrong move because of
>this. very, very unlikely, i know. but still...
>
>cheers
>  martin
>
>>> my theory is that you should try to recognize who is winning, but
>>>differentiate between being certain that it's a win, and just guessing it's a
>>>win. there are very many positions where you can be 99% certain, and for these
>>>returning a +5 is ok IMO. for those where it's not so clear, you should guess
>>>the result, but only return +1 or so.
>>>if you allow a +5 for such positions, you can get into this from a position
>>>where you were a piece up, because you simplify to this ending. if you want that
>>>to happen, fine :-)
>>>
>>
>>Note that there is an uncertainty in the evaluation.  Otherwise wouldn't you
>>expect a +9 which is a _real_ queen??? (+8 actually, since the pawn goes and the
>>queen appears).
>
>not necessarily. as a human, i never think in the context of +3 / +5 / +8. in
>such situations i think in the context of 99.9% winning probability or not. my
>static eval in my brain says "this is unclear" to the type of positions
>discussed. if i have a choice of playing this or playing with a piece up and 3
>pawns each for example, i will always choose the piece up position. no margin of
>error there...
>
>cheers
>  martin



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.