Author: Heiner Marxen
Date: 08:07:46 12/29/01
Go up one level in this thread
On December 28, 2001 at 20:25:34, leonid wrote: >On December 28, 2001 at 19:41:52, Heiner Marxen wrote: > >>On December 27, 2001 at 21:51:56, leonid wrote: >> >>> >>>Hi, Heiner! >>> >>>>>Just look into fact that with new depth procedure of search will be changed. >>>>>Specialized files, for instance, will be at new depth. Somewhere it can bring >>>>>different search sequence and with it even better time for higher depth. >>>> >>>>Aah! Yes, you have a point, here. >>> >>>I tried today last position once again but starting this time search from 3 >>>moves like, (3 4 5...). When before it was, (4 5 6...). Now I could see that >>>previous time for your program was wrong and your specilized plys work much, >>>much better that I could see previously. Fantastic!!!!! When before I found 0.11 >>>sec for 4 moves, now I could see 0.0 sec. >>> >>>This finding could signify that my guessing about ten fold possible speeding of >>>mate solver is very sober expectation. It reality, it could be much higher. >>> >>>In the next position that I wrote yesterday, old tendency is more that present. >>>Our speed for 4 moves (all condition are the same) is around 9 times in your >>>favor. Mine at 4 moves is 0.44 sec. and your 0.05 sec. Even if mine have here >>>chance to have somehow better branching factor it reach your time only at 9 >>>moves. Initial speed is really vital. >>> >>>[D]3k4/3qqqrp/N1qq3R/NQ1Q3q/n2qNRPQ/n7/B6b/BqQrQbQK w - - >>> >>>My time in general: >>> >>>Move Time Branching factor NPS. >>> >>>4 0.439 sec 38k >>> 4.87 >>>5 2.14 sec 36k >>> 4.64 >>>6 9.94 sec 36k >>> 5.3 >>>7 52.8 sec 49k >>> 4.69 >>>8 4 min 8 sec 57k >>> 8.52 >>>9 35 min 13 sec 64k >>> >>>Mate found in 10 moves at 1 hour 53 min. >> >>Interesting. My timing is: >># 4 0.09s [ 4.50] 5kN [ 5.24] 1.03 463- 0 >># 5 0.42s [ 4.67] 26kN [ 5.54] 1.29 1786- 0 >># 6 3.49s [ 8.31] 189kN [ 7.39] 1.51 16848- 0 >># 7 23.41s [ 6.71] 1187kN [ 6.27] 1.80 130157- 0 >># 8 146.17s [ 6.24] 7333kN [ 6.18] 2.13 871820- 0 >># 9 783.47s [ 5.36] 39167kN [ 5.34] 2.66 4764548- 22074 >># 10 5019.44s [ 6.41] 242350kN [ 6.19] 2.86 30197115- 21449215 >> >>Our NPS is nearly equal. My inital speed is clearly better: when you have done >>depth 4, Chest has completed depth=5, already. But although you do not use >>any hash, your EBF is better from 6 to 7 and to 8, while mine is better >>from depth 8 to 9. >> >>This may be due to luck, but it makes me curious: how do you manage such a >>good EBF? How do you select black moves? I know we both prefer checking >>moves, generally, but is there more to it in your program? >>Chest uses a really complicated function to order the black moves. >>You seem to be quite good in this respect, also. > >It could be that our programs do very close search but each do it best on some >preferable one. It could that this one mine recognized as "preferable" one when >on previous it was clearly terrible looser. That is what I meant by "luck", yes. >Probably you do the same move ordering for black and white, at least in my >program logic is the same. Basically, program find all legal moves in advance >(exception exist but only in one specialized ply) and put checking moves at head >of its chain. For white moves this is the only sorting I do: pulling checking moves to the front of the list. > No material evaluation ever done but something close to this >exist. Just after "first alignment" that was done in move generator (checking >moves are put there as first to go) come second aligment. It is most probably more efficient to do this already as part of the move generator (I have done that many years ago). Currently Chest does it as a separate function, to make the move generator less complex. > Each move that take >some enemy piece, or make promotion, is aligned after expected gained value in >very rough way. For instance, taken of knight and bishop are not differentiated. >Taken of queen and every pawn promotion is regarded as equal. Well, yes, that is similar to what I do for black moves. Capturing yields the usual material values, and checking is like capturing a rook. The amount of flight squares around the black king is also used: each flight is worth a pawn. If the depth is greater than 2, much more complicated things are done. Checking moves are differentiated whether they give away material or not, and the branching factor for white in the next two moves is estimated, in order to minimize their product. > On the most responsive plys "most responsive" is near the leaves? > two best moves are saved and used for "second aligment". One >move is "active" and second is "passive". Active move - move that is ckecking >move, or one that bring material advantage. Passive move - move other that >active. Is that some king of "killer move" heuristic? How exactly are these moves "used"? What exactly triggers the saving of another move (replacement)? I don't have such a thing. Might be worth trying. >Is this really close to what you have? It matches my basic sorting, yes. With more depth to go, Chest's function is much more complex, and not easy to explain. It is a little "magic" in that function. For white's moves you appear to do a bit more than I do. >Even if I wanted few times to read what you have done, I still never make my >reading. Partially it is because I am lazy for every possible reading but even >more so because I don't remember any more C language. Even if you were fluent in C, and would have the time and motivation to read it, I doubt you would understand much of it just from the sources. I myself have a hard time to re-read it. :-( My co-author Holger Pause developped the complex part of this move sorting by try and error, until he was satisfied with the results for a certain benchmark. That way some of the things in it are hard to explain, beyond "it works well that way". Cheers, Heiner
This page took 0.18 seconds to execute
Last modified: Thu, 07 Jul 11 08:48:38 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.