Author: Miguel A. Ballicora
Date: 08:23:20 03/20/01
Go up one level in this thread
On March 20, 2001 at 10:23:06, Robert Hyatt wrote: >On March 20, 2001 at 05:32:20, Tony Werten wrote: > >>On March 19, 2001 at 13:57:17, Bruce Moreland wrote: >> >>>On March 19, 2001 at 12:38:06, Miguel A. Ballicora wrote: >>> >>>>I just implemented in my program "Gaviota" the ability to process a epd file >>>>as a test. So I ran WAC in AMD K6-2 400 mhz 20 seconds each position >>>>and it solved 264 out of 300. How bad/good is that for a program that is ~2000? >>>> >>>>Regards, >>>>Miguel >>> >>>If you mean does that correlate, I'd guess it does. The stronger programs will >>>easily get somewhere over 290 in that time. >>> >>>It does suggest that you have some opportunity for improvement. My guess is >>>that you can still improve effective tactical speed by a factor of 20 or so. >>> >>>Recapture extension will help, as will null move R=2 if you are not doing it, >>>and a single-response-to-check extension. >> >>The last 2 are sure things, but be carefull with the first one. The >>recaptureextensions seem to be very program dependent. I took them out about a >>year ago and saw an improvement. >> >>They are the easiest to implement though so you should give them a try. They >>seem to help for smaller evaluationfunctions. >> >>cheers, >> >>Tony > > >I agree. How well they "work" often depends on how they are tested. IE >recapture on (crafty) solves the Bratko-Kopec position 22 (Bxe4) in 6 plies. >With it off, it takes 8 plies. Doesn't take much more time however. But in >games, I played several _thousand_ with recap on vs recap off. Recap off won >over 10% more of the games than recap off. That isn't a huge difference, but it >is a significant difference. I've had it off for a month or two now. > Thank you all for the replies. I am doing nullmove and recapture extensions. I am not doing single-response extensions; it is in my to-do list and I will certainly try it next. The recap. extensions I am doing is limited to recaptures of pieces of similar values, on the same square as long as in the only possible capture. I haven't tried yet to see how effective are different versions of recapture implementations. For now, this one is the one that does not give me a big increase in the tree size. I have some room for experimentation here. One of the reasons why my program does not solve more is that it is just painfully slow. It is doing average of 35 knps in a 400 mhz AMD K6-2. I think that is 3-fold slower than crafty for instance. When I tried to the test in 2 min rather than 20s correct answers were 286/300 Which, I think is more reasonable (not 290 as Bruce says, but close). I will take a closer look to the positions that can't solve fast to see why. At one point I will have to speed up my program somehow. My evaluation is still slim so I will need optimization to include more on it! Regards, Miguel > > > > >> >>> >>>bruce
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.