Author: Sune Fischer
Date: 07:18:25 07/29/04
Go up one level in this thread
On July 28, 2004 at 17:48:56, Robert Hyatt wrote: >On July 28, 2004 at 14:21:26, Sune Fischer wrote: > >>On July 28, 2004 at 11:02:36, Robert Hyatt wrote: >> >>>On July 28, 2004 at 03:18:52, Sune Fischer wrote: >>> >>>>On July 27, 2004 at 18:26:16, Robert Hyatt wrote: >>>> >>>>>Aha. And exactly how many times do you do the N+1 iteration and get the _same_ >>>>>best move? For crafty that is about 85% of the time. So I should cut the >>>>>search off one ply early? Or is that 15% critical? >>>> >>>>I don't understand the question. >>> >>>you said I wasted time by starting the next search which won't fail low most of >>>the time. I said you waste time by doing iteration N+1 that doesn't change the >>>best move most of the time. See the fallacy in the argument? I _know_ going to >>>depth N+1 won't change the best move most of the time. But it will likely >>>change the best move when it is important to do so... >> >>No. >>It's going to depend on how much time you have left. >>If you need 5 seconds to fail-low and you have 4 seconds left, you won't see it. > >No (I can play that game too). :) > >the game _always_ depends on time. If you run out you have to do something. >But again, in 85% of the cases, doing N+1 produces the same best move as N, so >it is "wasted" by your definition. I'm interested in that 15% where it changes >to something better. Starting the next iteration might produce nothing 80% of >the time or more. But if it fails low twice in a game, it may well save me from >making a bad blunder... I can't predict whether I will have enough time to get >any information back, so I just dive in and search, and if it fails low, I get >valuable information. If not, I don't. Ok it's simple and it works reasonably well. What I'm suggesting is more advanced, yes it's harder to get working, but probably has a higher efficiency if implemented well. >>>I never said "win-win". I said it works better for me after testing. And I >>>have done _lots_ of testing with various approaches. That's how I settled on >>>the current approach. I'm not much for tea leaves and Tarot cards. >> >>That interesting, because I was beginning to wonder how you could have such >>strong opinions on something you _haven't_ tested. :) > >I _have_ tested both options many times. But you have not tested what I'm suggesting. >Your "assumption" is based on facts that have tons of contradictory evidence (IE >I _have_ done lots of testing and reported on it many times in various ways.) AFAIK it was a completely new spin on an old idea. >>>>I too would like to know if there is a big fail-low at the next ply, I just >>>>don't see your way as the most efficient way of doing it though. >>> >>>That's ok. All engines are different in some respect. I base my decisions on >>>what to do on testing. That's all I can say. Nothing says that what works for >>>my program will work for yours or vice-versa. But what I do works for mine >>>pretty well... >> >>Sure, but perhaps you are closing your eyes to something that might work even >>better. >>You should test it first, then say how much it sucks :) > >There is _nothing_ you have suggested (so far) that I have not tried. >null-window search included. I even used a _pure_ null-window search several >years ago, as used in CB and Belle, which was yet another way to do exactly what >you are describing... You have done exactly as I suggested? >>Unless of course you can come up with some super logical argument why it's not >>going to work. > >I'm an experimentalist, personally. How many times have you seen me answer a >question with what works for me plus the caveat "but you should test this >yourself as your results might be different" ?? I'm an experimentallist also, every chess programmer has to be, but I also enjoy a good conversation on the matter. Anything to find a shortcut :) >> >>>>To see the next ply you have to extend time, which you won't be able to do if >>>>you run out of time before the search returns. >>> >>>I don't have to extend the time. You proposed the 15% rule. It breaks above >>>and I'd stop 2 plies too soon, even though I could finish _both_. >> >>Where does it break? >> >>Please show me some analysis output where ply N+1 takes less than 15% of ply N. > > >Did you look at the times I posted? No I did not look closely at that flood of output. I read your conclusion that ply N took 1.5 and ply N+1 took 1.4. This is what I call the same magnitude, ie 1.4 >> 0.15*1.5 >> >>You definitely won't find many of those, and even if you manage to find one it >>will be insignificantly rare. >> >>>>..and then bite the dust when the fail-low doesn't have time to return or the >>>>time is simply wasted :) >>> >>>Again, I use aspiration search in addition to PVS. My fail lows happen _very_ >>>quickly in 99% of the cases. >> >>Ok, so in 99% of the cases you have some idea how long it will take to fail-low, >>anything longer means it's not going to FL and it's trying to resolve the score. >> >>Somewhere inbetween you can abort if you are not interested in the score. > >Probably although I have no way to estimate where that transition point >occurs... Aha, finally! :) That's all I'm saying. From looking at ply times we get (usually) something which is exponentionally increasing. Hence if your target time is well below the expected return time it isn't realistic to expect anything but a FL during that time (now let's not discuss a lot of boring oddball cases, kay). This is an observation one should take advantage of in some way other than ignoring it! :) >> >>> And with my approach I have no special-case "last >>>iteration" stuff to deal with. I just search until the search returns "time up" >>>and go with what I have. >>> >>>That's the KISS part of this. >> >>It's just very random, I prefer something more harmonious. >> >>-S. > >Any approach you choose will have a random factor. Tree size varies too much. I don't think it varies "too" much. -S.
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.