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 compromise
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
in
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 a
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
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/
> (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.
http://www.ya
> 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 f
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 possibl
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
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
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 applic
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
http://www.computer-go.org/mailman
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 for
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 l
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 l
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 r
it's in EXPTIME, with boardsize as the parameter.
s.
- Original Message
From: Don Dailey <[EMAIL PROTECTED]>
To: computer-go
Sent: Thursday, November 22, 2007 12:35:37 PM
Subject: [computer-go] The global search myth
Instead of responding individually, I would like to address a myth
it's in EXPTIME, with boardsize as the parameter.
Is it EXPTIME-complete ?
Do you have the precise statement of the complexity result:
is it the decision problem
"a go-ban --> white is in winning position" ?
Thks for any information.
___
computer-go
I agree with your exposition of search as it applies to chess, but
I think there is a qualitative difference in Go.
In chess, evaluators can see clear progress, in the form of material
balance and statically determined positional factors, so each additional
ply gives you more opportunity to see
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 Congress,
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 pro
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
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 9x
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 safety
That is not that hard to implement, given a proper definition of
"safety". Subqueries are left as an exercise to the reader :-)
AvK
___
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 thi
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 algorithm
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 signa
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 t
"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 tr
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
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 Teub
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 c
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).
Maybe this link is a bit more interesting..
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=sbcl&lang2=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.
> http://shootout.alioth.d
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
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 d
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
ht
2007/11/23, Jim O'Flaherty, Jr. <[EMAIL PROTECTED]>:
> 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
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
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 m
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 Swi
On Thu, Nov 22, 2007 at 08:47:47PM -0500, Don Dailey wrote:
> Fritz had this and the programmer often joked that the bottleneck in his
> program was those expensive memory references (referring to the piece
> square tables that made his program so fast.)His program was so fast
> that you could
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 human
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
larger
44 matches
Mail list logo
