Author: Vincent Diepeveen
Date: 13:38:06 04/14/03
Go up one level in this thread
On April 13, 2003 at 11:08:49, Robert Hyatt wrote: >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. That's not entirely true. if( max(draw,alfa) == draw ) then *draw* gets stored. DIEP doesn't return *anywhere* in the search tree a draw score when it transposes. Hashtables cannot give draw score back. if( max(draw,alfa) == alfa ) then maximizing has taken away the draw score. So the only case left can be that in this subtree the move that lead to a draw was the best move. Let's first consider using 2 fold properties: a) the move cannot be a capture b) the move cannot be a pawn move c) the move cannot modify en passant status Then only shuffle moves are left. Yet we know that position P already was further back in the tree. So if shuffle move m which would modify alfa if it was the case that we directly evaluate after it but now give draw score back then: P --> .. --> Q(p) --> P' So basically position P gets wrong evaluated then. However, if P is a position > alfa, then we would already see that alpha improvement back in position P. So the scores get backtracked correctly to the root and the right score is written down for position P. >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.