Author: Vincent Diepeveen
Date: 03:38:28 08/12/99
Go up one level in this thread
On August 12, 1999 at 01:10:14, blass uri wrote: >On August 11, 1999 at 13:36:53, Vincent Diepeveen wrote: > >>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. > >This example shows that the null move is not a very good idea. Well this position is one of the few exceptions (short-timman). Note that GM Timman 2650+ also missed it. He resigned however after short making the Kg3 move. At that point we need a nullmove less, my program sees it nearly in blitz then too. Note that 14 ply is not that much to see it. It's a lot at nowadays hardware for programs like mine, no doubt. >If you need more 3*2=6 plies to see the right move and there is no >zunzwnag(playing no move cannot help black) then you are not close to see >everything to depth n-r with null move. but very close. Please feed us with some positions in YOUR games where it happened. It's easyto find some non-obvious examples which have nothing to do with chess. No doubt that in a few problems you need a bigger depth to see things, but that doesn't take away that usual WITH nullmove you get to that depth sooner than without nullmove to the depth without reduction. >I thought depth n when you use null move with R=2 means that except for >zunzwangs you analyse everything to depth n-2 and I see that it is not the case. Right. Would be rather stupid. >Uri
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.