Author: Robert Hyatt
Date: 10:25:04 03/21/01
Go up one level in this thread
On March 20, 2001 at 11:23:20, Miguel A. Ballicora wrote: >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 > > Are you sure you are using the optimizer? Crafty is not a fast program, so if you are 1/3 the speed of Crafty, it almost sounds like you are not running the optimizer at all when you compile... >> >> >> >> >>> >>>> >>>>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.