Author: Vincent Diepeveen
Date: 10:36:53 08/11/99
Go up one level in this thread
On August 10, 1999 at 21:55:29, Robert Hyatt wrote: >On August 10, 1999 at 18:42:58, Tom King wrote: > >>On August 09, 1999 at 20:41:50, Robert Hyatt wrote: >> >>>On August 09, 1999 at 17:51:01, Tom King wrote: >>> >>>>On August 08, 1999 at 21:35:46, Robert Hyatt wrote: >>>> >>>>[snip] >>>>> >>>>> >>>>>I've been doing a 'hybrid' for nearly a year... R=3 fairly close to the >>>>>root, R=2 beyond some threshold that I don't remember what it is... >>>>> >>>>> >>>> >>>>Interesting.. better than pure R=2 or pure R=3? I did some experiments a while >>>>back, using R=3 on the opponent's move, and R=2 on the computers move (idea >>>>being - let's not cover up the opponent's threats, and if we miss some of our >>>>threats, well, so be it). But it was more or less a 'wash'. >>> >>> >>>I started playing with this after Paris, as someone said that Frans (or someone) >>>was fiddling around with R=3. Bruce and I played a few games one night with >>>Ferret vs Crafty, with bruce using R=3, and we saw _no_ gross mistakes on his >>>part. In fact, we couldn't tell the difference (at least R=3 was not making >>>mistakes that R=2 wasn't). >>> >>>But I never felt comfortable with raw R=3, as R=2 causes more than enough >>>problems already, thank you very much. :) >>> >>>Ernst is writting an ICCA paper describing some experiments he did with this >>>(totally unconnected with my tests). Wait for his paper to hit the journal as >>>he has some good data... And I am not yet sure that this is a good idea, but I >>>have been running it a good while and it has been in the distributed Crafty for >>>quite a while as well and no one has complained. Of course, now that everyone >>>knows, look out. :) >> >>One thing's for sure - I'm sure there's a lot more we could all be doing with >>the null move. Playing around with different values of R, depending on depth in >>the tree, alpha and beta etc. etc. I look forward to this paper. Ernst has been >>productive of late..I'm sure I'm not the only one to enjoy reading his articles. >>[even if his damn program does kill mine at the WCCC ;-)] >> >>Cheers, >>Tom. > > >If you want to play around, here's another idea I have on my 'to-do' list: > >at present I 'break' the search into two 'chunks'. the part near the root >uses R=3, the rest uses R=2. Something tells me this might be made much more >dynamic than that... ie R=4, then 3, and finally 2. But rather than some >static divisor as I have now, make this dynamic so as you go deeper, you use >bigger R values near the root, etc... > >Seems reasonable. Whether it will work or not, we won't know until we try >it... It works great for testsets, but i care shit for those now. I've thrown such tricks completely out of my DIEP now, and the reason is that hashtable makes thing hazardeous: some positions it will not nullmove until it gets there, then score based upon a R=4 will be stored in position X. Now suppose in an important line we get to that position X using transposition, then first nullmove we use R=4, where we would *expect* it to find it a ply sooner. I go think then there is a bug in my DIEP, but there isn't, you just depend upon happiness of hashtable, and that idea sucks for me, so i left the idea of solving testsets. Good example is in the BS2830 test set: Kg3. Of course not with the best will in the world a program will get with transposition to the position where the king is at h6 and position the same. Not a single program will search so many BS that it gets to that position at a lower depth, and then by means of transposition finds it at a smaller depth than possible. 2r2rk1/1bpR1p2/1pq1pQp1/p3P2p/P1PR3P/5N2/2P2PPK/8 w - - 0 2 Kg3 15 what nullmove programs need to see here: Kg3 NULL Kf4 NULL Kg5 NULL Kh6 .. qg7 mate in qsearch. Now programs not doing checks in qsearch will null also at the '..' programs having mating extensions will extend after Kh6 will be made. Yet programs need to survive 3 nullmoves. So without cooking for this you need: Kg3 NULL Kf4 NULL Kg5 NULL Kh6 .. 1 2 3 4 5 6 7 8 so 8 ply + 3*r = 14 ply at least. Example, fritz with R=2 can solve this problem very quickly, so that's clearly cooked by Frans. Some weird lines which are stored in hashtable and give with luck hashtabletransposition to the right position is BS too, because that's impossible in this position. You would get a cutoff anywhere. Now i'm sure that Frans doesn't like to reduce R after first nullmove(s) either, as that's wasting some few nodes which even took care i don't do it anymore!. Other things like preventing the program to nullmove after 2 moves of the same piece are also insane and wasting nodes for nothing normally spoken. Only for this problem it's solving it. The way to solve this by means of cooking is to take care the prog is liking the moves Kg3-f4-g5-h6 in preprocessor, which normally spoken is insane, but very easy doable in this case. Then some alfabeta dependant extensions will quickly pickup the insane Kf4-g5-h6 moves and it will find it. Now i wonder whether this is really the way in which this problem is cooked by Frans. It's cooked, that's without question. A correctly functioning nullmove program where every 0.x% nodes speedup are not wasted will need at least 14 ply to solve this problem :) Greetings, Vincent
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.