Author: Robert Hyatt
Date: 09:49:38 07/30/02
Go up one level in this thread
On July 30, 2002 at 12:17:43, J. Wesley Cleveland wrote: >On July 29, 2002 at 23:08:59, Robert Hyatt wrote: > >>On July 29, 2002 at 12:56:33, J. Wesley Cleveland wrote: >> >>>On July 29, 2002 at 11:00:30, Robert Hyatt wrote: >>> >>>>On July 29, 2002 at 00:28:05, J. Wesley Cleveland wrote: >>>> >>>>>On July 28, 2002 at 13:02:01, Robert Hyatt wrote: >>>>> >>>>>>On July 27, 2002 at 15:06:23, J. Wesley Cleveland wrote: >>>>>> >>>>>>>On July 25, 2002 at 20:13:45, Robert Hyatt wrote: >>>>>>> >>>>>>>>On July 25, 2002 at 19:24:06, J. Wesley Cleveland wrote: >>>>>>>> >>>>>>>>>I see that crafty does not store lower bounds of MATE-n in the hash table, >>>>>>>>>rather changes them to MATE-300. Bob wrote that he had search instabilities >>>>>>>>>before he did this. Normally, this does not matter, but I think it makes crafty >>>>>>>>>considerably slower in finding mates, as it only gets cutoffs on exact scores. >>>>>>>>>Do other people have experience in this ? >>>>>>>> >>>>>>>> >>>>>>>>Note that all this does is slightly decrease search efficiency. I do store >>>>>>>>_exact_ mate scores as they should be stored. I store "bounds" that are based >>>>>>>>on MATE as MATE-300. The penalty is _very_ small unless you have a position >>>>>>>>where almost everything leads to a forced mate of some sort... >>>>>>> >>>>>>>The place where I notice it is in engame analysis with EGTBs, where after a long >>>>>>>time the PV is scored as Mate in 38 or so, and then it takes a *very* long time >>>>>>>to prove the other root moves are worse. >>>>>>> >>>>>>>A related question: >>>>>>>If the score in the hash table is MATE-300 and this would cause a cutoff, >>>>>>>shouldn't you cut off even if the draft is not deep enough ? >>>>>> >>>>>> >>>>>>I could but I don't. That would prevent finding a _shorter_ mate the next >>>>>>iteration. >>>>> >>>>>But wouldn't you only care about a shorter mate if the _value_ would not cause a >>>>>cutoff ? >>>> >>>> >>>>There are two issues here: >>>> >>>>1. absolute mate scores. I store those correctly, as is, corrected for the >>>>distance from the current position to the actual mate. >>>> >>>>2. mate bounds. I found problems with those, and simply changed any mate >>>>bound to mate-300. >>> >>>>It is still large enough to cause cutoffs against any >>>>possible material gain or loss. But not large enough to confuse a real mate >>>>search where the scores are absolute but the bounds are not... >>> >>>Let me give an example. Assume that while searching at a given ply, alpha is >>>1805 centipawns. When searching after a move for black, the hash table has a >>>lower bound of MATE-300 but the draft is less than the depth. Why would you not >>>want to cut off without searching here ? Wouldn't you search *exactly* the same >>>moves (assuming no hash table overwrites), and return the same MATE-300 value ? >>> >> >>You can do this. I used to do this in an even stronger form in Cray Blitz, but >>I dumped it later. All you need to do is set the "draft" to infinity for any >>mate score or bound... >> >>The down-side is that you will _never_ find the shortest mate if you find >>another mate first. >> >I modified crafty to do this, and I don't see this problem. When alpha is > >MATE_300, it does not cut off. If you do what I said, and set the draft to infinity, then you _must_ run into the problem. Because it is quite common, due to the search extensions I do, to first find a mate in N, and then a couple of iterations later find a mate in N-1 or N-2. If you set draft=+infinity, then you will _always_ use that mate score and never search to find the shorter mate... I used to do that, but got lots of complaints by problem-solvers, and I decided that it really wasn't that important and took it out so that it is possible to find the shortest mate, given enough depth. >> >> >>>On the next ply alpha is MATE-21. Now the score will not cause a cutoff and the >>>position is re-searched normally.
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.