Author: Robert Hyatt
Date: 11:27:06 05/09/98
Go up one level in this thread
On May 09, 1998 at 13:05:48, Amir Ban wrote:
>
>Game 2
>---------
>
>Played 35. Bxd6 with 5 moves and 46:59 min remaining.
>
>Evaluating based on expected reply 35... Bxd6:
>
>Starting at iteration 8 (AB: I guess this means ply 8, not counting
>extensions).
>
>Ply 8: 0:01 eval >30 (fail high): Qb6 Qe7 axb5 Rab8 Qxa6 e4 Bxe4
> Qe5 g4 Re8 Bg2 Qh2 Kf1 Re3
> Qc6 Rxc3
>
>Ply 8: 0:01 eval >61 (fail high): Qb6 Qe7 axb5 Rab8 Qxa6 e4 Bxe4
> Qe5 g4 Re8 Bg2 Qh2 Kf1 Re3
> Qc6 Rxc3
>
>Ply 8: 0:05 eval 87: Qb6 Qe7 axb5 Rab8 Qxa6 e4 Bxe4 Qe5
> g4 Re8 Bg2 Qh2 Kf1 Re3
>
>Ply 9: 0:18 eval 79: Qb6 Qe7 axb5 Rab8 Qxa6 e4 Bxe4 Qe5
> g4 Re8 Bg2 Qh2 Kf1 Re3
>
>Ply 10:
>
>35... Bxd6 played by Black (correct guess). Continuing to think on my
>clock...
>
>Set planned thinking time to 217 sec. Maximum time ("panic time") to
>839 sec.
>
>Ply 10: 1:22 eval 74: Qb6 Qe7 axb5 Rab8 Qxa6 e4 Bxe4 Qe5
> Bf3 Rd8 Qa7 Qxc3 Bh5
>
>Ply 11:
>
>For the next 4 minutes, there are no more reports with chess
>content. When the planned thinking time arrives, no move is made.
>Instead there start appearing messages that look like distress
>signals: Messages notifying each 4 seconds passing, and "panic time"
>(PT=...) countdown.
>
>Then:
>
>Ply 11: 5:35 eval 48: Qb6 (no principal variation given)
>
>At 6:56 minutes, the "panic time" mechanism is activated, and this
>produces:
>
>Ply 11: 6:56 eval 63: axb5 axb5 Qb6 Rxa2 Rxa2 Bc7 Qe6 Kh8
> Be4 Rb8 Ra6 Qd8 d6 Bb6
>
>36. axb5 played.
>
>
>AB:
>
>There are things here that are not easy to understand that are
>related to time management. Maybe IBM can clarify this:
>
>A move was not played at the planned thinking time (217 sec). In the
>rest of the printouts, a move is always played at this time (with
>the message TIMEOUT). In this case not. Maybe some criterion for
>playing the move was missing, or maybe Deep-Blue knew at the time
>something bad about Qb6, but the printout doesn't show it.
>
>
I believe that DB uses the same "next iteration guess" that I use,
that is previous score +/- .25...
assuming that, it looks like Qb6 failed low, but that they refused to
search it again (as I do) to find out how bad. Instead, they continue
to try *other* moves at the root to see if one of them will lie within
the original alpha/beta window. Which axb did...
As I said before, this seems perfectly natural to me, as it did when I
first saw it.
>When the score for Qb6 arrived, it wasn't too bad (48), not much
>lower than previous iteration (74). Perhaps it was failing low, but
>the log doesn't say so.
>
They generally don't. They might say "fail low" if *all* moves fail low
with the initial alpha/beta window. But in this case it appears that
the
first one failed low (notice score is about what I'd suspect alpha to be
on iteration 11, iteration 10's value -.25 or so...) and the axb5 move
dropped into the original alpha/beta window. When they got that score
back, that was within the original bound, so "panic time" ended. I
could
post several dozen such cases from my logs that look *identical*.
I think this approach is slightly imperfect, because the *first* move
that
gets back to alpha+x will stop the search, when there may be even better
moves to try...
>The "panic time" mechanism, if I understand correctly, was activated
>ahead of time. It still had about 7 minutes to go. The mechanism
>produced axb5. In normal alpha-beta as I know it, a new principal
>variation that was not discovered before cannot be produced just by
>stopping the search. Maybe I misunderstand, and first axb5 was found
>and this stopped the panic time countdown. If so, why wasn't it
>stopped a minute before when Qb6 arrived, and if not, why didn't DB
>continue to consider the rest of the valid moves ?
no one knows for sure, but my explanation above is probably correct,
from watching their output at prior tournaments. It wasn't really
activated ahead of time, I simply believe that the queen move failed
low, which would make the search continue since it is unknown whether
there is a better move or not, at that point...
And once a legit score is found (> alpha) it (and Crafty) immediately
stop and make the move... although in years past I have seen them search
longer. They have a complex algorithm that tends to "panic" when the
program can't make up it's mind, also. It was explained to me a couple
of times, but I never fully trusted it enough to play with it. But the
idea is if the evaluation is "unstable" then an extra iteration and
extra
time might be well worth the trouble...
>
>I am merely puzzled. I can't say I see any evidence of wrongdoing here.
>Perhaps an operator forced the move here to gain a few minutes. That
>wouldn't have affected the game anyway, since DB had plenty of time.
>
>About the variations given:
>
>After Qb6 DB expects Black to give up 3 pawns for an attack on the
>white king, and considers it almost equal compensation. I don't know
>how many other programs would evaluate it this way. This says
>something about DB's evaluation much more than its search depth. Some
>of the PV moves are weird, possibly completely wrong, but that often
>happens at great depths. For all I know, DB's judgement may have been
>excellent here.
I'm not sure how you arrive at that, because remember that any PV you
see stops at the hardware... so there could be many more moves tacked
on to the end that are not shown, because the hardware doesn't return
a PV (although it is possible to go probe each processor's hash table
and maybe retrieve some of what it saw...)
>
>
>------------------------------------------------------------------------
>
>Played 36. axb5 with 4 moves and 40:28 minutes remaining.
>
>Evaluating based on expected reply 36... axb5
>
>Starting at iteration 8.
>
>Ply 8: 0:01 eval >30 (fail high): Qb6 Rxa2 Rxa2 Bc7 Qe6 Kh8
> Be4 Rb8 Ra6 Qd8 d6 Bb6
>
>Ply 8: 0:04 eval 53: Qb6 Rxa2 Rxa2 Bc7 Qe6 Kh8
> Be4 Rb8 Ra6 Qd8 d6 Bb6
>
>Ply 9: 0:09 eval 53: Qb6 Rxa2 Rxa2 Bc7 Qe6 Kh8
> Be4 Ra8 Kh2 Rb8 g3 Qf8
>
>Ply 10: 0:33 eval 55: Qb6 Rxa2 Rxa2 Bc7 Qe6 Kh8
> Be4 Qf8 Kh1 Bd6 Ra6 Rd8 Ra7
>
>Ply 11:
>
>36... axb5 played by Black (correct guess). Continuing to think on my
>clock...
>
>Set planned thinking time to 199 sec. Maximum time ("panic time") to
>709 sec.
>
>Ply 11: 1:24 eval 32: Qb6 (no principal variation given)
>
>Ply 11: 3:02 eval 37: Be4 Rcb8 g3 Qd8 Ra6 Rxa6 Rxa6 Bc7 Rxf6
>
>(AB: This PV is ridiculous. I don't know what it means).
>
>Ply 12:
>
>Timeout occured after 199 sec.
>
>Ply 12: 3:19 eval 37: Be4 Rcb8 g3 Qd8 Kg2 Rxa2 Rxa2 Bc7
> Qa7 Bb6 Qa6 Qd7
>
>(AB: Since the search was timed out, I don't know where this new PV
>comes from. The eval did not change).
most likely from the hash tables... By probing to see what was "best"
at
each point (and for some positions, nothing is best of course so you can
get
nonsense moves since maybe everything is bad there)...
>
>37. Be4 played.
>
>
>AB:
>
>Timing here is normal. Some variations here are weird.
>
>There is no information given why Qb6 failed low at ply 11.
>
>The final move Be4 was accepted with a PV ending with a ridiculous
>Rxf6. Perhaps IBM know what this means.
you should try this algorithm: when you don't have a move to ponder
from the previous search's PV, do a hash probe and if you get a move
from
that test it for legality. Every now and then, Crafty does this and
reports
that an illegal move was found to ponder. I blame it on either a bug
that
I haven't found (and which I doubt) or on an occasional hash collision,
which
can happen easily...
>
>The move Be4 appears in many variations of the 36th and 37th moves.
>Looks like the evaluation function likes this square for the bishop,
>and it was played on general principles.
>
>
>-----------------------------------------------------------------------------
>
>Amir
>----------------------------------------
>Amir Ban e-mail: amirban@m-sys.com
>M-Systems Ltd. Tel.: +972 3 647 7776
> Fax : +972 3 647 6668
>-----------------------------------------
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.