Looks like you're making good progress. Apart from the time gained training,
you'll probably get a similar speed up when using the DNN during play? I'm
curious when you'll see improvement in play outweigh the extra computational
cost.
Mark
> On Apr 26, 2016, at 9:55 PM, David Fotland wrote:
>
Somehow reading this list has fallen off my radar...
I looked at the Numenta stuff some years ago. Jeff Hawkins' book "On
Intelligence" is an inspiring read and has some really good insights. So when
he started Numenta I had considerable expectations. However, what I thought
were the most inter
2010/1/19 terry mcintyre :
( I recall a pro making
> such an observation; I was willing to accept his expertise on the matter. )
Any pro making such a comment at move 10 is just grand-standing. I
have experienced pros making such comments too. You can let such a
remark pass out of politeness of c
The relative values look about right. But I remember getting much
higher numbers. Did you run the Java versions with or without the
-server parameter?
Mark
On Mon, Dec 14, 2009 at 11:00 PM, Brian Slesinsky wrote:
> Okay, I added a few more timings (playouts / second, very rough):
>
> Plug-and-Go
I took AMAF as the process to consider all the moves regardless when
they were played in the sequence (although a slight discount for later
in the sequence seems to help a little) whereas RAVE is using an
undefined method to favour some nodes over others prior to expanding
them. The reason (as far
This was discussed a little while back. I'd like to tinker with some
ideas but I have at most a few hours available at a time. I do have
some spare computing power. If there was an XCode project that
contains everything needed to run Fuego within the IDE I think I'd be
tempted to do some experiment
> I've found that AMAF gives very little boost with light playouts,
> you really need something fairly meaningful already to get any kind
> of real boost. To have at least 10% chance of beating GNUGo with
> reasonable time per game (to be able to play-test your bot), I think
> you can't avoid doing
ient program automatically connects your engine to 9x9 CGOS. If
nothing changed in CGOS over the past year that is.
Let me know if that works for you.
Mark
On Sun, Dec 13, 2009 at 7:28 PM, Brian Slesinsky wrote:
> That's why I decided to say something :-)
>
> 2009/12/13 Mark Boon :
&
On Dec 13, 2009, at 3:31 PM, Brian Slesinsky wrote:
> I probably won't have time to look at it much, but it would be good to
> have another Java refbot to compare against. I did look at Plug-and-Go
> but the install seems a bit tricky since I don't use Eclipse or
> Spring. Ideally, each engine sh
On Dec 13, 2009, at 8:08 AM, Denis fidaali wrote:
>
> So it would certainly be usefull, if people could agree on a reference monte
> carlo tree bot (and provide some reference implementations in popular
> langages).
> It would obviously be based on the reference light-bot.
This is what I att
On Tue, Dec 8, 2009 at 8:37 PM, David Fotland wrote:
> I use two values. I never even occurred to me to use three.
>
I use one, it never occurred to me to use two :)
At the time I'd never heard of Zobrist, but I used to use a single
value for each point to look up Joseki. By using white-value =
Well, I suppose this is a lesson that every computer-Go programmer
learns one day or another: always have a way to accept any move, no
matter whether your bot thinks it's legal or not.
I don't see how this is an indictment, the rules are what they are.
For every player. It's not as if this was a l
On Nov 19, 2009, at 1:24 AM, Nick Wedd wrote:
So a bot which appears on KGS, gets rated as 25k, plays hundreds of
games, and then improves to 15k, is going to do a lot of damage to
the rating system.
What happens when all those beginners that start at 25k improve, many
of them well beyon
2009/10/29 terry mcintyre :
> That sounds to me like "a dumb human with a smart algorithm can beat a fast
> computer with a dumb algorithm" -- which speaks more to Penrose's reluctance
> to improve algorithms in his dumbed-down computer models than it does to any
> quantum-physical effects.
>
> Sti
Roger Penrose thinks the human brain can do things a Turing machine
cannot. (Note: I don't say 'computer'.) He claims it's due to some
quantum-physical effects used by the brain. I doubt his ideas are
correct, but he did have a few interesting chess-positions to support
his theory. Typicall
On Oct 27, 2009, at 7:41 PM, Hideki Kato wrote:
IMHO, Jeff's idea is still very interesting while
the implementation by the staff in Numenta have been going to not
right direction.
That was also my opinion. What I thought was strange is that Numenta's
implementation doesn't have feed-back
On Oct 27, 2009, at 3:39 AM, Hideki Kato wrote:
I strongly believe that such patterns must not be only spatial
(static) but also temporal, ie, dynamic or sequence of pattens which
allow the player quickly remember the results of local fights or
L&D.
I think that's exactly right. At least for
2009/10/26 Don Dailey :
> Yes, you understood me right. I disagree with Olivier on this one. To
> me it is self-evident that humans are more scalable than computers because
> we have better heuristics. When that is not true it is usually because the
> task is trivial, not because it is hard.
2009/10/26 Don Dailey :
>
>
> 2009/10/26 Richard J. Lorentz
>
> Yes, this group does not have a consensus at all on this. On the one hand
> we hear that MCTS has reached a dead end and there is no benefit from extra
> CPU power, and on the other hand we have these developers hustling around
> f
2009/10/24 Dave Dyer :
> At 10:12 AM 10/24/2009, Joshua Shriver wrote:
>
> Came across this today, and since this is also an AI oriented list thought
> some of you might enjoy it too.
>
> http://www.techradar.com/news/world-of-tech/future-tech/the-past-present-and-future-of-ai-643838
>
> I won't be
On Oct 19, 2009, at 7:04 PM, Petri Pitkanen wrote:
Not really a compuetr Go issue, but I do not think that great wall
is superior even when completed. It is not too bad but it needs a
definite strategy from wall owner. I.e building side moyos using
wall as a roof and hoping that the other
On Wed, Oct 14, 2009 at 9:53 PM, Stefan Kaitschick
wrote:
> Very Cool. The mysterious part was "more interesting than programming go".
> That seemed almost impossible.
>
> Stefan
>
By the way, if anyone is curious you can sign up for a beta version
here: http://www.bluemarsonline.com/
Beta is th
On Sat, Oct 10, 2009 at 5:32 PM, Álvaro Begué wrote:
> Are you not going to tell us what this new job is about?
>
I almost forgot to answer this, I had no intention to sound
mysterious. My job is to make autonomous avatars (also called NPCs or
'bots') for a new MMO platform called Blue Mars. The
Also not Remi, but...
Numenta is a startup funded by Palm founder Jeff Hawkins. He started
it following up on his book 'On Intelligence', which I think is a very
interesting read. I'd suggest it as a reading to anyone considering
applying some form of Neural simulation to Go or any other problem.
Someone commented on it, so it must have come across OK.
Is it possible that your e-mail provider or e-mail reader decided to
not include the attachment? At least that's what 'skipped content'
seems to indicate.
If I need to repost or publish it in another way I'd be happy to do so.
Mark
On Tu
On Sat, Sep 26, 2009 at 6:11 AM, Brian Sheppard wrote:
> In my dream, I went on to overcome these difficulties and solve the problem.
> But when I woke up I couldn't remember how I did it...
That's too bad. I get almost all my good ideas in my sleep. I think
because the brain is more relaxed and
On Mon, Sep 14, 2009 at 10:55 AM, Stefan Kaitschick
wrote:
> Stone-Age - spooky concept :-)
> I suppose it has some relationship to generally lighter playouts deeper in
> the tree.
> Have you experimented some more with this?
No, I didn't have time to explore this further.
> Perhaps the cutoff p
Maybe from a different angle, but maybe you remember me writing about
'stone-age'. Basically what it did was assuming strings created during
the playout are less critical than existing strings. I used this to
limit my tactical search by a great deal by not doing any search on
'new' strings. This di
Thank you Christian, for taking the time to write an extensive reply.
I still don't understand how you come to conclude that the CPU, at 94K
playouts with two cores, is twice as fast as the GPU doing 170K
playouts per second. Sounds like the reverse to me. Or you meant to
say "more than half the s
I'm trying to understand your conclusion. The GPU is more than 3 times
faster than the CPU, yet you don't think it's worth it. You also say
the card has only 9% occupancy.
I know next to nothing about GPU programming, so take my questions in
that stride.
>>Optimal speed was at 80 threads per bloc
Just being curious I decided to give it a swing to see if Fuego would
compile on a Mac. The configure scripts stops saying 'boost' is not
installed. So I downloaded the latest version of that (it's huge!) and
set a BOOST_ROOT environment variable, but it still says it can't find
it.
Anyon
On Sep 6, 2009, at 4:20 AM, Don Dailey wrote:
I tried both llvm-gcc and CLANG. I did not have any trouble
getting them to work for my 64 bit chess program.
I didn't try too hard, but neither is producing executables as fast
as gcc. llvm-gcc is the slowest about 20% slower than gcc and
On Sep 5, 2009, at 4:41 AM, terry mcintyre wrote:
Found an interesting article on Snow Leopard at Ars Technica ... 20-
some pages.
http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars
Of interest to Computer Go programmers: the addition of blocks to C,
which allow closures and ot
2009/9/1 Peter Drake :
> On Sep 1, 2009, at 8:11 AM, David Fotland wrote:
>
> I don’t think any of the strong programs use pseudoliberties.
>
> Interesting! Can those involved with other strong programs verify this?
> My board code is descended from my Java re-implementation of libEGO. I tried
> wr
2009/8/25 René van de Veerdonk :
> Nonetheless, bitmap-go as a topic keeps resurfacing on this
> mailing list every once in a while and nobody ever put solid data and a
> reference implementation behind it. That is what I wanted to accomplish with
> my mockup.
I think this is interesting informati
On Tue, Aug 18, 2009 at 10:24 AM, Brian Sheppard wrote:
> What do you do in your program?
Not using the mercy-rule.
I believe you can gain 10%-20% performance on 9x9 using a mercy-rule.
But in its most simple form I don't see how it can be used reliably. I
don't know if the gain in performance o
On Aug 15, 2009, at 8:52 AM, wrote:
You will just have to jump in and read some code or write
your own to fully understand. I recommend reading the
gnugo source, which is pretty darn good.
But that's exactly the kind of work you'd want to avoid if there's no
reasonable grounds for believi
On Aug 15, 2009, at 6:24 AM, Heikki Levanto wrote:
You can also use board-sized bitmaps. Merging is a trivial OR
operation.
I've seen bit-maps mentioned many times, but is there any evidence
it's faster than a 'traditional' implementation?
Mark
_
2009/8/12 Don Dailey :
>
> If the program makes decisions about the best way to win N points, there
> is no guarantee that this is ALSO the best way to win N+1 points.
Although this is obviously true, that doesn't automatically mean it's
not the best approach. Because there's a hidden assumption
2009/8/12 Don Dailey :
>
> I disagree about this being what humans do. They do not set a fake komi
> and then try to win only by that much.
I didn't say that humans do that. I said they consider their chance
50-50. For an MC program to consider its chances to be 50-50 you'd
have to up the komi.
I started to write something on this subject a while ago but it got
caught up in other things I had to do.
When humans play a (high) handicap game, they don't estimate a high
winning percentage for the weaker player. They'll consider it to be
more or less 50-50. So to adjust the komi at the beginn
When using patterns during the playout I had improvised some code to
select patterns randomly, but favour those with higher weights more or
less proportionally to the weight..
I was wondering though if there's an established algorithm for
something like this. To be a little more precise, if I have
There are many ways to skin a cat. I allocate them dynamically, but
recycle the nodes no longer needed for performance. And I use 'aspect
programming' that optionally (after a recompile) checks for dangling
pointers.
Mark
On Jul 14, 2009, at 5:06 AM, Carter Cheng wrote:
This is somethin
On Mon, Jul 13, 2009 at 7:54 AM, David Doshay wrote:
> My personal opinion is that way too much effort is put into optimizations
> that used to be very important when memory was small, but now is nice but
> not really needed. My bias is that efficiency is a good thing as long as it
> does not get i
I have thought about this kind of thing a bit, but it's hard to
formulate a general solution. What happens is when you prohibit
certain 'bad' moves is that you slant the result in favour of the side
with more 'bad' moves. This gets to be a problem in situations where
there are few moves to
On Fri, Jul 3, 2009 at 7:28 PM, Ray Tayek wrote:
> please join us for an afternoon of surf, sand, and go.
>
> saturday, august 22'nd 2009, from 11 a.m. to 6 p.m or so, at 26918 malibu
> cove colony drive
Sounds good. If the earth wasn't curved maybe we could wave at each other :)
_
You always need to be extremely careful about these kind of
heuristics. Especially in MC programs they can be detrimental very
easily.
But I believe you can come up with a reasonable rule to prevent some
self-atari's. I have one which is something along the following lines:
- puts itself into ata
On Wed, Jun 17, 2009 at 9:17 AM, David Fotland wrote:
> Many Faces uses position value collection. Positions are hashed and looked
> up in the position table (with a hash invariant to rotations and
> reflections). Each node has information about the position (wins, losses,
> strongest players at
On Mon, Jun 15, 2009 at 4:02 PM, Brian Sheppard wrote:
>
> One thing I would *really* like to know is how to make something
> 10 times quicker using only 90 man hours. :-)
>
In my experience, the first ten times faster takes about the same time
extra as programming the original idea. It's the next
2009/6/10 David Fotland :
> I think we will get another 64x to 256 x density then it will stop, for
> single chips. We should eventually get desktop machines with thousands of
> cores, but probably never with millions of cores. There really are limits
> built into physics L
>
How about the cores
I did this, stopping search if other moves mathematically couldn't
catch up. I found that the savings in percentage of total nodes
depended on how many playouts the program did. The larger the number
of playouts, the larger the savings. I also made a rule where after a
certain percentage of the tot
I've also tried a variety of ways to use point-ownership in
combination with RAVE. By no means was it an exhaustive study, but I
failed to find an intuitive way to improve play this way.
I didn't try enough to be able to come to hard conclusions, but at the
very least it didn't turn out to be obvi
On Wed, May 27, 2009 at 7:33 PM, David Fotland wrote:
> GPL is not infectious through looking at source code, but I didn't want any
> appearance of wrongdoing. And I was put off a little by Stallman's
> rhetoric.
>
> David
>
I have mostly stayed away from GPL projects for the same reasons.
Inste
I'm a bit late reading this thread and the discussion seems to have
veered from the original topic a bit.
As to the CPU vs. memory discussion, it's not so clear-cut to me that
CPU speeds are improving faster than memory. Twenty years ago you had
CPUs in the 4-8Mhz range and around 1Mb of memory. T
last move
gains little for me, as it is covered in the first case. (I.e. the
ladder heuristic will escape a stone in atari by capturing the last
move.)
David Fotland said he has a low probability on capture, but I don't
think he ever gave specific numbers.
Mark
2009/4/27 Łukasz Lew :
&
On Sun, Apr 26, 2009 at 11:54 PM, Łukasz Lew wrote:
> Hi,
>
> Have any one of you tried uct + capture heuristic?
> Is it stronger? How much?
>
>From memory I'd say it was winning about 80% against plain UCT. But
only capture if it can escape (which means it can make three
liberties.)
Mark
__
On Mon, Apr 6, 2009 at 10:54 AM, Isaac Deutsch wrote:
This leads us to the question if groups in average have
> <=10 or >10 liberties... :)
Without actually having done any tests or measurements, I'd guess it's
much less than 10. More like 4.
Mark
___
On Thu, Apr 2, 2009 at 5:14 AM, wrote:
> Isaac,
>
> I implemented about 6 way to track liberties,
> a couple years ago, and measured the running
> performance, and by far the best is also the
> simplest: keep an array of liberties for each
> chain, and do a simple linear search.
>
> This may seem
I can confirm, with a bit of optimization, counting real liberties is
only marginally slower than counting pseudo-liberties. So there's
really no benefit that I can see from using pseudo liberties.
Mark
On Wed, Apr 1, 2009 at 8:49 AM, Álvaro Begué wrote:
> When John Tromp and I were thinking ab
2009/3/23 Yamato :
> Sorry for responding to the old topic.
>
> Mark Boon wrote:
>>Other than that, I'd take a different approach:
>>
>>- play out as usual. Instead of counting stones + eyes on the board,
>>you count eyes + prisoners + nr-opponent's pa
On Feb 24, 2009, at 4:40 AM, Daniel Burgos wrote:
I worked on this some time ago. I did not use neural networks but
patterns with feedback.
The problem with feedback is that it is difficult to know when it
reaches its final state. Usually you get oscillations and that state
never happens
On Tue, Feb 17, 2009 at 8:35 PM, George Dahl wrote:
> Really? You think that doing 20-50 uniform random playouts and
> estimating the win probability, when used as a leaf node evaluator in
> tree search, will outperform anything else that uses same amount of
> time?
You'll probably find a variet
Just curious, did you ever read 'On Intelligence' by Jeff Hawkins?
After reading that I got rather sold on the idea that if you're ever
going to attempt making a program with neural nets that behaves
intelligently then it needs to have a lot of feed-back links. Not just
the standard feed-fo
I don't know if that's what you're already looking at, but recently
Apple announced their new version of OS X called 'Snow Leopard' which
supposedly focuses mostly on improvements in the use of multiple
processing. And that includes the GPU. The module that binds it all
together is called '
On Sun, Feb 8, 2009 at 3:02 PM, Isaac Deutsch wrote:
> Hi,
>
> Can you explain what minimumNrNodes and nrSimulations do? In my program I
> play 50k games regardless of the number of nodes, so I would like to adjust
> this accordingly.
>
minimumNrNodes is the number of games played out. Originally
I had a little spare time to look at it. It seems indeed I forgot to
update the GoEngineGTP.jar file last time I made some changes. This
was easy to fix even from here and I think it should work now.
Just as a note, if you want to change the number of playouts to 50K,
you need to change the
; [/Users/ibd/Desktop/computer go/Rango/CGOS/TesujiRefBot.xml]: Instantiation
> of bean failed; nested exception is java.lang.NoClassDefFoundError:
> tesuji/games/general/MoveIterator
>
>
> Original-Nachricht
>> Datum: Sat, 7 Feb 2009 09:30:53 -0200
>> V
You can get everything here:
http://plug-and-go.dev.java.net
The MCTS program description is under 'Derived Projects'.
You don't really need the source-code. You can just get the 'binaries
& scripts' and then copy the files 'TesujiRefBot.jar' and
'TesujiRefBot.xml' to the directory where you put
I'm currently tied up but you can get my MCTS implementation, which
includes RAVE, and set it up to play 50K playouts. It's only a matter
of setting the right number in the configuration file.
You can also use it to play through two-gtp, that way you can test an
awful lot faster.
Mark
On Fri, F
I think as long as you don't count passes during exploration (or game-
play) but only count passes during playout as points for the opponent,
I don't see why you would need any adjustment.
As to unsettled groups, that's what the second phase is for. Playout
acts as the second phase in this c
On Feb 3, 2009, at 2:34 PM, Heikki Levanto wrote:
All in all, I think this is a messy and unreliable solution to a
problem I
have not seen happening.
For what it is worth I vote against client-side time controls.
Maybe you haven't seen it. That doesn't mean it doesn't exist.
I've lost gam
On Feb 2, 2009, at 2:19 PM, Rémi Coulom wrote:
Mark Boon wrote:
I think I've seen people post about playing with Japanese rules in
relation to MC programs. Correct me if I'm wrong, but I think I saw
people do some adjustment in that case. Does that mean they
actually use Chine
I think I've seen people post about playing with Japanese rules in
relation to MC programs. Correct me if I'm wrong, but I think I saw
people do some adjustment in that case. Does that mean they actually
use Chinese scoring internally?
Mark
___
c
On Feb 2, 2009, at 9:57 AM, Isaac Deutsch wrote:
They are not pattern based playouts, but as I said uniformly random.
I reckon the effect of RAVE is less with these?
My MCTS implementation sees a gain of 200-400 ELO from RAVE using
uniformly random moves. 400 gain (90% win-rate) for 2K play
I haven't gotten very far yet in incorporating many of the suggestions
published on this mailing-list into the MCTS ref-bot. As such I feel I
still have a lot of catching up to do when it comes to MC programs,
mostly due to lack of time.
But I had an idea I wanted to share as I haven't seen
On Feb 1, 2009, at 11:29 AM, Erik van der Werf wrote:
Something else for the discussion. I would like to have a rule about
mandatory displaying the thinking process of the program so that both
operators have an idea of what is happening. Especially for remote
play I think this is needed becaus
On Jan 21, 2009, at 11:53 AM, Olivier Teytaud wrote:
Here, we have a non-zero initialization of the number of wins, of
the numbere of simulations, of the number of Rave-wins, of the
number of Rave-losses.
We have then a 0 constant for exploration, but also an exploratory
term which is very
On Jan 21, 2009, at 10:23 AM, Magnus Persson wrote:
Quoting Thomas Lavergne :
- the best play is a good only if played immediatly and very bad if
played later in the game :
- the first playout for this play resulted in a lost.
score and RAVE score will be very low and this play will neve
On Jan 18, 2009, at 5:38 PM, Magnus Persson wrote:
In Valkyria I solved this by playing out the ladder on the playout
board, and store all changes on a stack. When the ladder undos moves
it just pop changes from the stack. In this way I can also use the
rich board representation of Valkyri
On Jan 18, 2009, at 4:11 PM, David Fotland wrote:
I think it is too expensive to read ladders during playouts. I
remember
that you have faster ladders search code so it might not cost you as
much.
My playout code has no ability to undo a move or do any kind of
lookahead.
Yes, my ladder
On Jan 17, 2009, at 5:41 PM, Sylvain Gelly wrote:
For the first difference you mention, as far as I remember it makes
a small but significant difference and is one of the main reason I
was talking about "tricky details".
OK, I ran a test and after 1,000 games with 2K semi-light playouts I
Thanks for taking the time Sylvain. I took a quick look to see how
your pseudo-code compared to the reference implementation I made.
There are a few small differences, and I think the place(s) where I
deviated is exactly what confused Daniel Waeber.
The first difference is that when I check
On Jan 15, 2009, at 12:33 PM, Daniel Waeber wrote:
yes, but the weight/color maps stay the same for all updated nodes.
I think the first playoutNode (the one most deep inside the tree) only
should get amaf values for the random playout, the next one form
random
playout + from the first play
On Jan 15, 2009, at 10:47 AM, Daniel Waeber wrote:
Thanks you. I think that I understand it now :)
On 23:21 Wed 14 Jan , Mark Boon wrote:
You have to understand that the 'start' variable really starts at the
root from the position for which we do the search. So all the moves
&
On Jan 14, 2009, at 10:55 PM, Daniel Waeber wrote:
Accessing the AMAF values depends on your implementation. The
following is a code-snippet from my MCTS reference implementation
that
updates the AMAF values in the tree:
if (_useAMAF)
{
IntStack playoutMoves = _searchAdministratio
On Jan 14, 2009, at 8:39 PM, David Doshay wrote:
Saving energy is a fine thing. Lets leave that to various hardware
engineers in the semiconductor industry. Or, if you think this is
such a grand idea then you should offer up the prize money and
then we can all see who comes to compete for it.
On Jan 14, 2009, at 3:40 PM, Don Dailey wrote:
However, the best thing to do is to ignore that page and go the "Bayes
Rated" link which is updated every day. This is the total
performance
rating over all time of any player on CGOS. Everything is rated
together, even if you have only play
On Jan 14, 2009, at 2:15 PM, Rémi Coulom wrote:
Mark Boon wrote:
I'm not so knowledgeable about the ELO system and had a few
questions about how it's used by the CGOS server.
Firstly, on the CGOS server page there's an explanation of how it
works with a table of e
I'm not so knowledgeable about the ELO system and had a few questions
about how it's used by the CGOS server.
Firstly, on the CGOS server page there's an explanation of how it
works with a table of expected winning percentages vs. difference in
ELO ratings:
http://cgos.boardspace.net/ (t
On Jan 14, 2009, at 12:43 PM, Thomas Lavergne wrote:
Couting xiangqi and shogi players as chess players is a bit unfair...
Sorry if I caused confusion, I didn't mean to count those as Chess-
players. I just stated that to show that despite large population-
numbers in say China, most of tho
It's difficult to get hard data about this. Go is only the most
popular game in Korea. In other countries like Japan and China it
comes second by far to a local chess variation.
Possibly Chess is more ingrained in Western culture than Go is in
Asia, I don't know really. But Chess has the po
On Jan 14, 2009, at 9:36 AM, Daniel Waeber wrote:
I have a question about the the part were the stats are updated.
(l.15-25). having an array of amaf-values in every node seems very
memory
intensive and I don't get how you would access these values.
You are right, it is memory intensive. I
On Jan 10, 2009, at 8:16 AM, Gian-Carlo Pascutto wrote:
Dave Dyer wrote:
I think general hardware limits are good, because they will permit
more teams to be competitive without altering the nature of the
competition.
So in effect, it's an admission that the strength of some teams should
be
The attached game played on CGOS was awarded a win for white due to an
illegal move. Black tried to play J3, which according to the game-
record is a ko. Nothing could be further from the truth...
Rather shocking really. What happened here?
Mark
684276.sgf
Description: Binary data
__
On Wed, Dec 17, 2008 at 6:39 PM, Michael Goetze wrote:
> this is actually a rather complicated topic because you can have different
> definitions for "professional strength". For instance, I could make an
> argument that S. Shikshina 3p does not have "professional strength", AFAIK
> she did not be
On Tue, Dec 16, 2008 at 8:52 PM, Michael Goetze wrote:
> I wish people would stop spreading such incorrect information. The
> correlation between professional ranks and playing strength is quite bad,
> and EGF 7dans are not, generally speaking, professional strength.
I'm not claiming to be an aut
- Show quoted text -
On Tue, Dec 16, 2008 at 11:35 PM, Weston Markham
wrote:
> On Wed, Dec 17, 2008 at 1:32 AM, Mark Boon wrote:
>> By the way, what does scratch100k.sh look like?
>
> ../gogui-1.1.3/bin/gogui-twogtp -auto -black "java -jar jrefgo.jar 10"
&g
By the way, what does scratch100k.sh look like?
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
On Tue, Dec 16, 2008 at 12:20 PM, Jason House
wrote:
> When thinking about the apparent strength loss, I came up with a potential
> theory: consistency. With more simulations, noise has less of an impact. I'm
> going to guess that the known bias of AMAF leads to blunder that is played
> more consi
Weston,
Although those result sound intriguing, it also looks like a
convoluted experiment. I wouldn't call gnu-go an expert judge,
although it is an impartial one. The fact that it says that the 5K
ref-bot is ahead after 10 moves 46% of the time alone makes it suspect
in my eyes. But it is curiou
1 - 100 of 301 matches
Mail list logo
