Author: Vincent Diepeveen
Date: 13:28:11 04/14/03
Go up one level in this thread
On April 13, 2003 at 10:09:29, Omid David Tabibi 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. > >Why do you always have to prove it yet again that you read no further that the >subject line of the paper? > >In the article you mentioned, I used 138 positions from Neishtadt's "Test Your >Tactical Ability", 869 ECM positions, 999 WCS positions, and also 434 "mate in >4" and 353 "mate in 5" positions. > Your whole conclusion is based upon search depths without telling what time it takes to get to that search depth. mating positions play a very important role in your 'proof'. for example table 2 just gives mate positions. Let's again look objective. Table 1 might show that R=3 works better for you. Table 2&3 shows nothing in fact as search times are not quoted, though they show an incredible big branching factor from Genesis going from 10 to 11 is branchingfactor=6.0 So i conclude directly then that something is wrong with Genesis. Not using transpositions like Uri isn't doing? Figure 4 the graph shows basically that if you extrapolate that verified nullmove is going to form a basic problem as it's coefficient for some weird reason is right up into the sky (45% degrees even). table 4 just shows depths 8,9,10 and that you need more nodes with verified nullmove than with R=3. Again weird branching factors there. like nearly 5.0 going from 8 to 9 ply with R=2. Even searching fullwidth i need less than 5.0, i need b.f. = 4.2 when searching fullwidth. You need with nullmove even 5.0 then moving to table 5 i see that your thing really gotta be very poor performing near qsearch because R=2 to R=3 hardly modifies something. Yet doing a 1 ply search near the leafs gives a lot of extra tactics. Of course the price is big. But most likely with 10% more nodes in qsearch (like doing checks) you would solve even more. The total number of solved positions is real low IMHO. This where in DIEP i'm not even using mating extensions... Yet no search times quoted, so it is unacceptible to say that verified nullmove solves more than R=3 here. Again same wrong assumption. Same applies to table 6 of course. > > >>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. >> >>>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.