it will only assign it a positive probability of being
dead if there are playouts where the group dies, right?
s.
- Original Message
From: ivan dubois [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, January 23, 2008 10:51:52 AM
Subject: Re :
this is not the case, please explain to me.
Ivan
- Message d'origine
De : steve uurtamo [EMAIL PROTECTED]
À : computer-go computer-go@computer-go.org
Envoyé le : Mercredi, 23 Janvier 2008, 17h22mn 35s
Objet : Re: Re : [computer-go] Bent four in the corner was:Scalability
problem of play-out
maybe this doesn't sound right to everyone,
but i thought that suicide and filling one-point
eyes were both things that could be highly
useful in many corner positions where you either
want to create a nakade (fill the eye), or threaten
one (with suicide).
s.
- Original Message
From:
did you optimize parameters in MFGO by playing against
gnugo?
that'd do it.
s.
- Original Message
From: David Fotland [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Sunday, January 6, 2008 12:52:10 PM
Subject: [computer-go] Odd results on 19x19
The styles of CS
you can use a multi-d ranking system to predict
the outcome of a contest between two players.
this is good for handicapping, for instance.
this will not necessarily create a linear ordering
of the players, as you've mentioned, but it is still
quite useful, and radically more efficient and useful
have your bot resign, for your own good
On Jan 4, 2008 4:44 PM, Gian-Carlo Pascutto [EMAIL PROTECTED] wrote:
steve uurtamo wrote:
It was my understanding that the netlag to the Philippines was about
380 ms; accounting for an additiaonal 15% packet loss and we end up
at about 440 ms.
i
s/UCP/UDP/g;
- Original Message
From: steve uurtamo [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Friday, January 4, 2008 7:50:34 PM
Subject: Re: [computer-go] Please have your bot resign, for your own good
TCP/IP communication can be viewed as round-trip.
UCP
--- 208.100.19.102 ping statistics ---
22 packets transmitted, 19 received, 13% packet loss, time 21134ms
rtt min/avg/max/mdev = 327.380/352.887/425.192/25.698 ms
this is really pretty darn good, given the setup.
the primary delay inbetween japan and the US is the speed of light
delay
i like don's idea about using fischer time. byo-yomi seems to be
the obvious solution to the problem (just make it a small byo-yomi time,
something like 5 seconds), but fischer time has some pretty magical
features that computers can easily take advantage of. time management
should be quite a
* compile time rather than runtime portability
* lack of dynamic modifications of the runtime
not to be too contrary, but i'm not sure that these two things
are all that safe, in the security sense that i'd like for, say, a
kernel to be safe. perhaps i'm misunderstanding what they imply.
s.
hey, something fun!
keeping pipelines full and carefully scheduling when cache
will be flushed is another. not as performance-killing as branching,
perhaps, but equally tedious to do by hand. one very cool thing
about the ultrasparc (and likely many other processors) is that it
could schedule 4
Currently there is no evidence whatsoever that probability estimates
are
inferior and they are the ones playing the best GO right now
are they?
s.
Looking for last minute shopping deals?
Find them
Ratings are not reality.
i think that we can probably say that a rating system
for, say, 19x19 go with komi relative to handicap and
time controls roughly the same for each contest (or not,
you choose!) is anything that turns a set of:
(p1,p2,h,t,r) [player 1, player 2, handicap, time, result]
(p1,p2,h,t,r) [player 1, player 2, handicap, time, result]
i should have said that i mean time here to be the
actual date/time that the contest occurred, since skill
can (and often does) change over time.
also the p1,p2 should be taken to be ordered, so that we
know who was black and who was
two followups, and i'm sorry for not referencing the
original notes directly:
i) i agree that 9x9 has fewer standard deviations of
skill. there's simply less to be good at (ladders are
tiny, life and death can only be so large, the difference
between influence and territory is skewed, etc.).
not to put too fine a point on it, but estimating dan ranks via
9x9 games is a bit silly. it doesn't actually capture any extra
information about the program, since there's no such thing as
a 9x9 rank to compare with/against, much less a dan rank.
ELO works well because it's strictly arbitrary
is this going to be broadcast on kgs, or is there
some other way to watch the games?
thanks in advance,
s.
- Original Message
From: Sanghyeon Seo [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thursday, November 22, 2007 9:28:32 PM
Subject: [computer-go] Re:
(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.
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
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
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
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
that 9x9 code cannot be thrown at a 19x19 board
and hope to have only a polynomial in (19/9) decrease in strength, but
i haven't proven this.
s.
- Original Message
From: steve uurtamo [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thursday, November 22, 2007 3:02:31 PM
In theory, a perfect compiler given enough time would optimize all
languages to the same machine code if the program does the same thing.
actually, to be a bit nitpicky here, you can't do this. not even for
a single language.
s.
as an aside, although not strictly useful for anything other than
what it was intended (what is?), matlab is a great
example of where loose typing can get out of
hand. just one or two extra characters here or
there, and all of a sudden the NxMxYxW matrix
represented by the letter g has undergone
you guys are forgetting *all* about
internationalization. i mean, do you
really think that i can parse that xml
if i don't even know what character set
i'm supposed to be using?
s.
- Original Message
From: Nick Apperson [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
And it's not fast either. Free() has a reputation of being
slow, and that's not surprising if you look at the way it is
almost always implemented: scanning a list of addresses in
order to amalgamate the newly freed memory with adjacent free
areas.
this is a burden for the OS, not a defect in
whew. i need to switch out my ascii, then.
s.
- Original Message
From: Lars Nilsson [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, November 14, 2007 10:10:15 AM
Subject: Re: [computer-go] Language
On 11/14/07, steve uurtamo [EMAIL PROTECTED] wrote
I just wanted to point out that free() is not a system call. The heap is
handled by the
C library, and the OS is mostly not involved in it.
my bad. thanks. :)
in that case, i'm impressed that i can do 2GB allocations.
s.
: Re: [computer-go] Language
On Nov 14, 2007 10:54 AM, steve uurtamo [EMAIL PROTECTED] wrote:
I just wanted to point out that free() is not a system call. The heap is
handled by the
C library, and the OS is mostly not involved in it.
my bad. thanks. :)
in that case, i'm impressed
I would like some language recommendations. Requirements:
Runs in Linux
Has garbage collection
Fast
Well supported
Can interface with MPI (can make C calls)
Hope this doesn't start a war.
---
let's see...
C
garbage collection: free().
very fast.
s.
i suspect most people plays always at a certain time of the day, in
their
timezone, so currently there might be 3 cliques: Asia, Europe, and
Americas.
there are also two other cliques: blitz and non-blitz.
watching a randomly chosen game among very strong players on
kgs, most will be blitz.
while neither a normal distribution nor integer
based, the following is relatively fast and may
be useful for you (you might need to slide things
around so that you get the maximum value
where you want it and ignore the rest)
check out the poisson distribution:
-go.org
Sent: Wednesday, November 7, 2007 3:26:29 PM
Subject: Re: [computer-go] use for Monte Carlo on 19X19?
steve uurtamo said:
i wonder what is known about the set of unconditionally
dead and unconditionally living groups. there must be
something like a small and extremely fast mechanism
and which, i agree, gives far too much credit to MC players,
since they roughly emulate this line of play purely by accident.
I don't agree with that.There is no accident here, MC really only
cares about winning and has no ego about winning big.
It was intended as a little play on
If you're ahead and go for a bigger win, generally you're
just risking more to gain more when you don't need more.
there is *absolutely* no advantage from a game-theoretical
point of view to try to win by more than 0.5 points. and in
practice, it's generally not a great idea to try to win by any
As results from children get aggregated, the parent node can repartition what
fraction of its
resources to dedicate to each subtree.
um, doesn't this mean sending out messages to every child for every
repartitioning?
s.
__
Do You Yahoo!?
why not just ignore game results that took place in
fewer than 10 moves?
then black can play his handicap stones, white can
pass, and everyone's cool.
s.
- Original Message
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Monday, October 29, 2007
there's not really much sense in a game 'won' in the first 10 moves.
i.e. i mean that it doesn't have much intrinsic meaning. i think
it's fair to throw away game results that have this feature to them,
then only cooperating programs will have their results counted.
s.
- Original Message
Subject: Re: [computer-go] 19x19 CGOS
On Mon, 29 Oct 2007, steve uurtamo wrote:
there's not really much sense in a game 'won' in the first 10 moves.
i.e. i mean that it doesn't have much intrinsic meaning. i think
it's fair to throw away game results that have this feature to them,
then only
ah, well, okay then. :)
s.
- Original Message
From: Christoph Birk [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Monday, October 29, 2007 6:24:41 PM
Subject: Re: [computer-go] 19x19 CGOS
On Mon, 29 Oct 2007, steve uurtamo wrote:
or to simply not include
Many of those complaining about XML don't seem to really know too much
about
it.
Dude. It's a file format.
File formats don't solve problems. Data structures solve problems.
XML is not a data structure, it is a very loosely specified way to arrange tags.
By becoming so multipurpose it has
I'd still like to see handicap games between computers. Some programs, such
as Mogo,
dominate the field. Some are quite bad. Is the difference one or two stones,
or is it
nine or 27 stones? The handicap which gives something close to 50-50 ratio
would give
a useful idea. This would also
to be fair, most KR code will compile on modern
compilers, if you ask nicely.
s.
- Original Message
From: Don Dailey [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Tuesday, October 23, 2007 8:42:15 AM
Subject: Re: [computer-go] XML alternatives to SGF
There is a
in figure 6 of this paper, black has developed (but hasn't
yet used) the mother of all walls. it's pretty funny.
s.
- Original Message
From: terry mcintyre [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Monday, October 15, 2007 4:17:47 PM
Subject: Re:
that just kills me every time i see the expression on yasuhiro's (?)
face. losing the 5 stones is one thing, losing the second eye is
brutal.
s.
- Original Message
From: Tapani Raiko [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Friday, October 12, 2007 10:36:01
Hi Steve,
So this doesn't get too lengthy I'll remove the stuff I'm not responding
to.
no problem.
But why would it suddenly go log at some point nearby? This is the
same superstition people had in computer chess for decades! Everyone
had this gut feeling based on nothing whatsoever.
does nothing.
On 10/12/07, steve uurtamo [EMAIL PROTECTED] wrote:
Hi Steve,
So this doesn't get too lengthy I'll remove the stuff I'm not responding
to.
no problem.
But why would it suddenly go log at some point nearby? This is the
same superstition people had in computer chess
i think that it's an accurate statement.
it certainly hasn't already played such a role, and there is
no evidence that it will or can.
s.
- Original Message
From: Chris Fant [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Wednesday, October 10, 2007 9:15:18 PM
I think that there's an apples/oranges thing going on here.
My hunch, however, is that they won't play a
significant role in creating a machine that can top the best human
players in the 19-by-19 game.
i agree with this statement.
And MC programs are more scalable that traditional programs.
As Don wrote, the
main problem of null move is the depth reduction. It hides long-term
threats that the evaluation function might not be able to evaluate.
even with a very good evaluation function, i would think that another problem
(this is likely just restating what you and others have
I wouldn't put it as strongly, but I also noticed that MC and UCT and suclike
techniques were not mentioned at all.
to be fair to the article, in fact they were. you just have to click on all of
the
links in the article to see it.
s.
For others, like me, who missed the link, it is here:
http://www.spectrum.ieee.org/oct07/5552/monte
But this is just talking about monte carlo; no mention of UCT, which (as
Don said earlier in this thread) is the best (global) search algorithm
we have right now, and it would be dangerous
I'm glad that you found it. seems like winRate
would end up as 0 most of the time and thus
you'd make nearly random moves?
s.
Shape Yahoo! in your own image. Join our Network Research Panel today!
-tailed p-value for
rejecting the null hypothesis that the bots are the same strength is
left as an exercise for the reader ;)
On Sat, 2007-09-29 at 07:20 -0700, steve uurtamo wrote:
Strangely enough, it now appears that hb-amaf-1k-v2 is significantly
stronger than genAnchor-1k, defeating it 9 out
Are you getting the same number of playouts as
everyone else?
s.
- Original Message
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thursday, September 27, 2007 9:33:14 AM
Subject: Re: [Housebot-developers] [computer-go] ReadyFreddy on CGOS
I've
Yeah. An eye point is defined as an empty point where all four
neighbors are the same chain. This prevents weak combos of false eyes,
but does allow it to miss one kind of life.
corner life is worth quite a few points, generally, and doesn't need to satisfy
these conditions. in fact, it
? This sounds like a really very very bad idea. But I may have
misunderstood.
Nah, you understood correctly.
ouch. it seems like you're forcing your eyes to be on the 2nd line
or above and all living groups to have stones on the 3rd
line or above.
right?
s.
There are some subtle distinctions to make
when thinking about slack moves, though. Some
strong moves simply solidify a connection enough
to make a large region of the board come under
more influence to be used later. This is really
difficult to measure, because these moves often
can serve
uh, never mind. i should have looked a little more
closely at the situation. :)
s.
- Original Message
From: [EMAIL PROTECTED] [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Friday, August 10, 2007 8:34:26 AM
Subject: [computer-go] EGC2007
I organized side event
(no limit hold 'em example)
if no. of hands can be taken to be # of distinct 2 card hands, mod
suit isomorphism for the first action, and no. of hands is taken to
be # of distinct 3 card hands given the first two cards for the second
action, etc., then it's easy to see that the vast bulk of the
Both.
Its probably not so difficult to make a simple bot. But it is also not
difficult to make a simple UCT player. But I am sure, that reaching the
level of Polaris is more difficult than writing the best Go-programm. I have
the feeling, that Polaris is a very serious project. Its
There is certainly more money to be made in poker than in go.
Yes, but its also more difficult.
do you mean this in a casual, unsubstantiated way, or in an exact way?
s.
Moody friends. Drama
This is a remarkable result. I think poker is more difficult than Go and of
course chess.
for people, or computers?
poker is a much smaller game than go.
s.
Fussy? Opinionated? Impossible to
hey, this sounds pretty good to me.
s.
- Original Message
From: Jason House [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Monday, July 23, 2007 9:53:26 PM
Subject: [computer-go] [Fwd: Re: Casual attendance of the US Go Congress]
Here is an old e-mail I've found
my guess is that you are in fact missing something --
it seems unlikely that they enumerated _on disk_ all
possible games and their correct response moves.
anything taking up less space than that would require
something more intelligent (or at least with a better
capacity to collapse situations)
PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thursday, July 19, 2007 1:17:59 PM
Subject: Re: [computer-go] Draughts / Checkers solved
On 7/19/07, Chris Fant [EMAIL PROTECTED] wrote:
On 7/19/07, steve uurtamo [EMAIL PROTECTED] wrote:
my guess is that you are in fact missing something
it's much more likely not to matter on
a real (19x19) board.
s.
--- chrilly [EMAIL PROTECTED] wrote:
New lesson learned. It depends on the rule set if
something is correct or a
blunder.
So far the Go-masters told me, it does not matter,
its practically the same.
Obviously its not. This
i'd suggest that you need to consider whether what you really mean
is a position chosen from the uniform distribution of all legal go positions,
or if you mean a position from somewhere near the middle game. (i.e. would
you be comfortable with a board with 4 stones on it as one of these uniformly
How is this a ko threat? Lazarus threatens a chain of 4 or 5 stones
with a self-atari move. If the opponent captures, where is the ko?
If the opponent doesn't capture, where is the ko?
sorry, this is just terminology on my part -- a 'ko threat' is any threat
that can be used during a ko,
There is one other issue I have seen that is similar. Sometimes
Lazarus will play a move that doesn't hurt nor help it's position.
It's not a wasted move because the opponent must respond or else lose.
this sounds a good bit like a ko threat, which is tricky to distinguish
from a good play.
s.
as far as killing moves are concerned, there's a fairly well-understood
set of circumstances for groups with a large blob eyespace under which
death is guaranteed, life is guaranteed if a ko is won, or death is guaranteed
if a ko is lost. i have no idea how to weight the last two, but given that
The attack is easily
refuted with a capture, and when that happens no time was lost. But
the opponent must capture immediately or the threat Lazarus made
actually works.
this, in fact, is a ko threat. if you play it *outside* of a ko, then it's a
wasted ko threat. no big loss if there are
We felt also, that even if it works, the improvement
measured in Elos would not be very spectacular. The Elo/Effort ratio is low.
I was simply too lazy (or too professional) to give it a try.
it might be fun (even from a non-FPGA point of view) to try it just
to see where it lies versus a
the language of mathematics is perhaps the most universal language for
computer scientists. pseudocode comes in somewhere after that, and well-known
algorithms probably somewhere inbetween. game programming is an application
of computer science, and the language of game programming isn't
The right parameters for Fischer time is whatever allows the highest
quality of games in the shortest actual game time and of course these
values can only be estimated or guessed at.I have estimated (perhaps
incorrectly but based on many comments from the group and for other
reasons too)
Don, I like you very much, but when you say that byo-yomi
is unfriendly to humans, I have to say that you clearly haven't
played enough go. Byo-yomi is incredibly friendly to humans.
If you don't like it, try canadian timing, which is also very
friendly to humans.
Please, for the love of god,
how about canadian time?
X moves in Y minutes, where X and Y reset every time
you play X moves. you can choose where to spend your
time, and if things get tight, you only have to survive and
not do anything stupid for X-(current # of moves) and then
you get all of your time back. you can use up
That still has the undesirable characteristic that you can use much less
time than your opponent but still lose on time.
not to be too obtuse, but why is this an undesirable characteristic?
s.
Got
i think that maybe you misunderstand how byo yomi is used in practice.
you have a giant pile of time that should be enough to account for basically
all of the hardest parts of the game.
then you have several (more than 1 !) byo-yomi periods, which are like
grace periods on top of what would
Managing your own time whether in chunks or as a whole _is_ a
sub-game/task either way.
true, and a good point. time management other than attempting
to equally divide remaining time among the expected number of
remaining moves (which itself isn't so easy to estimate) is
complicated.
s.
only for the first move or three, really.
s.
- Original Message
From: terry mcintyre [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Monday, June 18, 2007 1:09:31 PM
Subject: Re: [computer-go] Opening
Is it possible to recognize and exploit symmetry to improve the
on 9x9 it's easier to see it converge. 19x19 is a beast,
which is why i think that scanning a small slice of the board
for the first two moves might not be such a bad idea.
s.
Fussy? Opinionated?
i haven't found that i've received any additonal spam as a result of
being a member of (or of posting to) this list.
knock on wood.
s.
- Original Message
From: the Robot Vegetable [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Sunday, June 17, 2007 10:16:44 PM
Subject:
-0700, steve uurtamo wrote:
my last $0.02 on this -- let me know when you've written
a kernel in java, and tell me how fast your operating system
(written entirely in java) runs.
what? that can't be done? :)
Well, in fact that can be done... :-)
http://www.jnode.org/
Hellwig
Also I've found:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=all
Strict 1/2 C++ speed.
not to mention 10x the memory usage of C.
s.
We won't tell. Get more on shows you hate to
Also I've found:
http://shootout.alioth.debian.org/gp4/benchmark.php?test=alllang=all
Strict 1/2 C++ speed.
more surprising to me, i suppose, is that C is apparently more expressive --
the size of the code is smaller for the C implementations than for java ones.
that's just pure comedy to
hey, you guys are right, java really is as fast as C now.
s.
- Original Message
From: terry mcintyre [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Friday, June 15, 2007 1:17:11 PM
Subject: Re: [computer-go] Java hounds salivate over this:
The Vega chip is
not a java advocate, but I thought the whole java speed war ended
when JIT came out? Granted there is some overhead during the initial
start, but once it's running it would be the same speed since, in
essence it IS running native code at that point.
-Josh
On 6/15/07, steve uurtamo [EMAIL PROTECTED
byo-yomi is important for go, or at the very least,
canadian time standards.
s.
- Original Message
From: Jeff Nowakowski [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; computer-go computer-go@computer-go.org
Sent: Sunday, June 10, 2007 10:42:50 PM
Subject: Re: [computer-go] Congratulations
1. In Japanese rules when you have no ko threats you pass, then the
opponent connects. In Chinese rules you'd play a dame, and if none you'd
fill in a point of your own territory.
This is creating a 1pt difference in final score. In at least one game
I have it makes the difference in who
i'd need to write a C interface for it, then try to maintain compatibility
through new releases. (AKA i'd effectively end up rewriting it). it might
seem like less of a burden for me to just write my code in C++, but
i guess i'm just a caveman who is stuck in his old ways and would rather
unprune isn't a word in english (yet), so it might be more natural to
use widening.
you can un a lot of things, but pruning is generally a somewhat
irreversible action.
s.
- Original Message
From: Brian Slesinsky [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent:
some tree heuristics good, some tree heuristics bad.
s.
- Original Message
From: Peter Drake [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Thursday, May 24, 2007 12:53:03 PM
Subject: Re: [computer-go] Progressive unpruning in Mango 19x19
This interesting
No, humans are much weaker on 9x9 than on 19x19.
With all due respect, that's absurd. If that were true, then all
we would have to do is move to smaller boards if 19x19 were not
challenging enough.
You've almost gotten it right. In fact, 9x9 go is used to teach people
the rules of the
.. then of course there were lisp machines
(brain short circuits as sparks fly and magic smoke is released.)
s.
TV dinner still cooling?
Check out Tonight's Picks on Yahoo! TV.
http://tv.yahoo.com/
I like to think that MoGo deliberately beats such people by
half a point, so as to annoy them more :-)
this isn't uncommon in teaching games -- the idea (i think) is to
give the student opportunities to make good moves, providing them
with opportunities to learn through good play, rather than
I know a particularly nasty leak in garbage collection was fixed, but not
all code triggered it. If it was triggered you'd run out of memory,
that's not what you like to hear,
s.
Don't get soaked.
interestingly, this is the premise upon which i
wrote my genetic board evaluator. for what it's
worth, writing good go programs using a specialized
'go instruction set' isn't any easier or more
intuitive than using, say, 80386 instructions. it
just makes certain operations take less 'instruction
try() and expect() to suffer()
or install() signal_handlers() everywhere().
s.
- Original Message
From: Markus Enzenberger [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Saturday, March 3, 2007 12:39:28 PM
Subject: Re: [computer-go] GTPv3
On Saturday 03 March
101 - 200 of 256 matches
Mail list logo