Cgos 19x19 is back.
I hope electricity is stable :-)
Olivier
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
I, first, noticed that I might have readers especially Don
misleading with my previous mail. I used "we" for the participants
of cgos not "I and Don". I'm sorry if any.
Has "Hall of fame" with incorrect ratings any sense? Rather, it may
wrongly leads pepole, isn't it?
I won't discuss farther a
Darren Cook wrote:
> I wonder if you had anything to say on how the development was? I'm
> especially interested if you think if there was some aspect of the way
> libego is written that made it either hard work for you, or made it
> inefficient to wrap?
I don't think so, beyond being written in C
Gunnar Farnebäck wrote:
> Don Dailey wrote:
>> Also, even though we can ask people to never change their program unless
>> they give it a new login name, we can't enforce that, nor is it
>> reasonable to try. I might have a program with an on-line learning
>> algorithm which improves itself
Yes, I agree with all your points.
FFTW works by building test cases and testing them on the specific
processor it runs on. In other words, under program control, many
versions are produced just to see which one actually runs fastest.I
know the inventer of FFTW (Mateo Frigo of MIT) who a
> -Original Message-
> From: Jason House <[EMAIL PROTECTED]>
> To: computer-go
> Sent: Fri, 14 Dec 2007 2:23 pm
> Subject: Re: [computer-go] MC-UCT and tactical information
So, what tactical information should be calculated, how should it be used, and
yes how should it be stored?
Many Faces does on-line learning of Fuseki, Joseki, and half-board patterns.
David
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:computer-go-
> [EMAIL PROTECTED] On Behalf Of Gunnar Farnebäck
> Sent: Friday, December 14, 2007 1:28 PM
> To: computer-go
> Subject: Re: [computer-go]
Don Dailey wrote:
Also, even though we can ask people to never change their program unless
they give it a new login name, we can't enforce that, nor is it
reasonable to try. I might have a program with an on-line learning
algorithm which improves itself over time - it would be unreasonable t
> From: Jason House <[EMAIL PROTECTED]>
> I've done some dabbling (thought experiments) with how I'd like to cache
search results and I'm not yet happy with any of them. Not taking into
account miai and such logic could > > lead to excessive storage bloat. I'd
love to enter a discussion talk
On Dec 14, 2007 12:43 PM, <[EMAIL PROTECTED]> wrote:
> For purposes of discussion, let's say the bot takes a tactical snapshot
> once at the root node and then uses that information to help pick a move. It
> can apply it at the root, at internal nodes, at external nodes, or at the
> very end (mayb
> -Original Message-
> From: Jason House <[EMAIL PROTECTED]>
> To: computer-go
> Sent: Thu, 13 Dec 2007 6:30 pm
> Subject: Re: [computer-go] MC-UCT and tactical information
> ...
> "Change for the better" seems to imply only a one-sided analysis.? I would
> imagine any analysis wo
Don Dailey wrote:
>By the way, I am no fan of C. I don't like C and have tried some of
>the languages on your list of languages that are supposedly faster than
>C.
>
>I think you must be getting your information from the web pages for
>those languages. As a general rule any reasonably fast l
On Dec 14, 2007 10:55 AM, Nick Wedd <[EMAIL PROTECTED]> wrote:
> I'll bet that if someone ever does write a go-playing program that
> adapts its play in the light of what happens in the games it plays, I'll
> eventually be able to train it to make some _really_ bad moves.
That trick works again
In message <[EMAIL PROTECTED]>, terry mcintyre
<[EMAIL PROTECTED]> writes
- Original Message
From: Rémi Coulom <[EMAIL PROTECTED]>
For instance, against computers, I estimate that Crazy Stone improved
about 3 stones between this summer and now. But it clearly did not
improve 3 stones o
By the way, I am no fan of C. I don't like C and have tried some of
the languages on your list of languages that are supposedly faster than
C.
I think you must be getting your information from the web pages for
those languages. As a general rule any reasonably fast language is
going to cla
Stefan,
Yes, in special cases you can outperform C.
I don't claim that it might not be possible with better compiler
technology to outperform C. I'm keeping my eye on D because it
promises to be one of those languages.
But the truth of the matter, despite the promises, C is the best
perfor
Darren,
Thank you for posting the links. Very nice. It could be my lack of
understanding the intention of each of the tests, but it looks like most of
them are micro-benchmarks, meaning there is single or very few methods calls
and a very well defined micro-space. I can understand how doing so
Due to electricity shutdowns in our university, I will wait a few
consecutive hours
with constant electricity before starting the 19x19 cgos server again.
Sorry for that. Be sure I am in bigger trouble
than you with these electricity shutdowns :-)
Olivier
Darren Cook <[EMAIL PROTECTED]> writes:
> Stefan, judging by this site (which I posted some links from
> yesterday) your intuition is correct:
> http://shootout.alioth.debian.org/
To clarify: I don't really like these non-scientific benchmarks (in
many cases I assume no one or only really few p
On 14/12/2007, Nick Apperson <[EMAIL PROTECTED]> wrote:
> C++ is "faster" than C because the STL (and other generic code) allows the
> programmer to spend their precious time optimizing the bottleneck and using
> a very fast default for less critical places. For a sufficiently small
> program how
Look,
I love C++ and I'd love to say look I told you all, C++ is the fastest,
but frankly it just doesn't work like that. When we come to a point where
every programmer writes the fastest possible code their language could
create then we have some kind of a comparison.
C++ has a philosophy
>> I thinks it's very difficult to outperform C since C really is just
>> about at the level of assembly language.
>
> No, in special cases it's not that hard to outperform C, because the
> language spec dictates some not so efficient details. C has an ABI and
> it's specification is optimized for
22 matches
Mail list logo
