Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: MODERATION(the title is misleading and it is about programming)

Author: Uri Blass

Date: 00:47:32 07/22/02

Go up one level in this thread


On July 21, 2002 at 21:36:53, Miguel A. Ballicora wrote:

>On July 21, 2002 at 16:02:36, Uri Blass wrote:
>
>>On July 21, 2002 at 14:54:40, Miguel A. Ballicora wrote:
>>
>>>On July 20, 2002 at 15:53:15, Uri Blass wrote:
>>>
>>>>On July 20, 2002 at 15:37:00, Christophe Theron wrote:
>>>>
>>>>>On July 19, 2002 at 23:12:28, Ricardo Gibert wrote:
>>>>>
>>>>>>On July 19, 2002 at 23:08:16, Robert Hyatt wrote:
>>>>>>
>>>>>>>On July 19, 2002 at 22:15:31, Ricardo Gibert wrote:
>>>>>>>
>>>>>>>>On July 19, 2002 at 21:43:40, Robert Hyatt wrote:
>>>>>>>>
>>>>>>>>>On July 19, 2002 at 15:50:44, Uri Blass wrote:
>>>>>>>>>
>>>>>>>>>>On July 19, 2002 at 15:25:48, Christophe Theron wrote:
>>>>>>>>>>
>>>>>>>>>>>On July 18, 2002 at 12:14:10, Robert Hyatt wrote:
>>>>>>>>>>>
>>>>>>>>>>>>On July 18, 2002 at 05:58:56, Vincent Diepeveen wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>On July 17, 2002 at 13:18:40, Christophe Theron wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>On July 16, 2002 at 11:01:23, Vincent Diepeveen wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>On July 15, 2002 at 13:11:09, Christophe Theron wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>On July 15, 2002 at 08:37:34, Omid David wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>I don't think using double null-move is a good idea in practice, since in
>>>>>>>>>>>>>>>>>midgame the chance of zugzwang is negligible and thus it's superfluous (I doubt
>>>>>>>>>>>>>>>>>if even DIEP uses it). However the contribution of double null-move is that it
>>>>>>>>>>>>>>>>>gives legitimacy to the null-move pruning idea, proving that it _is_ a correct
>>>>>>>>>>>>>>>>>search method (anyway, no one doubts null-move nowadays).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>Why does double null move prove that null move is a correct search method????
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>Doing two null moves in a row means going back to standard search (a search not
>>>>>>>>>>>>>>>>involving an illegal move like null move is).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>I fail to see how it legitimates null move.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>Double nullmove legitimates (duh can't you use easier to spell words)
>>>>>>>>>>>>>>>itself, for the obvious reason that it is provable now that a search
>>>>>>>>>>>>>>>depth of n ply, where i may pick n, is going to solve any problem you
>>>>>>>>>>>>>>>give it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>OK, I see now.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>However, it is not true.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>Due to a nasty interaction with the hash table algorithms, just allowing 2 null
>>>>>>>>>>>>>>moves in a row will NOT solve any problem.
>>>>>>>>>>>>>
>>>>>>>>>>>>>What you refer to is a practical impossibility (assuming you have
>>>>>>>>>>>>>a efficient search) :
>>>>>>>>>>>>>
>>>>>>>>>>>>>  your assumption is that from a root position r
>>>>>>>>>>>>>  with transition of some moves to position p, side stm to move and
>>>>>>>>>>>>>  depthleft=d:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  r ==> p(stm,d)
>>>>>>>>>>>>>
>>>>>>>>>>>>>  that you visit this position with properties that
>>>>>>>>>>>>>  before this move you have made 1 nullmove or less.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  so ==> r , nullmove , p
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Now a major problem for such an event to occur is that
>>>>>>>>>>>>>  after 1 nullmove, sides change the side to move.
>>>>>>>>>>>>
>>>>>>>>>>>>Why is this a problem?  IE in my case, position P reached thru a path
>>>>>>>>>>>>with a null-move and position P reached thru a path without null-move
>>>>>>>>>>>>are _unique_ positions...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>If so, your programs loses a lot of opportunities to prune because it detects
>>>>>>>>>>>less transpositions. But maybe it avoids some problems and is benefical in the
>>>>>>>>>>>end, I do not know.
>>>>>>>>>>
>>>>>>>>>>How much do programs earn by pruning based on hash tables?
>>>>>>>>>>
>>>>>>>>>>Today I do not use hash tables to prune the tree.
>>>>>>>>>>I am interested to know how much rating programs earn from
>>>>>>>>>>using hash tables to prune the tree.
>>>>>>>>>>
>>>>>>>>>>1)Did someone do the experiment of comparing the rating of
>>>>>>>>>>a chess program when hash tables are used only for things like order
>>>>>>>>>>of moves and the rating of the same program when hash tables are used also for
>>>>>>>>>>also to prune the tree.
>>>>>>>>>>
>>>>>>>>>>2)How much speed improvement do programs get in middle game
>>>>>>>>>>from pruning based on hash tables?
>>>>>>>>>>
>>>>>>>>>>Uri
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Try position fine 70 with and without.  Without you might get to depth 15
>>>>>>>>>or so.  With it you can reach depth 40.  A _significant_ gain...
>>>>>>>>
>>>>>>>>You're trying to drive Uri crazy aren't you?
>>>>>>>>
>>>>>>>>Did you really think Uri could not think of an example of a position where
>>>>>>>>having hash tables makes a significant difference?
>>>>>>>>
>>>>>>>>Do you really think being able to search a position like Fine 70 to a depth of
>>>>>>>>40 instead of 15 will make a difference in a programs playing strength?
>>>>>>>>
>>>>>>>>Don't you realize people are liable to react to such a reply as yours above as a
>>>>>>>>troll?
>>>>>>>>
>>>>>>>>Please try to be a bit more thoughtful.
>>>>>>>
>>>>>>>
>>>>>>>There was _no_ troll involved.  Point by point.
>>>>>>>
>>>>>>>fine 70 _is_ an important hash test. It represents a near-best-case for
>>>>>>>hashing.  Which is the best you can do.  It increases the search depth by
>>>>>>>at least a factor of 3x in terms of plies searched.
>>>>>>>
>>>>>>>Will that help the program?  Clearly in king and pawn endings I see 20+ ply
>>>>>>>searches _all_ the time.  And _that_ definitely helps for those positions where
>>>>>>>K+P endings are reached.
>>>>>>>
>>>>>>>But if you want to take a middlegame position, hashing is worth at least a
>>>>>>>factor of 2x based on tests I have run in the past.  I can always run them
>>>>>>>again.
>>>>>>>
>>>>>>>So to summarize, fine 70 was and is legitimate.  It _clearly_ shows that
>>>>>>>hashing makes a significant difference.  I hardly see why _your_ post wouldn't
>>>>>>>be considered a "troll" in fact.  As it attacks a legitimate point in a
>>>>>>>utterly simplistic and wrong context...
>>>>>>>
>>>>>>>Perhaps you should follow your own advice and try to be more thoughtful.
>>>>>>>_prior_ to posting???
>>>>>>
>>>>>>I did. You didn't...again.
>>>>>
>>>>>
>>>>>
>>>>>Bob's post (the one you originally responded to) was perfectly fine. He just
>>>>>gave a meaningful information.
>>>>>
>>>>>Your posts are really borderline. I really fail to see what is the problem with
>>>>>Bob's post.
>>>>>
>>>>>Please don't start a war here. There is really no point.
>>>>>
>>>>>
>>>>>
>>>>>    Christophe
>>>>
>>>>I asked simple questions.
>>>>
>>>>I got a response but not to the questions that I asked.
>>>>
>>>>I asked:
>>>>1)How much speed do you earn from using hash table
>>>>to prune the tree in the middle game relative
>>>>to using hash tables but not using them to
>>>>prune the tree(not how much speed
>>>>I can get from hash tables in the middle game).
>>>>
>>>>2)How much rating can I expect from using
>>>>the hash tables to prune the tree.
>>>>
>>>>The response that I got are:
>>>>
>>>>1)Using hash tables to prune the tree is very important
>>>>in some endgames.
>>>>
>>>>2)Using hash tables help to get factor of more than 2
>>>>in the middle game.
>>>>
>>>>Nothing of these responses answered my questions.
>>>>
>>>>I have no problem with not getting a reply
>>>>because people may not know the right reply to
>>>>my questions but I prefer to
>>>>get replies to the questions that I ask and not to the
>>>>questions that I did not ask.
>>>>
>>>>The fact that I got from Robert hyatt only
>>>>informationa that I did not ask is the reason that
>>>>Ricardo Gibert said that Hyatt did not follow the thread.
>>>>
>>>>Uri
>>>
>>>Uri,
>>>
>>>I understand your question but unfortunately I cannot give you numbers :-)
>>>I believe that in the _middlegame_ the contribution of the hashtables as
>>>_pruninig_ is not so big. CT says 10% and BH say 2x which sounds to much to me,
>>>but it might depend on the program. Anyway, the biggest contribution on the
>>>middlegame I believe comes from the move ordering. I played a little bit with
>>>this a while ago and there are very rudimentary experiments that seems to
>>>suggest that once you have a good ordering the pruning by the hashtable do not
>>>seem to be huge. It is in an article by T. Marsland "Computer Chess and Search"
>>>in the Encyclopaedia of Artificial intelligence (page 234). This article is on
>>>the web somewhere, I remember the reference and I suggested it here in the
>>>group. You can do a search and find it. BUT, this experiment is very old and
>>>limited to short depth (6).
>>>
>>>However, the answer about how many elo points this could give you is difficult
>>>to answer because the real strength will be shown in the endgame. The answer to
>>>this point cannot be separated from this fact.
>>>
>>>My real suggestion is that you do experiments. Just can easily add the pruning
>>>in the code with a compiler switch so you can choose to compile it with and
>>>without. This is really easy. If you want I will be interested in comparing
>>>several middlegame positions side by side. I have this switch in Gaviota.
>>>
>>>Regards,
>>>Miguel
>>
>>Thanks for your reply.
>>
>>1)How do I add a code with compiler switch?
>>
>you define a variable like this:
>
>#define HASH_PRUNE
>
>and then you do
>
>
>#if defined(HASH_PRUNE)
>    code_1();
>#else
>    code_2();
>#endif
>
>code_1() is compiled and NOT code_2(). Also valid options are
>
>#ifdef HASH_PRUNE
>    code_1();
>#else
>    code_2();
>#endif
>
>or
>
>#if defined(HASH_PRUNE)
>     optional_code();
>#endif
>
>When you want to inactivate HASH_PRUNE you have
>
>#define HASH_PRUNE
>#undef HASH_PRUNE
>
>or you can comment out the line.
>
>/*#define HASH_PRUNE*/
>
>Those switches are very powerful, I suggest you get very familiar with those.
>Generally, the variables (like HASH_PRUNE) are in a file that is *.h and
>inserted everywhere like
>
>#include "switches.h"
>
>Then, you can change one variable in "switches.h" and the compilation of the
>whole program is affected. You can also control the portability of your program
>in this way. Also, when you have a portion of code that you are not sure you
>want to include and you are testing it, a good way to is to do this
>
>#if 0
>        code_1();
>#endif
>
>much better than commenting it out like this
>
>/*
>        code_1();
>*/

Commenting is the way that I used.

Today I have a code to print the line that movei considers every time that some
condition happens in my program(the condition is changed).

I used that code often when I found some bug in my program.

It is commented as

/*
code_1();
*/

If I want to print the line that my program considers I simply change it to

///*
code_1();
//*/

and compile again.

I found it as more simple than deleting the comment because if I delete the
comments I need to think where to put them again.

I never used #if or #endif in my program.
I guess that I could find bugs faster by better programming(the only way that I
tried to detect bugs was by changing the source code and asking the program to
print some information that it calculates).

>
>And besides, you put a 1 rather than 0 after #if and code_1() will be compiled
>again.
>
>Uri, I recommend that you peek sometimes comp.lang.c since it is very useful and
>buy "The C language program" by Kernighan and Ritchie. Your programming will get
>way much better.
>
>Regards,
>Miguel

I am sure that my programming can be improved and working together with another
programmer about movei could also help me, but for that purpose I need to find
another programmer that I can trust to keep the ideas that I use as a
secret[except using them for his own program(unfortunately I have to say his
because I do not know about a single female who developed a good chess
program)].

Most of the ideas that I have are not used today in movei.
One of the reasons is that I was too lazy to try to implement them and I use too
much time to watch my program play or analyze and not to try to improve it but
part of the problem is that it is not easy for me to implement the algorithms.

Last comment:
I did not delete the word moderation from the title because of the fact that
people who want to follow the thread may look for moderation but I decided to
make clear that the title is misleading in order to convince other people who do
not look in threads with the title moderation to look in the thread.

Uri



This page took 0.04 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.