Author: Sune Fischer
Date: 10:09:19 12/18/02
Go up one level in this thread
On December 18, 2002 at 12:53:09, Gian-Carlo Pascutto wrote: >On December 18, 2002 at 12:13:56, Sune Fischer wrote: > >>On December 18, 2002 at 11:38:41, Gian-Carlo Pascutto wrote: >> >>>On December 18, 2002 at 07:47:15, Sune Fischer wrote: >>> >>>>On December 17, 2002 at 19:42:10, Bruce Moreland wrote: >>>> >>>>>We have his new version, and it gets to the same depth more slowly, and finds >>>>>more answers, than R=3. This proves nothing. I could make a program where the >>>>>eval function incorporates a 2-ply search. It would take longer to search 9 >>>>>plies, but it would get a lot more right. This is the same result that Omid >>>>>got. Did he just prove that my hypothetical program is better? Of course not. >>>>> >>>>>If you accept his method as proof, he did prove that VR=3 is better than R=2, I >>>>>point out. But he should have tackled R=3, too, if he is going to present that >>>>>data. >>>> >>>>If you want to compare _search_ algorithms, you shouldn't go and change the >>>>evaluation or completely redefine the word "node" from one program to the next. >>>> >>>>The whole assumption here is that they are identical, except for changes in the >>>>search parameters. >>> >>>I don't see how this affects Bruce's point. >>> >>>His point is that searching slower to a certain depth but getting more >>>solutions is no proof that the algorithm is better. >>> >>>Are you arguing this is wrong? >> >>Yes I am. >>Bruce is saying that a node is a node. > >No, that is not the point at all. You said you couldn't see what it had to do with Bruce's point, so I elaborated. >The point is (I'm repeating exactly what I said before) >that searching slower to a certain depth but getting more >solutions is no proof that the algorithm is better. It is proof that it is better in terms of nodes. Whether it is also faster can depend on you implementation details, your structures and other things. Some can do incheck() very cheap, others can't, some can do SEE cheap, others can't. So IMO time is no more objective than nodes, as a unit of measurement. Everything will depend on the rest of your program, ultimately. >What a node is or is not has nothing whatsoever to do with this. It does, because when you pick nodes, you sort of disregard the implementation details. It assumes a node is well defined I suppose, which it isn't, but it's not far from it I think. I see the knps drop in some positions in my program, but I consider that implementation effect and other programs might behave differently, ie. get a speed up where I get a slowdown.... What we need is a measuring stick, but there isn't one! Is SEE worth it? Can't answer that question, can you? All we can say is it gets the job done in fewer nodes than MVV/LVA, whether it is faster or not is a different discussion and probably highly implementation specific. Imagine if you just published an article showing it to be inferior to MVV/LVA, which it might be in your program. Then 10 years later some guy decides to do a hardware move generator with move ordering, he can do everything very fast (for the sake of argument). Now he reads your article and decides against SEE because you found it to be inferior, period. Obviously this would be a bad decision in his case. -S. >-- >GCP
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.