Author: Robert Hyatt
Date: 08:08:49 04/13/03
Go up one level in this thread
On April 13, 2003 at 09:06:19, Vincent Diepeveen wrote: >On April 13, 2003 at 08:36:06, Uri Blass wrote: > >>On April 13, 2003 at 08:04:04, Vincent Diepeveen wrote: >> >>>On April 13, 2003 at 07:57:47, Uri Blass wrote: >>> >>>>On April 13, 2003 at 07:41:00, Vincent Diepeveen wrote: >>>> >>>>>On April 13, 2003 at 00:14:52, Omid David Tabibi wrote: >>>>> >>>>>may i remind you that many programs use R=3 basically with exception sometimes >>>>>of the nullmove of depthleft == 4. >>>>> >>>>>I'm doing more in qsearch than you do. >>>>> >>>>>Further your verification search is using R=3 too with a bug in the hashtables >>>>>management. Because of that bug which is that you do not store in hashtables >>>>>whether a search result is based upon a verification or not, the worst case >>>>>performance of verification search is R=3. >>>>> >>>>>Best regards, >>>>>Vincent >>>> >>>>I suggest that you care about your programs and not about other programs. >>>> >>>>You do not know the exact details of the implementation of verification search >>>>in genesis so you have no way to know if there are bugs. >>>> >>>>Uri >>> >>>He posted stuff in ICGA. There was no mention on how he manages verification >>>search with regard to hashtables. So he doesn't. If he does then his publication >>>was not accurate as it is not representing truth. >>> >>>Best regards, >>>Vincent >> >>1)He also did not post the other details of genesis. >>so by this logic you can say that his publication is not accurate if he does not >>release the source code of genesis. > >This is not relevant. Relevant is that he published something and if his >publication has a bug, then it has a bug. Period. > >>2)Even if he does not store in hash tables if a result is based on verification >>search then it does not mean that there are bugs. > >Ah you are not understanding the bug either. Logical, transpositions do not work >in Movei. > >If they do not work in genesis either then that explains everything :) > >>It is possible that not storing the information and doing verification search >>is simply better for him practically than R=3. > >Only if his qsearch sucks ass, which is probably does. The first 'verification' >(when we forget the hashtable bug) gets done where nullmove normally gets >replaced by -qsearch, it is modified into a R=2 more or less search. > >So at depthleft == 4 it is trying a move now. > >The only tests he showed were at a few mating positions. So in short if you do >not do checks in qsearch, but when trying another move at depthleft == 4 and >lower then you see that sooner of course if your qsearch sucks ass. > >Therefore his article is a clear case of willingly committed fraud, as he showed >in the CCC clearly that he knew the problem. > >Had Omid used normal positions or a better program, then results would have not >been similar. > >>You can say also that using hash tables for pruning is bad because you can get >>wrong result when there is repetition in line A and no repetition in line B. > >I fix that in diep by never returning a score when score stored == repetition >score. That doesn't _begin_ to fix the "bug". You _still_ store positions and scores that were produced as a result of repetitions happening or not happening, even if the score you store doesn't say repetition. This is _impossible_ to fix without storing path information as well, which eliminates the use of hashing almost 100%... > >>I do not use hash tables for pruning and I do not plan to do it in the near >>future but I do not say that it is a bad idea only because of the fact that they >>may give a result that is not correct. >>Uri > >You should say that you are a very poor programmer instead. Hashtable gives a >lot, especially incombination with nullmove.
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.