Author: Robert Hyatt
Date: 14:45:26 04/14/03
Go up one level in this thread
On April 14, 2003 at 16:38:06, Vincent Diepeveen wrote: >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. That's not the problem. You are at position S. You want to score a score and the score is not a draw score. But, unfortunately, at some position _below_ S in the tree, a draw score changed the best move which affects the score at S. You will store that score at S, even though it is not a draw score, not knowing it was _influenced_ by a draw score that occurred deeper into the tree. This is not fixable without totally wrecking the idea of "transpositions". > >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. But this is not the problem I am talking about... > >>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.