Author: Robert Hyatt
Date: 10:33:03 04/25/02
Go up one level in this thread
On April 25, 2002 at 12:01:12, Uri Blass wrote: >On April 25, 2002 at 10:46:57, Robert Hyatt wrote: > >>On April 25, 2002 at 06:52:58, Uri Blass wrote: >> >>>On April 25, 2002 at 06:08:03, Sune Fischer wrote: >>> >>>>On April 25, 2002 at 05:24:52, Uri Blass wrote: >>>> >>>>>I do not know why do you suspect that it is more. >>>> >>>>Because I have not tested how Chezzz's strength depends on hashsize, and 6 elo >>>>doesn't sound like a lot. >>>> >>>>>In the second game(10 hours per game) movei is losing the endgame against chezzz >>>>>so it is 1-1 >>>>> >>>>>The previous movei also lost the game with black(10 hours for game) and I think >>>>>that the latest version played better. >>>>> >>>>>I will stop these long time control games and I will try to implement some very >>>>>small opening book only for the first move and learning to change the first move >>>>>in every game so movei will be able to play a match of 4 games without repeating >>>>>the same game twice. >>>>> >>>>> >>>> >>>>If the point is to prove you have a method that is better than hashing, then I >>>>think you should give your opponents a decent size hash. >>> >>>I did not say that I have a method that is better than hashing but that I am not >>>going to use hash tables in the way that they are used today by chess programs. >>> >> >>There is only one way they _can_ be used in an alpha/beta search. Otherwise >>what you will be doing can not be called "transposition/refutation" which is >>the proper name for "hash" tables. >> > >The problem is that my evaluation function is not depended >only on the leaf position. > > >It does not mean that memory from previous search for >better order of moves cannot be used with this evaluation >but today I do not use it(I use 2 >killer moves and history tables but this is not what I mean by >memory from previous search). > > >> >> >>>I also think that 8 mbytes is a decent hash and the difference between 8 mbytes >>>and 128 mbytes is small(I also cannot use 128 mbytes in my p800). >>> >>>I remember a claim by programmers that doubling the hash tables give 6-7 elo and >>>I do not remember a claim that it is dependent on the time control. >>> >> >> >>Your number is wrong. It depends on a lot of things. But one thing can >>be easily proven. Changing the hash size can make the program reach a >>specific depth more than 2x faster. And >2x is > 50 elo. > >The question is about rating for games. > >I agree that in endgame doubling the hash tables >can do the program more than twice times faster but >the interesting question is what happens in the middle game >that is more important. > >>] I am not talking about endgames. I am talking specifically about middlegames. take Crafty, use the default hash, and search for (say) 5 minutes, a typical search for 40/2hr time controls. Then double the hash and try again. And double and try again. The time required for the search will vary from 2x-3x (or more)... In middlegame positions. I posted some test results like this several years ago in r.g.c.c when KomputerKorner asked me to run the test to give some real answers on how hashing affected middlegame positions. The answer was more than I thought. >> >> >> >>>> >>>>An opening book is a good idea for that reason. I don't want a huge book because >>>>I want the engine to play the game itself, the opening included. >>>> >>>>-S. >>> >>>I agree and I also never liked the idea of a huge opening book. >>> >>>Uri >> >> >>Depends on where you play. On ICC you will get killed with a small opening >>book... > >I think that it depends on the program but I do not care about >ICC today. > >You will get killed if the opponent can repeat the same opening >again and again but if the program is not deterministic >in the first 10 moves then things may be changed. > >I think that a good program should find good opening moves >by itself. > >My program in the 5th division of the winboard programs >has 9.5 out of 11 >inspite of not having opening book,hash tables,pondering >and even does not use the null move pruning that >seems to be a significant improvement relative to >the previous version. > >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.