Re: [computer-go] Drunken sailor on payday

2007-11-22 Thread Raymond Wold
Don Dailey wrote: Raymond Wold wrote: On Wed, 2007-11-21 at 14:11 -0500, Don Dailey wrote: Experience in a language is a factor, but nobody refutes that properly coded C is fastest (next to properly code assembly) and if performance is your goal, then anything else accepts some

Re: [computer-go] Re: compiler optimizations

2007-11-22 Thread Raymond Wold
Dave Dyer wrote: Arguments about the quality of compiler optimizations vs. hand coding are pointless, because programmers optimize programs in ways that compilers are (correctly) forbidden to do; by changing the algorithm. I've heard of no such law or rule. There are several compilers or

Re: [computer-go] Drunken sailor on payday

2007-11-22 Thread Jacques BasaldĂșa
Raymond Wold wrote: Do you have anything to back this up? I was under the impression that most decent assembly programmers agreed that they can't compete with the best C compilers. Absolutely NOT. Only the typical, perhaps 99.9% of the programs, made of: transfers, conditionals, integer

Re: [computer-go] Drunken sailor on payday

2007-11-22 Thread Raymond Wold
Jacques BasaldĂșa wrote: Of course, what is cool is very subjective debate: Some people find it cool to depend on runtimes that increase at mega/month rate, do what the API already does only much worse, gift the user with the gray rectangle experience even on a quad-core. After two seconds of

Re: [computer-go] Drunken sailor on payday

2007-11-22 Thread Benjamin Teuber
Full agreement - I'll write more later when I find the time :) ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/

Re: [computer-go] Re: more on languages

2007-11-22 Thread steve uurtamo
(1) the quality of the development environment. my development environment is an xterm. is that a handicap? s. Get easy, one-click access to your favorites. Make Yahoo! your homepage.

Re: [computer-go] Drunken sailor on payday

2007-11-22 Thread steve uurtamo
As far as I can tell, the optimizations that a compiler can't do are higher-level optimizations that can be done in C and wouldn't require the programmer to write assembly, or am I wrong about this? just take a look at the generated assembly sometime and you'll see things that you can make

Re: [computer-go] Drunken sailor on payday

2007-11-22 Thread Don Dailey
terry mcintyre wrote: A bird's-eye view of computer-Go programming: a large part of what a Go program does will probably be some sort of analysis of a deep tree of possible moves, involving the exploration of millions of possible positions. The guts of this should be as optimal as possible.

Re: [computer-go] Re: Drunken sailor on payday

2007-11-22 Thread steve uurtamo
one seemingly overlooked aspect of the whole speed vs. devel. time argument is that in order to actually *test* to see how strong your code is, you need to compete with it. once you do so, you will immediately see how cycles matter. i only know this because i've done some testing of various go

Re: [computer-go] Re: more on languages

2007-11-22 Thread Don Dailey
steve uurtamo wrote: (1) the quality of the development environment. my development environment is an xterm. is that a handicap? s. No, you are in a good development environment :-) - Don Get easy, one-click

Re: [computer-go] Re: more on languages

2007-11-22 Thread Benjamin Teuber
How about this conclusion: We all know that the choice of language depends on what you want to do with it. There are dynamic, well-supported but slow languages with many libraries like Ruby or Perl, which I'd want to use for something that doesn't need too heavy computation like GUI or web

[computer-go] Obtaining Archvies

2007-11-22 Thread Joshua Shriver
Is there a place online or via this mailing list where you can request an archive of older posts? Preferably the entire set for offline reading and parsing? -Josh ___ computer-go mailing list computer-go@computer-go.org

[computer-go] The global search myth

2007-11-22 Thread Don Dailey
Instead of responding individually, I would like to address a myth in one message.The myth is that any kind of global search, whether it be alpha/beta, or the currently explored best first search methods is a foolish approach and that there is a some kind of constant time elegant algorithm

[computer-go] Re: compiler optimizations

2007-11-22 Thread Dave Dyer
Languages like SQL and Prolog don't specify algorithms, they describe the desired result. I agree that the quality of compilers that turn these specifications into algorithms can improve dramatically, and that this kind of specification is a great way to increase the productivity of programming

[computer-go] Re: compiler optimizations

2007-11-22 Thread Dave Dyer
Languages like SQL and Prolog don't specify algorithms, they describe the desired result. I agree that the quality of compilers that turn these specifications into algorithms can improve dramatically, and that this kind of specification is a great way to increase the productivity of programming

Re: [computer-go] Obtaining Archvies

2007-11-22 Thread the Robot Vegetable
wget -r http://computer-go.org/pipermail/computer-go/ Others maintain or possess older archives - I do not. On Thu, 22 Nov 2007, Joshua Shriver wrote: Is there a place online or via this mailing list where you can request an archive of older posts? Preferably the entire set for offline

Re: [computer-go] The global search myth

2007-11-22 Thread steve uurtamo
it's in EXPTIME, with boardsize as the parameter. s. - Original Message From: Don Dailey [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Thursday, November 22, 2007 12:35:37 PM Subject: [computer-go] The global search myth Instead of responding individually, I

Re: [computer-go] The global search myth

2007-11-22 Thread steve uurtamo
it's PSPACE-hard and EXPTIME-complete, although this is dependent upon the rules involved. i think that superko changes things a tiny bit. in any case, it's brutally difficult as the boardsize increases. JM Robson, The Complexity of Go. In Information Processing; proceedings of IFIP

Re: [computer-go] Re: compiler optimizations

2007-11-22 Thread Don Dailey
Dave Dyer wrote: Languages like SQL and Prolog don't specify algorithms, they describe the desired result. I agree that the quality of compilers that turn these specifications into algorithms can improve dramatically, and that this kind of specification is a great way to increase the

Re: [computer-go] Re: The global search myth

2007-11-22 Thread Raymond Wold
Don Dailey wrote: So I must give up on this. I know if I do the plot again someone will say, it only applies to depths we can currently test. Surely it will flatten out next year when the new processors come. I cannot answer to those arguments when no evidence is presented to back it up

Re: [computer-go] The global search myth

2007-11-22 Thread steve uurtamo
to be fair, i'm not sure that this means much at all. for the 19x19 case in go, this could all just be wrapped up in some constant somewhere in front of someone's uber-clever code that takes advantage of the particulars of 19x19 go. similarly for chess on an 8x8 board. perhaps this means that

Re: [computer-go] Re: compiler optimizations

2007-11-22 Thread Moi de Quoi
On Thu, 2007-11-22 at 10:10 -0800, Dave Dyer wrote: Getting back to go In my dreams I could write select groups where safetyalpha and sizebeta and color=black That is not that hard to implement, given a proper definition of safety. Subqueries are left as an exercise to the

Re: [computer-go] Re: The global search myth

2007-11-22 Thread Don Dailey
Hi Dave, You are doing it.No matter what evidence is presented, people will find a way to say it doesn't exist.As I mentioned earlier, the argument was that didn't apply to chess except for the first 4 or 5 ply - then when that didn't happen they expanded it to the first 6 or 7 and to

Re: [computer-go] Re: compiler optimizations

2007-11-22 Thread Raymond Wold
Dave Dyer wrote: Languages like SQL and Prolog don't specify algorithms, they describe the desired result. What's the difference? The two are very much intermingled when you get to high-level optimizations. I agree that the quality of compilers that turn these specifications into

Re: [computer-go] Re: The global search myth

2007-11-22 Thread Magnus Persson
My experience from doing search only with Valkyria, is that Go is not different to Chess in the sense that each extra ply really makae a difference. Improving evaluation almost always means that search gets deeper in UCT-type programs. Monte-Carlo simulation + knowledge gives a better

Re: [computer-go] Drunken sailor on payday

2007-11-22 Thread Don Dailey
C is the one true language and must be indented with the one true brace style :-) - Don Stefan Nobis wrote: Benjamin Teuber [EMAIL PROTECTED] writes: Man, we really need a complete Common Lisp Go Framework which also has some fast low-level code to show all these C gurus its true power

Re: [computer-go] Drunken sailor on payday

2007-11-22 Thread Stefan Nobis
Benjamin Teuber [EMAIL PROTECTED] writes: Man, we really need a complete Common Lisp Go Framework which also has some fast low-level code to show all these C gurus its true power :) I think so, too. :) I don't want to say CL is the one and only language (for me surely it is), I only try to

Re: [computer-go] Re: compiler optimizations

2007-11-22 Thread Stefan Nobis
Dave Dyer [EMAIL PROTECTED] writes: Languages like SQL and Prolog don't specify algorithms, they describe the desired result. Take a look as Haskell -- it's a very high level language but functional, so you are describing algorithms in it. Yet the compiler has so much knowledge (because of a

Re: [computer-go] Drunken sailor on payday

2007-11-22 Thread Don Dailey
Stefan, What is the state of common lisp these days?What is fastest compiler for X86 and how does it compare to C code in performance? I was either going to experiment with Forth or lisp in the near future. I will get around to both eventually. - Don Stefan Nobis wrote: Benjamin

Re: [computer-go] Drunken sailor on payday

2007-11-22 Thread Don Dailey
I'm also curious about scheme compilers and the quality of code they generate. Does anyone have the dirt on these? - Don Stefan Nobis wrote: Benjamin Teuber [EMAIL PROTECTED] writes: Man, we really need a complete Common Lisp Go Framework which also has some fast low-level code to

Re: [computer-go] Drunken sailor on payday

2007-11-22 Thread Benjamin Teuber
AFAIK, CMUCL is the fastest free lisp available. But I would rather stick with its offspring, SBCL, which might be a bit slower, but it is being worked on actively, it is quite portable (http://sbcl.sourceforge.net/platform-table.html) and it supports native threads (CMUCL just has green threads).

Re: [computer-go] Drunken sailor on payday

2007-11-22 Thread Benjamin Teuber
Maybe this link is a bit more interesting.. http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=sbcllang2=gcc On Nov 23, 2007 12:30 AM, Benjamin Teuber [EMAIL PROTECTED] wrote: Of course it's not easy to compare speed of different languages, but e.g.

Re: [computer-go] The global search myth

2007-11-22 Thread Matthew Woodcraft
Don Dailey wrote: Back then the ELO curve was not understood. The basic formula was eventually found that 1 ply added 250 ELO rating points to a program. [...] At some point, some incredibly foolish programmers at Northwestern University built a program and decided that it was too hard to do

Re: [computer-go] The global search myth

2007-11-22 Thread Don Dailey
Can you elaborate on the relation between the 'ELO curve' and the improved evaluation functions? Is it that if you took this original 'brute force' program and ran it on current hardware, it would gain 250 rating points per ply, and the improved evaluation functions allow modern programs to

[computer-go] Re: Environmental Go

2007-11-22 Thread Sanghyeon Seo
Some more information: Date: 2007-11-28 and 2007-11-29 Place: Hanguk Kiwon Players: An Joyeong 9p Song Taegon 8p Weon Seongjin 8p Han Sanghun 1p Rui Naiwei 9p Jiang Zhujiu 9p -- Seo Sanghyeon ___ computer-go mailing list computer-go@computer-go.org

Re: [computer-go] Re: The global search myth

2007-11-22 Thread Jim O'Flaherty, Jr.
Seo, All I described was the scientific method plus simple probability theory combined with using intuition to explore unknown unknowns creatively. For a layman's explanation into this world, see the works by Talib of Fooled by Randomness and The Black Swan. Not sure about your analogy

[computer-go] computer languages

2007-11-22 Thread Don Dailey
Has anyone looked at a lisp variant language called lush? It's a variation of lisp where you can freely mix C code that gets compiled. You can also make little C functions, compile them, then run them as lisp functions. - Don ___ computer-go

Re: [computer-go] Drunken sailor on payday

2007-11-22 Thread Russell Wallace
On Nov 22, 2007 12:13 PM, Jacques BasaldĂșa [EMAIL PROTECTED] wrote: I am still waiting to meet the first person who answers affirmatively to the question: Have you ever paid for a program written in Java? *raises hand* You need wait no longer ^.^ - and that was back in the days when Swing

[computer-go] Environmental Go

2007-11-22 Thread Sanghyeon Seo
http://senseis.xmp.net/?EnvironmentalGo Korean newspapers reported that Berlekamp will hold a league of environmental go games between six top Korean professional players, and analyse the result. I think this will give us a better sense of the gap between the perfect play and the current top

Re: [computer-go] Re: The global search myth

2007-11-22 Thread Jim O'Flaherty, Jr.
Don, I think it is tenuous to predict, much less emphatically assert, that just because the evidence is linear at the lower scale, it remains so at higher scales. While it is reasonable to assume, it is not certain. I see your point that at this time, your theory about it applying to