Author: Robert Hyatt
Date: 11:42:13 05/04/01
Go up one level in this thread
On May 04, 2001 at 14:14:37, Andrew Dados wrote: > >Now, Bob, have a look at that again: > >1) Previous, timed out search: >============================= >11(6)[TIMEOUT] 2 T=168 >Qb5f1q ra1f1Q Ph6h5 kh1g1 Pb7b5 kg1h1 Kg8f8 kh1h2 Ne5g4 ne3g4N Ph5g4n pf5f6 >Rd8d6 kh2g1 Re8e6 rf1e1 > OK... let's figure out what that means. I interpret that as the 11(6) search ran out of time with no PV or score back yet... I could be wrong of course, without Hsu or Campbell here to be sure. > >2) Next search: >============================== > 7(4) #[h5](-30)[h5](-30) -30v T=0 >Ph6h5 kh1g1 Pb7b5 kg1h1 Kg8f8 kh1h2 Ne5g4 ne3g4N Ph5g4n pf5f6 Rd8d6 kh2g1 Re8e6 >rf1e1 > 7(6) #[h5](-66)############################## -66 T=1 >Ph6h5 kh1g1 Pb7b5 kg1h1 Kg8f8 kh1h2 Ne5g4 ne3g4N Ph5g4n pf5f6 Rd8d6 kh2g1 Re8e6 >rf1e1 > 8(6) #[h5](-50)############################## -50 T=5 >Ph6h5 kh1g1 Pb7b5 kg1h1 Kg8f8 kh1h2 Ne5g4 ne3g4N Ph5g4n pf5f6 Rd8d6 kh2g1 Re8e6 >rf1e1 > OK... those searches are done after the time-out search. Values are still in the hash table from that search that didn't complete. Those values can _definitely_ perturb the search results from the above analysis. I have seen this many times in Crafty. I can produce output _exactly_ like the above from ICC games, and I don't do _any_ root preprocessing of any kind. > >Note: > >a) all 3 lines above are searches below previous 11(6) depth. They all produce >same PV and different scores. They all should give exact same score if TT probe >was hit from previous search. If they give different scores, then TT was >owerwritten, then in that case second and third PV would give score similar to >previous search-to-corresponding-depth score. Hard to believe *all* PV nodes >were overwritten and then exact, same PV was found. Not necessarily. The table entries could be fail high or fail low nodes. They would influence/cutoff some lines, but they could not produce an EXACT type of score. Again, I have personally debugged the above kind of problem many times. And I feel pretty stupid each time it happens and I realize what I am debugging. > >b) it took T=5 seconds to get 8(6), so either something is broken in DB TT (it >shows exact PV line as previous) or DB didnt reuse TT from search to search, >which makes sense if it was doing some preprocessing. As you noted above 8(6) >depth should return _instantly_. > >-Andrew- Look at Crafty's output. I save the PV from iteration to iteration in the same way... Remember that DB doesn't save a PV, they probe the table. And they just probe to get the best move. Some of those nodes could be "LOWER" or "UPPER" bounds which means they _really_ aren't a part of this PV. And also don't forget that with Deep Blue, they used 32 SP processors, with 32 hash tables. You _could_ find the same position in different SP tables with different scores and different best moves... As a result, I'm not ready to assume any "root processing" or anything else here based on the PV output of the program. It is inherently unreliable because of the hardware design.
This page took 0 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.