Author: Tony Werten
Date: 03:45:40 06/08/01
Go up one level in this thread
On June 08, 2001 at 05:06:25, Dan Newman wrote: >On June 08, 2001 at 03:44:44, Tony Werten wrote: > >>On June 07, 2001 at 16:04:49, Dann Corbit wrote: >> >>>On June 07, 2001 at 06:52:07, Tony Werten wrote: >>>>On June 06, 2001 at 10:32:14, Gian-Carlo Pascutto wrote: >>>>>On June 06, 2001 at 09:06:40, Vincent Diepeveen wrote: >>>>>>Noop it doesn't make it void. >>>>>>To get from 100 to 200 is harder as it is to get from 10 to 20. >>>>>If they mean the same thing, not at all. >>>>>Note that I said you should be taking convergence acceletrators >>>>>into account. Every competetive implementation of MTD(n,f) has >>>>>them and the papers suggest them so that is a valid requirement. >>>>> >>>>>If you increase the window forecefull from 100 to 200 when you >>>>>are using millipawns it's the exact same thing as increasing it >>>>>from 10 to 20 when you are using centipawns. >>>>> >>>>>If you rely purely on the fail-soft and do not adjust the bounds >>>>>with the accelerators, I think you are right, but I really would >>>>>like to see evidence of it. When forcing the bounds it's just the >>>>>same thing however, and that is what every good MTD(n,f) implementation >>>>>is doing. >>>>> >>>>>You are basically saying that the difference between 0.1 and 0.2 >>>>>is different from that between 0.1 and 0.2. No it's not :) >>>> >>>>I think what Vincent is saying is that there's a difference between 0.1 and 0.2 >>>>and 0.10 and 0.20 The first 2 are following each other while the second 2 have 9 >>>>numbers between them. >>>> >>>>Suppose the current score is 0.10 Now I find a move with score 0.12 MTD will >>>>fail and I have to research. If I had scored 0.1 then the new move would have >>>>also been 0.1 and MTD wouldn't have to research. >>>> >>>>Of course is this not only true for MTD, but for all minimum window searches, >>>>but in MTD the first (best) move is also done with mws and this is most of the >>>>time the one that has the fluctuating scores. >>> >>>I imagine that this is a stupid question, but what happens if we simply truncate >>>on the test to research? We could just reorder the moves at that point instead, >>>if the difference is tiny. >> >>Not a stupid question. >> >>I was thinking about something like this. If I have time I'll test this weekend. >>( I'm messing with my code to get out the bugs ) >> >>My idea is this: I like the millipawn stuff, because I can give small bonusses >>to things I like ( not nescessairily correct ). When I return from the >>evaluation I could divide it with 10, 100 or whatever. This would mean the >>millipawn stuff still works (since 10 millipawns is still 1 centipawn ) but my >>search might have more cutoffs. >> >>Tony >> >>PS About my code. I found out that if I take a testposition and I mirror it, I >>get a different solutiontime ( even with material only eval ) I think it's in >>the extension discision part. >> >>Others might try if their engine doesn't have this problem. > >The hash table can do this to you. Even if all your code is mirror imaged >for black and white, if you use random numbers for the hash table, then >overwriting of positions will differ in the two cases, and the solution >times (node counts) will vary. In my code I would get this effect even >without the hash because my move generator generates moves for black and >white in different orders for mirrored positions... I don't use random numbers, but I think you have the point. At the start I scan the board to fill my piece arrays. I do this from downleft to upright. If I mirror then 2 equal pieces will be in different order, so moveorder will change so nodecount will change. Sounds logic. Thanks, Tony > >-Dan.
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.