Author: Miguel A. Ballicora
Date: 11:16:05 07/22/02
Go up one level in this thread
On July 22, 2002 at 03:47:32, Uri Blass wrote:
>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.
It works but it is not a good idea. It is suggested not to do it that way in
every single book that deals with it, and for good reasons.
/**/ are for comments, not for enabling disabling code. One of the most obvious
problems is that you cannot do that if you have another comment "nested".
This does not work:
/*
code_1(); /* comment */
*/
This does
#if 0
code_1(); /* comment */
#endif
Or steffen's suggestion works too
if (0) {
code_1; /* comment */
}
>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.
That is why is better to use #if 0, you just change it to #if 1
>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).
Uri, you do not only need to read some books about this, but also you will enjoy
doing it!! believe me, I have no formal education in computer science and the
books can teach you A LOT.
Another one to enjoy is
http://www.amazon.com/exec/obidos/ASIN/020161586X/qid=1027361468/sr=1-3/ref=sr_1_3/103-8949683-4968646
"The practice of programming" by Kernighan. There are more complete books but I
think this is the one for you. I wish I had this book when I started to learn
programming by myself.
"The C language" by Kernighan and Ritchie is almost a must to program in
correct, portable C. A bit expensive though. (~U$40)
Regards,
Miguel
>>
>>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 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.