Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: deep blue versus diep

Author: Vincent Diepeveen

Date: 06:06:19 04/13/03

Go up one level in this thread


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.

>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.