[gnugo-devel] [sr #105877] non-conforming to GTP in gtp_final_status_list()

Update of sr #105877 (project gnugo): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #2: It's a bit of a conf

[gnugo-devel] [sr #105877] non-conforming to GTP in gtp_final_status_list()

Follow-up Comment #4, sr #105877 (project gnugo): I'm fairly certain I did not propose to change anything. I was only trying to explain a misunderstanding. ___ Reply to this item at: _

Re: [gnugo-devel] gnugo download

Louis Gutenschwager wrote: I am trying to download the latest 3.7.11 files I am getting a file not found error when I go to download the tar.gz file. Can you please send me the link for the file or if you would like I could host the files for you. The reason why you can't find any 3.7.11 file

Re: [gnugo-devel] gnugo download

Dan wrote: It's been ages since we made a tarball. Maybe we should either make 3.8 or 3.7.11. But it will be Getting a 3.7.11 out certainly wouldn't hurt. hard for me to do much until January since I'm on sabbatical in Oregon until then. An issue is that our configure.in is based on obsolete

Re: [gnugo-devel] gnugo download

Joseph Piche wrote: I vote for a 3.8 release: GNU Go 3.6, released November 17, 2004 I agree. Last I recall, there weren't many bugs open in 3.7.10. Maybe a release canidate for 3.8 instead? If someone wants to help with a simple but slightly tedious task, go through the archive for this lis

Re: [gnugo-devel] Making GNU Go take advantage of multiple processors.

Dmitry Denisenko wrote: I'm a graduate student taking a course in parallel computer architecture and programming and I'm looking for a program to parallelize. I noticed that making GNU Go thread-safe is on your wish list. Have there been previous attempts at making it parallel? Not quite, but

Re: [gnugo-devel] on the road to 3.8

Joseph Piche wrote: With regard to bug #175, I have to agree that G5 on move 52 is awkward, and that a more appropriate move would be B8 or F1. However, after viewing output with -t -t, it looks like gnugo is choosing G5 to increase territory, even though Chinese rules are being used. Gnugo shoul

Re: [gnugo-devel] Re: on the road to 3.8

Joseph Piche wrote: With regard to bug #120, I believe resigning is the correct move for gnugo, but I think more skilled players should confirm this. When you run gnugo with -t you see the output: I pass. ... though, genmove() thinks the position is hopeless You win by resignation. This probabl

Re: [gnugo-devel] GPL 3

Dan wrote: I posted a patch at: http://match.stanford.edu/gnugo/gpl3 This updates the GPL to version 3. The biggest changes are to COPYING and doc/copying.texi. There are no changes apart from this version conversion. I have not added it to the CVS, but I assume it's a good patch if we are agr

Re: [gnugo-devel] GPL 3

Dan wrote: I haven't been active on GNU Go for a long time, but I thought that I'd just chime in and give Dan a thumbs up. I like GPL 3 very much and think we should move up to it. It's GPL 3 now in the CVS. If I understand Gunnar's last email we may be almost ready to put up GNU Go 3.7.11.

Re: [gnugo-devel] gnugo.ps and .pdf

Dan wrote: We currently seem to have some trouble building gnugo.ps and gnugo.pdf. This is on a machine where the texi2dvi and texi2pdf --version yields (GNU Texinfo 4.7) 1.3, and on another with (GNU Texinfo 4.2) 0.51. For example gnugo.log contains: 184] [185] (./gtp-commands.texi ./gtp-comm

Re: [gnugo-devel] doc patch

Dan wrote: I've posted a patch at: http://match.stanford.edu/gnugo/doc_3_7_11 This patch addresses the problem that building doc/gtp-commands.texi may require GNU sed; with BSD sed, this command was found to fail. After this patch, doc/gtp-commands.texi is not built automatically but can be reb

[gnugo-devel] Building GNU Go on Windows

Has anybody tried to build GNU Go 3.7.11 on Windows? Does it work? Whether it does or not the fact remains that the MSVC project files are a maintenance nightmare. As soon as we add a new source file or a pattern database file the project files are immediately out of date and we can only hope tha

Re: [gnugo-devel] Building GNU Go on Windows

Ben Lambrechts wrote: I have build 3.7.11 for windows with mingw and cygwin You can find the build at http://lithops.sourceforge.net/gnugo.htm Right, this way the normal configure script is run in cygwin. That's certainly a valid solution. But let me restate my question. Has anybody managed

Re: [gnugo-devel] Building GNU Go on Windows

Dan wrote: Gunnar wrote: I have also posted an updated cmake configuration patch at http://trac.gnugo.org/gnugo/attachment/ticket/191/cmake_7_12.1b.diff which fixes some problems but also replaces the HAVE_VISUAL_C symbol with actual configure tests to check existence of specific header files.

Re: [gnugo-devel] Bug 152

Joseph Piche wrote: Even though it is a trivial bug, I made a patch for bug 152. It is located at: http://trac.gnugo.org/gnugo/attachment/ticket/152/remove-ncurses.patch Notice that this patch removes support for using ncurses to provide color capabilities (for colored debug displays) and lea

Re: [gnugo-devel] Building GNU Go on Windows

Ben Lambrechts wrote: I have tried to build it with "Visual C++ Express 2005" and "Visual C++ Express 2008 bèta 2" but that didn't work. I don't have a version of Visual C++ 6 so I can't test that one. Is there any chance you could try whether the cmake build proposed in http://trac.gnugo.org/

Re: [gnugo-devel] speeding up the engine

Joseph Piche wrote: I had an idea for speading up move generation, but this would probably only work in certain situations. When genmove gives a list of top moves, store that list and the current board position until the next genmove so that after checking the difference in the board--if the opp

[gnugo-devel] Revise TODO?

As mentioned in a previous message I'm not content with the state of our TODO list and I think it's in a rather bad need of revision. I'll start by stating my opinions on the current items. Please comment. * If you can, send us bug FIXES as well as bug reports. If you see some bad behavior,

Re: [gnugo-devel] Revise TODO?

alain Baeckeroot wrote: Maybe add somewhere a section "Known weakness" or "Simplifications" with short comment if needed (in the trac wiki or in Doc...): - intransitivity in connection - group A is connected (cannot be cut) to B - B is connected to C GNU Go _assumes_ tha

Re: [gnugo-devel] Revise TODO?

Ben Lambrechts wrote: * Fuseki tuning by hand is difficult. People who are interested in doing machine learning experiments with GNU Go could try working with fuseki. This may be one of the areas with most potential for substantial and reasonably quick improvements. Very interestin

Re: [gnugo-devel] Revise TODO?

Ben Lambrechts wrote: * Fuseki tuning by hand is difficult. People who are interested in doing machine learning experiments with GNU Go could try working with fuseki. This may be one of the areas with most potential for substantial and reasonably quick improvements. Very interestin

Re: [gnugo-devel] Bug 152

Joseph Piche wrote: Notice that this patch removes support for using ncurses to provide color capabilities (for colored debug displays) and leaves that to using ANSI color escape codes. It would be nice to get rid of a dependency but I'm afraid the use of ncurses was introduced for a reason. Ca

Re: [gnugo-devel] Revise TODO?

Ben Lambrechts wrote: I don't want to hack in the code, but if I can create a new fuseki- database, I am willing to help. I don't think a new full-board database would be of much value at this time. As described in my other mail, smaller scale patterns have much more potential. However, I bel

Re: [gnugo-devel] interesting problem

Terry McIntyre wrote: I found a problem which gnugo 3.7.11 fails to solve; it requires setting up a cute little snapback. Both the problem and the solution are attached. I tried both --decide-semeai d1/g3 prob5.sgf -o result.sgf and --decide-dragon d1 prob5.sgf -o result.sgf Any ideas on how

Re: [gnugo-devel] Building GNU Go on Windows

I wrote: I have prepared a patch which adds cmake configuration files at http://trac.gnugo.org/gnugo/ticket/191 They are written by a cmake beginner (me) but suffice for building on GNU/Linux and hopefully can be used on Windows. Please see the ticket for instructions on how to build with cmak

Re: [gnugo-devel] Building GNU Go on Windows

Ben Lambrechts wrote: I tried with Visual C++ 2005 Express and Visual Studio 2008 beta 2 With both I get the message: The project file '___\gnugo-3.7.11-cmake\patterns\uncompress_fuseki.dsp' has been corrupted and cannot be opened. When I place the 'uncompress_fuseki.dsp' provided by Olav Mülle

[gnugo-devel] Configure options

Reviewing the configure options I'd like to make some changes. | /* Connection module. Default standard. */ | #define ALTERNATE_CONNECTIONS 1 This toggles between two connection reading modules, where one is effectively abandoned. I don't see any value in exposing this to the users and propose d

Re: [gnugo-devel] regressions and bugs

Emanuele wrote: Hi people. First, thanks to everybody for this nice project. It's many years I use GNU Go and I will be happy to contribute a little. I know C language but my last acivity as professional programmer is dated 12 years ago, so I cant give much help in writing code now (not in a s

Re: [gnugo-devel] Pattern VA49

Emanuele Cisbani wrote: I'm discovering how to "debugging" at patterns-level. $ gnugo.exe --trace -l cisba01.sgf 2>&1 | tail -n 13 Top moves: 1. H5 2.44 2. J10 2.25 3. A1 0.71 4. P5 0.19 5. Q5 0.19 6. F9 0.10 7. N7 0.10 Checking safety of a white move at H5 Move generation likes H5 with

[gnugo-devel] First Monte Carlo code ready for inclusion

I've posted a new patch at http://trac.gnugo.org/gnugo/ticket/150 which contains a first version of my Monte Carlo code which should be in good enough shape to be added to CVS. It doesn't represent the full strength of the MonteGNU account on CGOS 9x9 but should at least suffice for a 2000 ratin

Re: [gnugo-devel] First Monte Carlo code ready for inclusion

I wrote: I've posted a new patch at http://trac.gnugo.org/gnugo/ticket/150 which contains a first version of my Monte Carlo code which should be in good enough shape to be added to CVS. It doesn't represent the full strength of the MonteGNU account on CGOS 9x9 but should at least suffice for a

Re: [gnugo-devel] regressions and bugs

[Moving back to the list.] Emanuele Cisbani wrote: > Working on STS_RV, first semeai, first problem: > > Class 0 semiai. > White outside libs= 2 > Black outside libs= 3 > Shared libs=0 > Black wins unconditionally. > Black to play pass. > White has two ko threads in either A12, B12, C12. > Value

Re: [gnugo-devel] regressions and bugs

Emanuele Cisbani wrote: > 2007/12/5, Gunnar Farnebäck <[EMAIL PROTECTED]>: > [...] >> In this case which is already settled PASS is an allowed >> answer but also other moves which bring black further ahead in the >> semeai are accepted. > [...] > > If blac

Re: [gnugo-devel] regressions and bugs

Emanuele Cisbani wrote: > 2007/12/6, Gunnar Farnebäck <[EMAIL PROTECTED]>: > [...] >> I'm not sure how best to handle this test, possibly change it to >> tactical reading tests, but for now you can leave it and make a note >> about the problem. > > Ok, s

Re: [gnugo-devel] Adapt semeai test suite STS-RV for GNU Go.

Emanuele Cisbani wrote: > Work has begun. > > I posted the first set of 26 tests "ported" to GNU Go, > and the problem suite folder to put in games directory. > > http://trac.gnugo.org/gnugo/ticket/41 > > Summary: 17/26 passes. 0 unexpected passes, 9 unexpected failures > > Only one failure is a m

Re: [gnugo-devel] First Monte Carlo code ready for inclusion

Ben Lambrechts wrote: >>> I've posted a new patch at http://trac.gnugo.org/gnugo/ticket/150 which >>> contains a first version of my Monte Carlo code which should be in >>> good enough shape to be added to CVS. It doesn't represent the full >>> strength >>> of the MonteGNU account on CGOS 9x9 but

Re: [gnugo-devel] First Monte Carlo code ready for inclusion

Ben Lambrechts wrote: > >> What command line options are you using, more exactly? > > tcl.exe cgos3.tcl GnuCvs-1-MC * "gnugoMC.exe --mode gtp --cache-size > 512 --chinese-rules --level 1 --capture-all-dead --monte-carlo" > tcl.exe cgos3.tcl GnuCvs-10-MC * "gnugoMC.exe --mode gtp > --cache-

Re: [gnugo-devel] minor bug on owl.c

Emanuele Cisbani wrote: > The GTP command causing the abend is: > analyze_semeai B3 C4 > > It's not correct, ok, but we can expect a less tragic reply then this: > > ***assertion failure: > owl.c:503 - board[apos] == OTHER_COLOR(board[bpos]) near B3*** > > >A B C D E F G H J K L M N O P Q R S

Re: [gnugo-devel] First Monte Carlo code ready for inclusion

Ben Lambrechts wrote: > So the correct commands are: (after I rebuild gnugo with modified board.h) > > tcl.exe cgos3.tcl GnuCvs-1-MC * "gnugoMC.exe --mode gtp --cache-size > 512 --chinese-rules _--max-level 1_ --capture-all-dead > _--positional-superko_ --monte-carlo _--mc-games-per-level TO

Re: [gnugo-devel] Adapt semeai test suite STS-RV for GNU Go.

I wrote: > Actually it's quite easy to disable amalgamation over four-liberty > strings altogether, see the appended patch. It does solve this semeai > mistake as well as testcases semeai:48 and semeai:147. Probably it > does bad things elsewhere though. Amazingly enough it doesn't seem to. Regre

Re: [gnugo-devel] Adapt semeai test suite STS-RV for GNU Go.

Emanuele Cisbani wrote: Task is completed. General summary: 565 passes 157 fails 722 total I added the STS2GNUGo.txt file with some explanation of method and comments. Great work! It will take some time to look through all of this but there's no question it will be of great help for improvin

Re: [gnugo-devel] First Monte Carlo code ready for inclusion

Ben Lambrechts wrote: > This are my conclusions after running several bots on CGOS: > >* 1000 games per level > o L1 :: 1698 > o L10 :: 1813 >* 8000 games per level > o L1 :: 1777 > o L10 :: 1938 >* 10.000 games per level > o L1 :: 1736 >

[gnugo-devel] Semeai reading

With the help of STS-RV it's easier to see where GNU Go goes wrong in semeai reading. The analysis below is based on STS-RV_1.tst, which mostly features semeai problems where both colors have one big eye each. What varies is the shape and size of the big eyes, the number of common liberties, and t

Re: [gnugo-devel] Semeai reading

I wrote: > 1. Tactical reading mistake of a three liberty string causes an >overamalgamation which the semeai reading can't recover from. >STS-RV_1:23 > >9 O O O . . . >8 X X O . . . >7 . X O O . . >6 X X X O . . >5 . . X O . . >4 O O O X X . >3 . O . X . X >

Re: [gnugo-devel] blunder:36 fails

Terry McIntyre wrote: > I just checked out the CVS and compiled it, using > > cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/gnugo co gnugo > > Would this include the latest modifications, Gunnar? Yes. > In any case, I ran regress.pike, and got an unexpected failure: > > [EMAIL PROTECTED]:~/gnugo

Re: [gnugo-devel] view.pike failure?

Terry McIntyre wrote: > I tried running view.pike on a ubuntu 7.10 system, and got failures > related to a GTP module. GTK, not GTP. > [EMAIL PROTECTED]:~/gnugo/regression$ uname -a > Linux terry-quad 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 > i686 GNU/Linux > [EMAIL PROTECTED]:~/gn

Re: [gnugo-devel] for communication on Computer Go

谢帆 wrote: Hi, I'm a member of Computer Go Institute of Bupt in China. Gnu Go is a very good program in our field, and we always regarded it as preferred opponent.(now our program have been as strong as gnugo 3.7) We learned many things from GnuGo,but some core idea of your talented gnugo is still

Re: [gnugo-devel] Pattern for seki (bug 175)

Joseph Piche wrote: > I created a regression test for bug 175 (the patch is in trac). Then I > started looking at the pattern code after reading the documentation. It > was difficult for me to try and understand how to generate a pattern, The pattern code is rather complex due to various speed op

Re: [gnugo-devel] Pattern for seki (bug 175)

Joseph Piche wrote: > I believe the semeai and owl code breaks down pretty bad with this > pattern. It's obvious the best move for black is B2, but when white > responds with C1, gnugo gives up. The response W-C2 B-C1 W-B3 B-A3 is > found with default options. But when you turn the level up, W-C1

Re: [gnugo-devel] Pattern for seki (bug 175)

I wrote: > Joseph Piche wrote: > > I believe the semeai and owl code breaks down pretty bad with this > > pattern. It's obvious the best move for black is B2, but when white > > responds with C1, gnugo gives up. The response W-C2 B-C1 W-B3 B-A3 is > > found with default options. But when you t

Re: [gnugo-devel] fyi

Erik van der Werf wrote: ***assertion failure: board.c:2727 - ON_BOARD1(pos) near PASS*** B:A9 A B C D E F G H J 9 X O O . O . . . . 9 8 X O X O . O . . . 8 7 . X X X O . O . . 7 6 X . X X O O X . . 6 5 O X . . X X O O . 5 4 O X . . X . X O . 4 3 O X X X . . X O O 3 2 . . . . X X . X

Re: [gnugo-devel] can i help?

Teo Swee Ann wrote: > Hi, I would like to offer my help to GNUGO. I have been thinking of > writing a Go-bot for some time and did write a bad one, based on a score > estimator. I am an amateur programmer, who is very proficient with C++. > I have done language developments for computer aided desi

[gnugo-devel] Tunable Monte Carlo patterns

Here's an Easter surprise. I have added a patch to CVS which makes big changes to the Monte Carlo code. First it adds incremental updates of local 3x3 neighborhood, suicide status, self-atari status, and number of stones captured, for each move. Second it makes the random playout move generation

Re: [gnugo-devel] Bugreport

Joseph Piché wrote: Hi GNU Folks. My Computer say's to me i should eMail you this Bug, this is the terminal Output: --- NEWGAME from peer ***assertion failure: board.c:942 - pos == PASS_MOVE || board[pos] == EMPTY near E8***

[gnugo-devel] Experimental git repository

I have made an experimental mirror of the CVS repository to a git repository, which can be cloned with git clone git://trac.gnugo.org/gnugo.git The bandwidth is limited so the initial cloning may take some minutes. Some instructions on using git can be found at https://savannah.gnu.org/maintena

Re: [gnugo-devel] Experimental git repository

Łukasz Lew wrote: > Have you considered Mercurial? They say it is simpler. > Lukasz From what I've read the relative advantages of Mercurial and git are mostly up to taste and/or religion. But that's not a factor here. As a GNU project, GNU Go is primarily hosted at savannah.gnu.org and they have

Re: [gnugo-devel] exe file

Franck Bouquerel (Wanadoo) wrote: > Hello, > > I've seen an update of gnu-go (3.7.12) > > Is there any possibility to also download directly an exe file (Windows) ? Not from us. We only distribute the source code. /Gunnar ___ gnugo-devel mailing li

Re: [gnugo-devel] Experimental git repository

I wrote: > I have made an experimental mirror of the CVS repository to a git > repository, which can be cloned with > > git clone git://trac.gnugo.org/gnugo.git > > The bandwidth is limited so the initial cloning may take some minutes. > > Some instructions on using git can be found at > https://s

Re: [gnugo-devel] unaccurate evaluation

thierry banel wrote: > Hi Gnu Go team. > > Attached is an sgf game I've just played. > The game is over (no more stone to add). > GnuGo makes a (very) wrong evaluation. > > The command line is: > gnugo --quiet --never-resign --score finish --level 20 buggy-eval.sgf > (--level does not matter) > >

Re: [gnugo-devel] tournament at US Go Congress - SlugGo needs permission

[EMAIL PROTECTED] wrote: >> There will be a computer Go tournament at the US Go Congress in >> Portland Oregon. I hope that at least one GNU Go primary author will >> be at the Congress and will enter GNU Go in the tournament. > > Unfortunately I can't go since I'll be in Scotland for > a workshop

Re: [gnugo-devel] FW: Computer Olympiad

Winands M (MICC) wrote: Dear GNU Go developers, As you probably know there is again a Computer Olympiad (http://www.grappa.univ-lille3.fr/icga/event.php?id=37) There is again a Go tournament for 9*9 and 19*19. For both tournaments we are planning to have a swiss tournament and both tourna

Re: [gnugo-devel] Bug

Erik van der Werf wrote: Cyclic point redistribution detected. ***assertion failure: move_reasons.c:1389 - 0 near C3*** Thanks for the report. This problem has now been fixed in the source repository. See http://trac.gnugo.org/gnugo/ticket/208 for details. Thanks also to Rémi for a report

[gnugo-devel] clear_cache mystery

Apply the patch at http://trac.gnugo.org/gnugo/attachment/ticket/199/gunnar_7_12.9.diff which is no more complex than this: --- a/engine/owl.c +++ b/engine/owl.c @@ -1027,7 +1027,10 @@ do_owl_analyze_semeai(int apos, int bpos, if (board[pos] == EMPTY && !mw[pos]) { if (liberty_of_

Re: [gnugo-devel] About the Gnugo API

Jorge Timón wrote: > Hello, is the first time i suscribe to a mailing list, so if i do > something wrong just tell me. I'm spanish so sorry about my poor english. It all looks fine. > I'm not really interested in developing gnu go but it can be usefull for > me. I'm working in a genetics algorit

Re: [gnugo-devel] Re: About the Gnugo API

Jorge Timón wrote: > Hello everyone. > I'm reading the GTP commands and this what i need. I'm reading some > example scripts but i don't know perl or python. Can anyone send me i > little exmple in shell script (or php) about how to run gnugo in gtp > mode and how to send (and receive the answers)

Re: [gnugo-devel] Using pipes for the GTP mode

Jorge Timón wrote: > I readed some old mails in the mailing list. Now i know what i need is > pipes. I found some examples > (http://lists.gnu.org/archive/html/gnugo-devel/2005-03/msg00052.html)(http://svn.gna.org/viewcvs/quarry/trunk/src/gtp/). > I think that's too complex for me: i just need

Re: [gnugo-devel] Gnu Go Ladder Challenge

Dan wrote: On the Computer Go Ladder (9x9) I got behind Gnu Go and would like to challenge it with Jacqueline Go. We could meet on KGS or if you like and have a Intel Mac, you could play it out yourself by downloading Jacqueline Go. What do you like and when do you have time? Who will play

Re: [gnugo-devel] Trouble importing "gnugo.h"

Biggles Bristol wrote: > Ok, that makes a lot of sense. Just did some more research, however, and > it seems that you can't use exec() on the iPhone, so running two > processes legitimately isn't an option in this case : ( > > Am working through the errors, getting there slowly but surely. One >

Re: [gnugo-devel] Patches for 3.8

Daniel Bump wrote: >> The following patch allows me to compile on OSX. This is not a correct >> fix, since patterns/Makefile.in is an autogenerated file (by automake). > > The following patch seems to be OK. At least after this > I can build on both OS/X and Ubuntu. > > http://sporadic.stanford.ed

Re: [gnugo-devel] Doc revision

Dan wrote: >> The Macintosh installation info is real skimpy; I'll see if I can put >> something together this weekend. Will the OS X-specific patch be part >> of the 3.8 release? > > Gunnar had some criticisms of it, but this has to be fixed. > > I think it will go in if noone figures out a bette

Re: [gnugo-devel] Patches for 3.8

Ben Lambrechts wrote: > On Tue, Dec 16, 2008 at 7:49 PM, Daniel Bump > wrote: > > > Is anyone interested in updating the .dsp and .dsw > files for Microsoft VC? The existing files may be > found in gnugo-3.7.12.tar.gz. > > > > Just delete these files

Re: [gnugo-devel] Patches for 3.8

Daniel Bump wrote: > Ben Lambrechts wrote: > >> Just delete these files >> They aren't necesary since Gnu GO supports the CMake build suistem. > > As I understand it, CMake produces .dsp files. Since 3.8 will > be a stable release might it not be helpful to distribute these? > I would not propose

Re: [gnugo-devel] Doc revision

Dan wrote: > Gunnar wrote: > >> automatically. That's why extract_fuseki has duplicate libraries >> listed in LD_ADD. Presumably the same trick should work for >> mkmcpat. Try to add another copy of libengine.a at the end of the >> mkmcpat_LDADD line instead of adding globals.c as a source file. I

Re: [gnugo-devel] Patches for 3.8

Daniel Bump wrote: >> The important question is whether the CMake build actually does work >> with Visual Studio. Has anyone tested that? There are instructions >> under item (E) of the WINDOWS file. > > The fact that they were (oops) not actually in the 3.7.12 tarball (discovered > yesterday) ma

Re: [gnugo-devel] GNU Go Trac

Ben Lambrechts wrote: > The GNU Go track site don't send the verification token to verify my > e-mail adress. That's probably because no outgoing mail has been configured for trac at all. /Gunnar ___ gnugo-devel mailing list gnugo-devel@gnu.org http:

Re: [gnugo-devel] Some warnings with Intel C++

Ben Lambrechts wrote: > Hi, > > When compiling GNU Go 3.8 with Intel C++ 11 I get following warnings > between several 100 warnings about deprecated functions. Thanks for the report. > File > > Line > > > src\engine\board.c > > 689 > > warning #279: controlling expression is con

Re: [gnugo-devel] using MPI for gnugo.

Daniel Bump wrote: >> The question is: >> Is it planned to use distributed parallel computing for building world-wide >> AI to beat strongest human player? > > An immediate problem is that the GNU Go codebase is > not well adapted to parallel processing. SlugGo is > an experiment in using GNU Go

Re: [gnugo-devel] using MPI for gnugo.

Terry McIntyre wrote: > To restore competitiveness, it might be time to refactor GnuGo, as > David Fotland refactored Many Faces of Go. > > Conditions are very different now. RAM is cheap. Typical desktop > computers have quadcore processors. Six- and eight-core processors > will become typical in

Re: [gnugo-devel] using MPI for gnugo.

Petri Pitkanen wrote: > This would not be trivial. > > MFG uses MFG knowledge to make MCTS smarter. I do doubt that this is > simple. I think it took him about six months. In collaborated effort > this could easily take quite bit longer. Also since details of how > are not known it would mean tha

Re: [gnugo-devel] using MPI for gnugo.

Darren Cook wrote: >> code. The only thing that matters in the short term for making GNU Go >> stronger is to catch up with the Monte Carlo development, especially >> make the Monte Carlo code scale better to larger boards. Key ideas to >> look into there are RAVE (rapid action value estimation),

Re: [gnugo-devel] using MPI for gnugo.

Daniel Bump wrote: >> There's no particular need to do anything drastic with the existing >> code. The only thing that matters in the short term for making GNU Go >> stronger is to catch up with the Monte Carlo development, especially >> make the Monte Carlo code scale better to larger boards. Key

Re: [gnugo-devel] segfault - "--decide-dragon xx -a -t" with certain board positions

Winsor C wrote: > Seems like some boards position causes GNU Go 3.80 to go segfault with > "--decide-dragon xx -a -t" options. > For example, save the following as "a.sgf" > > -begin of a.sgf- > (;FF[4]CA[UTF-8] > KM[6.5] > ;B[pd];W[dd];B[ip];W[pp];B[np];W[dp];B[pn];W[qi];B[qq];W[oo] > ;B[

Re: [gnugo-devel] about one feature

shuda...@sina.com wrote: > Hello, Go developers: > > Is there such a feature supported in GnuGo that when playing > gmp(human vs. program) the user can first load a .sgf file in and then > start from that point( instead of start from the right beginning)? Starting GNU Go with "gnugo -l game

Re: [gnugo-devel] I would like to help.

Mark Andrew Gerads wrote: > I would like to help with GNUGo, but have little Idea where to start. I > would like a bit of guidance if possible > > [...] David Levesque wrote: > Hi, > > My name is David, I am currently finishing my second year in > software engineering in Montreal, Canada. I am st

Re: [gnugo-devel] Scoring problem with GnuGo engine

Charles Ellis wrote: Hi -- I'm running GnoGo through a PandaNet interface and have encountered a scoring glitch with 9x9 practice games. Essentially, the program doesn't recognize a surrounded area unless it's literally surrounded, or see stones as captured that aren't actually removed. Can yo

Re: [gnugo-devel] bug report

Liu Zheng wrote: > I use gnugo 3.8 to practice dead-live problem as attachment file, > gnugo plays as white. > The command line is: gnugo --mode gtp --capture-all-dead > --chinese-rules --monte-carlo --level 100 It should first be noted that level 100 is very much untested and would be ex

Re: [gnugo-devel] bug report

I wrote: > Looking back at move 2, --monte-carlo can help but only if the position > is considered as non-final, which it only was due to the > owl_node_limit bug for level > 45. Here it makes sense to check the > semeai reading for the lower left corner. > > ...[semeai reading mistake which can b

[gnugo-devel] Unconditional safety search

In the testcase endgame:1010, the position is this: A B C D E F G H J 9 . . . . . . . . . 9 8 . O O O O O O . . 8 7 . X O X X X O O . 7 6 . X X . . X X O O 6 5 . . . . + . . X X 5 4 . . . . . . X X X 4 3 . . + X X X X O O 3 2 . . . X O O O O . 2 1 . . . X O . . . . 1 A B C D E F G

Re: [gnugo-devel] OWL tuning: blocking escape with a knight's move

Martin Holters wrote: > I arend2:10, after two steps of reading (b G3 w F4), the situation looks > like this: > > 6|...O > 5|..O.X... > 4|...X.O.. > 3|..OX.OX. > 2|..OOXX.. > 1| > +---. > ABCDEFGH > > Here, gnugo misses the nice move at H5, capturing the two white stones, > reje

Re: [gnugo-devel] OWL tuning: blocking escape with a knight's move

Martin Holters wrote: >> > However, it breaks strategy5:225 and ninestones:40. In the latter, >> > the semeai reading looks bogus with and without the patch and I have >> > not really figured out why the patch results in preferring D2 over >> > C3. >> >> I agree about ninestones:40. D2 is extr

[gnugo-devel] Recent semeai advances

Over the last weeks many changes to the semeai reading have entered the repository, specifically aimed at improving the results of the STS-RV_* test suites. There were also a number of semeai changes made before 3.8 that didn't make it into 3.8 As you can see from the following statistics, there

Re: [gnugo-devel] An Inquiry about how to modify GUN Go's Replay method .

On 05/12/10 05:17, Amr Ahmed Sabry Abdel Rahman Ghoneim wrote: Good Day … I’m a Post-Graduate Student at the University of New South Wales –Australia. I’m using GNU Go in my research and I need to make a modification to its code. But since the GNU Go is life-size and has been developed over a lo

Re: [gnugo-devel] Assertion failure from gnugo 3.8

On 09/14/10 20:32, Matthew Woodcraft wrote: I just got the assertion failure below from gnugo 3.8. -M- ***assertion failure: influence.c:941 - (color == WHITE&& q->territory_value[pos]>= 0.0) || (color == BLACK&& q->territory_value[pos]<= 0.0) near R10*** [...] Thanks for the report. I c

Re: [gnugo-devel] Re: [PATCH 4/4] Autotools refresh.

On 09/23/10 20:52, Yann Dirson wrote: configure does report results for the compiler's target platform (which autostuff calls "host machine", it reserves "target machine" to talk about the target of a toolchain when we are building one - so the "canadian cross" setup is building on a "build machi

Re: [gnugo-devel] Re: [PATCH 4/4] Autotools refresh.

On 09/25/10 00:15, Yann Dirson wrote: On Fri, Sep 24, 2010 at 07:59:08AM +0200, Yann Dirson wrote: On a sidenode, rumors of full success of the testsuite on gta02 are slightly exagerated: it still has not finished (after nearly 36 hours), and there is finally (at least) this failure: ./regress.

Re: [gnugo-devel] Re: [PATCH 4/4] Autotools refresh.

On 09/25/10 15:40, Yann Dirson wrote: On Sat, Sep 25, 2010 at 12:15:08AM +0200, Yann Dirson wrote: On Fri, Sep 24, 2010 at 07:59:08AM +0200, Yann Dirson wrote: On a sidenode, rumors of full success of the testsuite on gta02 are slightly exagerated: it still has not finished (after nearly 36 hou

Re: [gnugo-devel] Re: [PATCH 4/4] Autotools refresh.

On 09/26/10 15:36, Yann Dirson wrote: On Sat, Sep 25, 2010 at 04:17:24PM +0200, Gunnar Farneb?ck wrote: That is known to happen occasionally due to imperfect persistent caching of reading results but the examples you show below look consistent. Oh right, looks like I misread some of those. Ho

Re: [gnugo-devel] Re: [PATCH 4/4] Autotools refresh.

On 09/26/10 22:53, Yann Dirson wrote: Well, let's get serious and hunt. Looks like -t would help to understand, so I try to get some useful info using it. ./regress.sh . nngs4.tst 480 unexpected FAIL: Correct 'R16', got 'Q17' ./interface/gnugo -t -l regression/games/nngs/evand-gnugo-3.3.17-

Re: [gnugo-devel] Re: [PATCH 4/4] Autotools refresh.

On 09/27/10 00:12, Gunnar Farnebäck wrote: On 09/26/10 22:53, Yann Dirson wrote: I won't have much time to look in more details this week - if you have a precise idea about what to look at that will surely help. Oh, there's no mystery here. The warnings about the fuseki databases

  1   2   3   >