Author: Guido
Date: 14:37:49 06/06/01
Go up one level in this thread
On June 06, 2001 at 03:56:24, Marcus Heidkamp wrote: >On June 06, 2001 at 03:05:54, Guido wrote: > >>IMHO in the last question you are right: it is possible to use one only >>tablebase (.nbw or .nbb) to find the response for an ending position. I did it >>with my tablebases, not with EGTB, seemingly with success, but the program >>becames very complicated and cpu time increases consequently, so I abandon the >>idea. >> >>In fact, suppose you use a .nbw file, there are four possible situation: >> >>1) you can use the .nbw tablebase directly >>2) after exchange of the men colour you can use the .nbw tablebase directly >>3) you have to make a ply and after you can use the .nbw tablebase >>4) you have to make a ply and exchange the men colour and then you can use the >>.nbw tablebase >> >>But in the two last cases you have to analize all the possible plies to find the >>best result, but what happens if the ply is a promotion or a capture? Obviously >>you have to load another tablebase and repeat the procedure; moreover the >>loaded tablebase could not be used directly, but it could need an exchange of >>men colour or, in the worst case, the execution of another ply or both. And this >>process could continue so the code must be recursive. >>During this process you have to save the best result for the player, keeping >>into account every time you need of a ply or of an exchange of colour. Very >>simple :-)! >> >>So my opinion is that the game is not worth the candle (italian: il gioco non >>vale la candela) >> >>Ciao >>Guido Antonelli > >Actually I use the TB probing code just after my Hash probe, and a successful TB >probe will be stored permanently (i.e. with a maximum search depth) to the hash >table. I did not see any significant performance deficits, but my program is >still a rough sketch. I guess, because I use MTD(f) as the Alpha-Beta-Driver, it >works due to the cutoff-approach of MTD. > >Regarding your four points I think that going one ply deeper is not a real >problem. If you do captures or promotions you have to look into the new TB >anyway. Of course you have to do on average the av. branching factor/2 (i.e. >38/2=19). But for people lacking disk space (like me) it works, instead of >giving no result at all, or doing the 1-ply search manually. And for the >professionals: If the other side exists, you simply cut off and do not search >one ply deeper. So what's the disadvantage there? > >Marcus With my message I would only say that there is a big difference in the cpu time relative cost between simply looking for one result in a tablebases and calculating all the possible plies and for any ply looking for in the tablebases with or without exchange of men colour, with the possibility, surely very rare, of having to extend the search to other tablebases. Obviously with an hash table the cost in time is strongly reduced, because you don't have to repeat the calculation millions of times or more. Secondly if your PC doesn't have a big RAM your choice becames obliged. Besides using hash tables, I imagine that you don't pay too much in cpu time also because probably not too many leaves of the tree are situations where there is the possibility of using tablebases. But you have surely more experience than me in this, because I realized this procedure only for a demonstrative program and I also remember that I had to debug a lot before obtaining acceptable results. I add the consideration that when the program enters a chess ending situation covered by tablebases, cpu time is no more a problem, as it is not necessary to load tablebases in RAM, being sufficient to look for the answer in the disk file. IMHO for the professionals there is no disadvantage but only a complication in the code. Ciao Guido
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.