Author: Dann Corbit
Date: 14:41:53 06/02/04
Go up one level in this thread
On June 02, 2004 at 17:27:52, James Swafford wrote: >On June 02, 2004 at 16:58:01, Dann Corbit wrote: >>On June 02, 2004 at 16:07:14, James Swafford wrote: >>>On June 02, 2004 at 16:03:10, James Swafford wrote: >>>>On June 02, 2004 at 10:06:22, Dann Corbit wrote: >>>>>On May 29, 2004 at 16:13:24, James Swafford wrote: >>>>>>On May 29, 2004 at 14:15:37, Frank Phillips wrote: >>>>>>>On May 29, 2004 at 12:53:54, James Swafford wrote: >>>>>>>>On May 29, 2004 at 11:53:29, Frank Phillips wrote: >>>>>>>>>On May 29, 2004 at 11:44:58, James Swafford wrote: >>>>>>>>>>On May 29, 2004 at 11:35:07, Frank Phillips wrote: >>>>>>>>>>>On May 29, 2004 at 04:00:31, Gian-Carlo Pascutto wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>I don't think so. The program still has weaknesses that a bit of >>>>>>>>>>>>extra hardware will not overcome. >>>>>>>>>>>> >>>>>>>>>>>>GCP >>>>>>>>>>> >>>>>>>>>>>What are these weaknesses? >>>>>>>>>>> >>>>>>>>>>>Bob may even be able to fix them before the event. >>>>>>>>>> >>>>>>>>>>He was talking about his program, not Crafty. >>>>>>>>> >>>>>>>>>Thanks. I misread the post. >>>>>>>>> >>>>>>>>>But I am still interested in the weaknesses being referred to by GCP, which are >>>>>>>>>resistant to faster hardware. I have so many myself. If only I knew what they >>>>>>>>>were :-) >>>>>>>> >>>>>>>> >>>>>>>>As in, "I can't seem to mate Shredder, even with faster hardware!" ?? :) >>>>>>>> >>>>>>>>-- >>>>>>>>James >>>>>>> >>>>>>> >>>>>>>I guess the answer is yes, although I have never had better hardware - and am >>>>>>>not SMP, so probably never will. >>>>>>> >>>>>>>See you tonight at ICC author's only tournament ? :-) >>>>>> >>>>>>NOt as a competitor-- my thing is nowhere near strong enough >>>>>>to compete yet. I'm hoping to be able to compete in the next >>>>>>CCT, though. >>>>> >>>>>Are you still doing the learning stuff? >>>> >>>>I've been working with TDLeaf quite a bit. At some point I'll >>>>post something with some meat to it, but to sum it up, I'm >>>>not nearly as optimistic about it as I once was. >>>> >>>>In my experience, TDLeaf can train the material weights, and it >>>>can even produce an evaluation vector that's superior to a >>>>'material only' vector. I am not convinced it's useful for >>>>training a complex vector, nor am I convinced it does a better >>>>job than hand tuning. For that matter, I am not even >>>>convinced it converges to the optimal vector! >>>> >>>>Caveat: it's possible (though I think it's unlikely) that >>>>my implementation is flawed. My engine will become open source >>>>at some point (maybe after the next CCT), so you can judge >>>>for yourself then. >>>> >>>>Will Singleton and I had a bet on this... I conceited defeat >>> >>> >>>Gah! I "conceded" defeat. >>> >>>>the other day. THe original bet was for the loser to fly >>>>the winner and spouse across country for drinks. :) I'm >>>>pretty sure Will's decided he'll forego that if I show up >>>>at a tourney, but that's his call. >>>> >>>>I'm still very interested in learning algorithms, but I'll >>>>be focusing on improving my evaluation for a while. >>>> >>>>Again- I will post some data at some point. >> >>I am doing a computer guided optimization for Beowulf. >> >>It takes ~12,000 positions from super-GM games and SSDF games among the top >>computers where all the participants chose the same move (no other moves chosen >>for that position). >> >>For each of about 100 parameters, I vary the value from too small up to too >>large (e.g. a knight might go from 200 centipawns to 450). At some optimal >>point, the largest number of positions will be chosen. I fit a parabola >>throught the data ans solve for the maxima (if any). >> >>Often, the variance of the parameter has no effect on the solution scores (for >>instance, I might get 5500 solutions no matter what the parameter is, or the >>number of solutions may vary randomly). So I also solve for the minima of the >>time curve. As an example, a depth 4 search using NULL MOVE will probably solve >>a few LESS positions than not using NULL MOVE, but it will take 1/3 of the time >>at some optimal prune level. >> >>I have had lots of bugs in my curve analysis, but I am slowly working it out. >> >>Before, I solved for a smaller subset of tactical positions which made it great >>at solving those tactical positions but lousy at playing. I am hoping for a >>better result this time (especially since some of my result calculations were >>backwards, making the fits enormously unstable). > > >That is fascinating. Would you explain in more detail how you went >about choosing the positions? I see extracted positions from very high >quality games, but I don't understand what you meant by "all >participants chose the same move." Imagine the starting position with 20 possible moves. In a large set of GM and SSDF high quality games there will be many choices for it. So I throw it out. Only positions where every player chose the same move are used. That way, I know that the choice is a very, very good one. >Do you mean that you (1) took a position (and the move made in that >position) from a game and then (2) looked in other games for the >identical position, and if found (3) compared the moves, keeping >the position if the moves matched? > >IN the case of the knight that might vary from 250->400; how much >would you increment for each run? 5? 10? I take (max-min)/6 as increment, but for small values where the division would be something like 1.8 it gets truncated to 1, so there are more values tried. I think that is better because on a narrow band I am very interested in small changes anyway. >It seems you need to watch for local optima. Perhaps you find >"optimal" for parameter A, then move on to find "optimal" for >parameter B, but perhaps some other combination of both would've >done even better. If you extend that out to all combinations, >the number of possibilities is truly staggering. Any thoughts >on that? Maybe a random mutation here and there? It's clearly intractible to solve every combination. I am hoping to get an effect similar to simulated annealing. >Your time curve analysis is spot on: very clever. > > >I learned in early TDLeaf experiments with Prophet that if you get >crushed tactically (as Prophet usually did at the time), you >begin to train the eval to predict tactical blunders. So- I >improved my search a bit and tried again. > >I think part of the problem now is that my eval is too simple. >I deliberately kept the eval very simple, thinking I could >do a "proof of concept" type thing, then just start throwing >terms in, letting TDLeaf train the weights. Well, what you >start to see is outrageous values for some parameters to >compensate for missing knowledge. Perhaps such 'outrageous' >values could actually serve to point out exactly what's >missing, but I don't know how yet. > >Anyway, I think parameter training of some flavor will be >one of the next 'big things'. What would be _really_ cool, >though, is learning not only how important a term is, but >finding new terms! (i.e. pattern recognition and all that) > >Good luck with your project: it sounds like a sound idea... :) > >-- >James
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.