Author: Koundinya Veluri
Date: 17:51:12 10/18/01
Go up one level in this thread
On October 18, 2001 at 12:05:20, Miguel A. Ballicora wrote: >On October 18, 2001 at 02:06:17, Koundinya Veluri wrote: > >>I ran them for 1 hour maximum, 5 million nodes minimum. Results are here: >>http://www.ecf.utoronto.ca/~veluri/WCSAC%20cleaned.txt >> >>Only one wasn't solved: >>k1q1bbrr/1p3pp1/p7/5n1n/PP2N2p/1NP5/1BB1Q1PP/2R2R1K b - - bm Bb5; id >>"WCSAC.0582"; >> >>This one takes a long time even with some help moving forward and backward. >>Plus, if you see the output for this position you'll see that the branching >>factor _sucks_ in my program once it reaches 11 ply. I gotta do something about >>that... >> >>Koundinya > >Thanks, I have the times to solution of Crafty, YACE and my program (on a K6-II >400 mhz, what's your hardware?). Hi Miguel, Sorry forgot to mention the hardware. It's P4 1.7 GHz, 68 MB hash tables. >I will post the comparison of all of them. >Rebel times are just amazing (excet the mate in 11!). Unfortunately Vincent do >not care to post DIEP's which seemed to be very good too. > >For some reason, Crafy does poorly in this set of positions and Deep Fritz >had problems with one particular position. Very funny. Somehow, I think >that nullmove can create some problems and if you do more things on the qsearch >(checks) it will show here, but it is just a _wild_ guess. DIEP apparently >is solving many positions in less plies than other programs and Vincent claim >that he does several things on the qsearch. Maybe the extensions are important. About doing checks in the qsearch, I haven't yet found a single position where it makes a difference in the solution. It slows down the search in general though so it may not be a good idea after all. I am currently using checks in qsearch but I think it will help only if I plan to catch mates in the qsearch... Koundinya
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.