Hi Jim, I feel similarly to you.
I have to take exception to what someone posted earlier - Java keeps getting presented as some kind of high level language than enables a natural expression of ideas. This is total garbage. Java is a low level language and very much a C dialect. I don't understand where people are getting this - but I think it's because it's their pet language and they want to believe it's somehow extra special. There are no special languages. If they wanted to make an argument for an expressive language, then they would be hyping scheme, ocaml, lisp or something more exciting than C like languages. I personally don't feel the language really gets in the way that much. Ok, now about experimentation. I believe in spending a significant time looking for the breakthroughs. Most breakthroughs are not orders of magnitude of advancement, but they are simply wonderful discoveries that are clearly better than minor incremental things. For instance in chess it was things like "check extensions", a simple idea that was quite valuable and not seriously considered previously. Hash tables, null move pruning etc. They came one after another over several years. The latest rage is move reductions (although often it turns out that certain techniques have been used for years but not advertised or known - such as reductions.) I'm not that familiar with the very early days of computer go, but I would assume that the intelligent usage of "patterns" was a big deal when it was first discovered. The only other real breakthrough I can think of is clever local searches - but I might be corrected on this. But that's why I'm currently interested in Monte/Carlo. Right now it's the most promising way forward. That might change next year - but I don't see any long term future in tweaking patterns and doing more local searches to make incremental progress. I believe that MC will be the only way to write a GO program in the near future leaving the other stuff in the dust (like Mogo has with 9x9 Monte Carlo Go.) This happened in computer chess several times, someone came up with some breakthrough idea, proved it with actual results and everyone else had to play follow the leader to catch up. Time could prove me wrong - I have learned that humans have a short horizon view - we cannot accurately see much ahead of us. - Don On Thu, 2006-11-30 at 13:07 -0600, Jim O'Flaherty, Jr. wrote: > Wodzu, > > There are roughly two types of approaches to bettering the skill of > computer go solutions; incremental and breakthrough. I think for > incremental solutions, ones where lots of work results in small shifts > in better go playing performance, you are correct. Any optimizations > around execution speed will result in better go playing performance per > time-unit. This is important if the measurement is winning current > computer_go competitions. > > However, what I hear quite a few people saying is they are looking for > "breakthrough" types of go skill improvement, and more at the > application level as opposed to the individual lines of code. And to do > that, their needs around adaptability are more influential on their > primary constraint (personal time, not eventual execution speed). Their > focus is on being able to complete more experiments per personal time > unit with the hope of stumbling into a new "domain" where the go playing > performance takes an order of magnitude leap ahead. Once in the new > domain, the priorities for the person may shift back to incremental as > they begin to see what kinds of limits the new technique might provide. > This is where I am at personally. I am far more interested in > probability based techniques as opposed to perfecting tactics/fighting > strategies. I am very happy others are more interested in those areas. > It's a good match. > > There are short-term benefits to the incremental approach. However, it > likely has a much closer threshold of diminishing returns if one follows > the standard constraint reduction techniques, largest first, etc.. At > which point, all the optimizations start fighting with any attempts to > "change" and/or "expand" newer ideas, techniques and experiments in an > effort to continue making progress. Once one has prioritized code > execution speed optimizations as a root value in moving a system > forward, almost always there is a large loss in adaptability with the > eventual result being the person abandons the bulk of the previous code > base to essentially start from scratch. In many, if not most, cases, > the error persists in the new approach as the fixation on maximizing > execution speed remains too high resulting in a rapid pruning of > possible exploration options. > > There is no short answer to the Go problem. It is going to takes lots > of investment by both the code speed optimizers (incremental) and the > new technique inventor/innovators (breakthrough) and an effective > integration of both before we see result substantially superior to what > we experiencing right now. Personally, I have been enjoying the > discussions around the progress being made on the UTC/Monte Carlo > techniques. I am eager to start playing in that domain. > > > Jim > > > Wodzu wrote: > > > > > > > >>> Huh, why not use Pascal? It has speed of C and > >>> simplicity of Java :) > >> > >> heck, you could use perl. plenty of packages > >> available (it can even be made multithreaded!), > >> shared memory packages, etc. > >> > >> i mean, if speed isn't your top concern... > >> > > > > i think speed is one of most important things beacuse it affects > > strength of the program ;) (if the time for move is restricted) > > anyway, chosing a proper (fastest) algorithm has crucial meaning and > > other things like language, used data structures and so on, have less > > meaning in improving speed. > > thats my opinion, regards. > > _______________________________________________ > > computer-go mailing list > > computer-go@computer-go.org > > http://www.computer-go.org/mailman/listinfo/computer-go/ > > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
