Author: Ross Boyd
Date: 23:55:58 04/19/05
Go up one level in this thread
On April 19, 2005 at 19:13:35, Uri Blass wrote: >On April 19, 2005 at 17:45:29, Ross Boyd wrote: > >>On April 19, 2005 at 14:30:07, Uri Blass wrote: >> >>>On April 19, 2005 at 13:16:41, Uri Blass wrote: >>> >>>>On April 19, 2005 at 07:38:56, Uri Blass wrote: >>>> >>>>>On April 19, 2005 at 07:28:01, Uri Blass wrote: >>>>> >>>>>>On April 19, 2005 at 05:21:30, Ross Boyd wrote: >>>>>> >>>>>>>On April 18, 2005 at 22:55:31, Uri Blass wrote: >>>>>>> >>>>>>>>On April 18, 2005 at 22:41:37, Uri Blass wrote: >>>>>>>> >>>>>>>>>On April 18, 2005 at 22:29:09, Uri Blass wrote: >>>>>>>>> >>>>>>>>>>On April 18, 2005 at 21:32:59, Jeremiah Penery wrote: >>>>>>>>>> >>>>>>>>>>>On April 18, 2005 at 07:24:11, Uri Blass wrote: >>>>>>>>>>> >>>>>>>>>>>>part of the problem is check extensions and part of the problem is probably >>>>>>>>>>>>pruning based on evaluation together with other factors that I should improve. >>>>>>>>>>> >>>>>>>>>>>Why should check extensions make any difference in this position? Neither side >>>>>>>>>>>should be giving any checks. >>>>>>>>>> >>>>>>>>>>The problem is that most of the search time is not on the right line but in what >>>>>>>>>>happens after queen promotion. >>>>>>>>>> >>>>>>>>>>Movei cannot find the knight promotion in a reasonable time(I did not try more >>>>>>>>>>than 30 minutes on a fast PC) but almost all the search time is on queen >>>>>>>>>>promotion. >>>>>>>>>> >>>>>>>>>>After performing the knight promotion finding the mate is easy for movei. >>>>>>>>>> >>>>>>>>>>Uri >>>>>>>>> >>>>>>>>>Note that check extensions was only a thought and I am not sure that it is the >>>>>>>>>problem. >>>>>>>>> >>>>>>>>>single reply extensions after queen promotion may be a bigger problem(single >>>>>>>>>reply extensions are done also after a knight promotion but they do not help >>>>>>>>>much because depth reductions that is not null move pruning are also used and >>>>>>>>>probably they are used more after knight promotion). >>>>>>>>> >>>>>>>>>Uri >>>>>>>> >>>>>>>>Checking show that you are right that check extensions are not the problem and >>>>>>>>single reply extension is the problem that prevent movei to go deep because >>>>>>>>after queen promotion there are a lot of moves that force single reply that are >>>>>>>>not checks. >>>>>>>> >>>>>>>>Uri >>>>>>> >>>>>>>:-) >>>>>>> >>>>>>>That sounds like the cause of the problem. The tree would explode. Do you limit >>>>>>>single replies in any way? In 99% of positions its not going to be a problem >>>>>>>anyway, so no need to fix it. Maybe put a hard limit of 4 non-check extensions >>>>>>>or whatever works best. >>>>>>> >>>>>>>Ross >>>>>> >>>>>>I limit them but the limit is not based on their number but based on evaluation >>>>>>and if the side that force the single reply is clearly winning I do not extend. >>>>>> >>>>>>Uri >>>>> >>>>>I hope that I have another idea to limit them and also to limit check extensions >>>>>but I am not sure if it works and I plan to try it. >>>>> >>>>>I know that there are positions that movei cannot go deep because of heavy check >>>>>extensions(this position is not the case) and I have an idea how to stop it. >>>>> >>>>>Uri >>>> >>>>Latest private Movei after limiting extensions can solve the position at depth >>>>22 after less than 25 minutes and 952561647 nodes on fast hardware. >>>> >>>>failing high happen after 528430410 nodes. >>>> >>>>I will check if limiting the extensions also work in test suites. >>>> >>>>Uri >>> >>>After fixing a bug that caused it not to extend the first move >>>it is only 952557602 nodes at depth 21 and 528426365 nodes to fail high. >>> >>>Note that Movei does not use hash for pruning and I believe that using hash for >>>pruning is more important in that type of positions for programs that solve it. >>> >>>Uri >> >>Absolutely, hash pruning will save a great deal of nodes in this type of >>position. Have you experimented with hash pruning in Movei? Does it hurt Movei >>in games? In test suites it will almost certainly help. >> >>Ross > >I experimented with it in the past and probably I had bugs and it did not help >in a test suite so I even did not test in games. > >I think that the problem is that I do not save partial extensions in the hash >tables. > >If I prune when the remaining depth is bigger than the depth in the hash there >is almost no difference and if I prune also when the depth is equal then the >problem is that equal may be practically smaller because of partial extensions. > >changing my code to save partial extensions with no bugs is not easy with my >ugly code. > >Uri I think you should prune only when the depth in the hash table is >= remaining search depth.... but definitely not <= . But that is probably what you meant, anyway. Partial/fractional extensions can be rounded to the nearest full ply. I do that in TRACE. Works better that way. Maybe its worth another try. It surely saves nodes, and your code could not be any uglier than mine. :-) Ross
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.