Author: José Carlos
Date: 13:56:19 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. > >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. It is a good idea to use that at least in header (.h) files, to avoid problems with nested or repeated includes. Your chess.h file should look like this: /////////////////////////////////////////// #if !defined(CHESS_H) #define CHESS_H *** your declarations here *** #endif /////////////////////////////////////////// This way you can #include "chess.h" several times without compile problems. José C. [snipped]
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.