[gnugo-devel] ticket 87, floating point comparison
Hi http://trac.gnugo.org/gnugo/ticket/87 has been closed as a won't fix One thing i can do is a fixing patch, replacing all unreliable floating equality test by safe inequality tests: if (a == b) replaced by epilon=0.01 if (abs(a-b) = epsilon) Should i use gg_abs instead of abs ? My potential 2 cents Alain ___ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
Re: [gnugo-devel] kgs tournament
Hello Le Mercredi 1 Février 2006 11:47, Arend Bayer a écrit : According to the rules by Nick Wedd, only one GNU Go-bot can enter the tournament. What I would suggest to do is that Gunnar can enter an official bot in the formal division, and you can enter your bot in the open division. i registred my bot in open division. I asked if i could enter formal division (if it does not prevent our beloved GNU Go to play) Nick Wedd answered: I have so far received no official entry from GNU Go for the Formal division. If I do receive one, I shall give it priority over twinbot. Otherwise, I am happy to have twinbot play in the Formal division. Happy GNU Going. Alain ___ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
Re: [gnugo-devel] kgs tournament
Le Mercredi 1 Février 2006 11:47, Arend Bayer a écrit : On Sun, 29 Jan 2006, alain Baeckeroot wrote: I would like to play kgs computer tournament with my twinbot. I hope it can play in formal division , but i m not sure i can. It is 99,9% gnugo, with some changes in move generation/evaluation so it changes between 10-30% of all the genmoves. (taking opponenent best move into account) Is this enough to enter formal division ? Do i need an agreement from you ? According to the rules by Nick Wedd, only one GNU Go-bot can enter the tournament. What I would suggest to do is that Gunnar can enter an official bot in the formal division, and you can enter your bot in the open division. Yes that will be nice , my twinbot will play in open division Btw, I would certainly be curious to see the changes you made! In attachement you find the first draft of this patch, against 3.7.4 which corrspond to the twinbot running on kgs. It is a working draft with a lot of comment for _me_ . It is also my first C program, so please be tolerant ;) I'm working on a much cleaner version , better order, less uglyness The only idea is: - examine position - find top10 W - find top10 B add a bonus if top moves are close, and we are in chuban or yose This patch is good if games_status 0.7 or for finding some kind of big moves in chuban. This breaks a lot of regression tests but roughtly seems as good/bad as gnugo. I ll redo regression test with the new version, synced to 3.7.8 soon :) Any comment/correction/explaination/fix is welcome. Alain 2006-0201-1534-twin-patch.tgz Description: application/tgz ___ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
[gnugo-devel] superko violation ?
Hi my bot played this, and wants to plays A6 which lead to exactly the same position as 2 moves before. kgsgtp.2.6.12 says it is ko violation. i tried various gnugo 3.4 3.6 3.7.8 they all want to play A6 Is this a superko ? Alain (;GM[1]FF[4]CA[UTF-8]AP[CGoban:2]ST[2] RU[Chinese]SZ[19]KM[7.50]TM[600]OT[25/600 Canadian] PW[twinbot]PB[GAWIN]WR[13k]BR[14k]DT[2006-02-01]PC[The Kiseido Go Server (KGS) at http://kgs.kiseido.com/]C[twinbot [13k\]: GTP Engine for twinbot (white): GNU Go version 3.7.4-twin ] ;B[pd]CR[pd]BL[596.366] ;W[jj]CR[jj]WL[599.437] ;B[pq]CR[pq]BL[590.89] ;W[qo]CR[qo]WL[598.104] ;B[qp]CR[qp]BL[586.673] ;W[po]CR[po]WL[595.687] ;B[np]CR[np]BL[584.986] ;W[dp]CR[dp]WL[591.832] ;B[pl]CR[pl]BL[580.05] ;W[dd]CR[dd]WL[588.995] ;B[ip]CR[ip]BL[571.269] ;W[nc]CR[nc]WL[585.593] ;B[pf]CR[pf]BL[568.468] ;W[kc]CR[kc]WL[581.738] ;B[cf]CR[cf]BL[554.01] ;W[fc]CR[fc]WL[577.191] ;B[cj]CR[cj]BL[551.693] ;W[gq]CR[gq]WL[573.446] ;B[go]CR[go]BL[440.186] ;W[ep]CR[ep]WL[568.28] ;B[hq]CR[hq]BL[420.706] ;W[gp]CR[gp]WL[562.844] ;B[ho]CR[ho]BL[402.956] ;W[ce]CR[ce]WL[557.078] ;B[df]CR[df]BL[391.648] ;W[pb]CR[pb]WL[552.875] ;B[qc]CR[qc]BL[387.608] ;W[pp]CR[pp]WL[548.651] ;B[qq]CR[qq]BL[381.04] ;W[rp]CR[rp]WL[543.71] ;B[rq]CR[rq]BL[377.629] ;W[cm]CR[cm]WL[539.181] ;B[on]CR[on]BL[368.31] ;W[rn]CR[rn]WL[531.611] ;B[rl]CR[rl]BL[361] ;W[lk]CR[lk]WL[526.104] ;B[me]CR[me]BL[357.413] ;W[lm]CR[lm]WL[520.997] ;B[lo]CR[lo]BL[341.247] ;W[nj]CR[nj]WL[514.238] ;B[pj]CR[pj]BL[331.162] ;W[oh]CR[oh]WL[508.373] ;B[qh]CR[qh]BL[326.372] ;W[ke]CR[ke]WL[502.196] ;B[ld]CR[ld]BL[321.895] ;W[kd]CR[kd]WL[496.116] ;B[nd]CR[nd]BL[318.175] ;W[mc]CR[mc]WL[489.621] ;B[oc]CR[oc]BL[314.993] ;W[nb]CR[nb]WL[483.631] ;B[ob]CR[ob]BL[311.922] ;W[ee]CR[ee]WL[478.397] ;B[dl]CR[dl]BL[301.539] ;W[fg]CR[fg]WL[471.571] ;B[ef]CR[ef]BL[299.404] ;W[ff]CR[ff]WL[465.755] ;B[lg]CR[lg]BL[290.043] ;W[kg]CR[kg]WL[458.008] ;B[lh]CR[lh]BL[285.025] ;W[mh]CR[mh]WL[448.701] ;B[mg]CR[mg]BL[282.239] ;W[gj]CR[gj]WL[441.787] ;B[mi]CR[mi]BL[272.729] ;W[ni]CR[ni]WL[422.147] ;B[mj]CR[mj]BL[260.963] ;W[ch]CR[ch]WL[407.086] ;B[bh]CR[bh]BL[255.194] ;W[eh]CR[eh]WL[393.482] ;B[cg]CR[cg]BL[247.479] ;W[oa]CR[oa]WL[380.344] ;B[qb]CR[qb]BL[233.42] ;W[gr]CR[gr]WL[366.803] ;B[hr]CR[hr]BL[223.172] ;W[bk]CR[bk]WL[359.156] ;B[cl]CR[cl]BL[218.919] ;W[bl]CR[bl]WL[349.635] ;B[bj]CR[bj]BL[212.874] ;W[kk]CR[kk]WL[341.509] ;B[mk]CR[mk]BL[209.289] ;W[hs]CR[hs]WL[328.789] ;B[ir]CR[ir]BL[193.972] ;W[bf]CR[bf]WL[320.968] ;B[bg]CR[bg]BL[186.9] ;W[be]CR[be]WL[311.905] ;B[dm]CR[dm]BL[178.124] ;W[cn]CR[cn]WL[303.808] ;B[dh]CR[dh]BL[167.416] ;W[ei]CR[ei]WL[294.308] ;B[dj]CR[dj]BL[162.969] ;W[dn]CR[dn]WL[287.89] ;B[en]CR[en]BL[160.041] ;W[jm]CR[jm]WL[281.978] ;B[kh]CR[kh]BL[150.712] ;W[jg]CR[jg]WL[272.332] ;B[jh]CR[jh]BL[147.567] ;W[ig]CR[ig]WL[266.334] ;B[ij]CR[ij]BL[124.806] ;W[ii]CR[ii]WL[258.217] ;B[ih]CR[ih]BL[121.65] ;W[ik]CR[ik]WL[245.463] ;B[hi]CR[hi]BL[119.147] ;W[hj]CR[hj]WL[232.832] ;B[hg]CR[hg]BL[115.908] ;W[hf]CR[hf]WL[224.022] ;B[if]CR[if]BL[46.673] ;W[gg]CR[gg]WL[216.489] ;B[hh]CR[hh]BL[36.028] ;W[ie]CR[ie]WL[207.277] ;B[lc]CR[lc]BL[13.874] ;W[lb]CR[lb]WL[199.045] ;B[kb]CR[kb]BL[588.779]OB[24] ;W[jb]CR[jb]WL[184.317] ;B[pc]CR[pc]BL[582.808]OB[23] ;W[gl]CR[gl]WL[176.806] ;B[mm]CR[mm]BL[554.826]OB[22] ;W[is]CR[is]WL[167.753] ;B[js]CR[js]BL[552.198]OB[21] ;W[gs]CR[gs]WL[160.214] ;B[jr]CR[jr]BL[547.489]OB[20] ;W[pa]CR[pa]WL[151.748] ;B[md]CR[md]BL[523.254]OB[19] ;W[na]CR[na]WL[143.523] ;B[qa]CR[qa]BL[510.407]OB[18] ;W[ka]CR[ka]WL[134.231] ;B[cq]CR[cq]BL[395.457]OB[17] ;W[dr]CR[dr]WL[125.994] ;B[bo]CR[bo]BL[378.472]OB[16] ;W[cr]CR[cr]WL[118.751] ;B[bn]CR[bn]BL[371.051]OB[15] ;W[bm]CR[bm]WL[112.278] ;B[cp]CR[cp]BL[344.035]OB[14] ;W[do]CR[do]WL[100.426] ;B[br]CR[br]BL[341.933]OB[13] ;W[bs]CR[bs]WL[95.44] ;B[aq]CR[aq]BL[322.192]OB[12] ;W[an]CR[an]WL[89.879] ;B[bp]CR[bp]BL[312.117]OB[11] ;W[ao]CR[ao]WL[82.835] ;B[fo]CR[fo]BL[291.012]OB[10] ;W[em]CR[em]WL[76.06] ;B[el]CR[el]BL[272.218]OB[9] ;W[fm]CR[fm]WL[69.503] ;B[fl]CR[fl]BL[255.449]OB[8] ;W[gm]CR[gm]WL[61.95] ;B[ej]CR[ej]BL[251.484]OB[7] ;W[ml]CR[ml]WL[53.282] ;B[nl]CR[nl]BL[248.674]OB[6] ;W[mn]CR[mn]WL[45.563] ;B[nm]CR[nm]BL[220.688]OB[5] ;W[ln]CR[ln]WL[39.694] ;B[mo]CR[mo]BL[216.226]OB[4] ;W[lf]CR[lf]WL[35.604] ;B[mf]CR[mf]BL[211.636]OB[3] ;W[ko]CR[ko]WL[29.635] ;B[kp]CR[kp]BL[208.918]OB[2] ;W[jo]CR[jo]WL[24.879] ;B[in]CR[in]BL[203.621]OB[1] ;W[di]CR[di]WL[18.101] ;B[ci]CR[ci]BL[600]OB[25] ;W[jp]CR[jp]WL[12.106] ;B[kq]CR[kq]BL[579.726]OB[24] ;W[ll]CR[ll]WL[4.629] ;B[fp]CR[fp]BL[576.359]OB[23] ;W[fq]CR[fq]WL[597.372]OW[24] ;B[eq]CR[eq]BL[568.177]OB[22] ;W[dq]CR[dq]WL[576.914]OW[23] ;B[jn]CR[jn]BL[550.518]OB[21] ;W[kn]CR[kn]WL[570.906]OW[22] ;B[im]CR[im]BL[546.516]OB[20] ;W[jl]CR[jl]WL[565.824]OW[21] ;B[ji]CR[ji]BL[521.942]OB[19] ;W[fn]CR[fn]WL[560.044]OW[20] ;B[eo]CR[eo]BL[517.082]OB[18] ;W[io]CR[io]WL[554.978]OW[19] ;B[hp]CR[hp]BL[479.825]OB[17] ;W[hn]CR[hn]WL[548.789]OW[18] ;B[ij]CR[ij]BL[455.249]OB[16] ;W[kj]CR[kj]WL[542.2]OW[17]
Re: [gnugo-devel] Default reading cache size / tiny benchmark
Le Lundi 16 Janvier 2006 21:43, Gunnar Farneb�ck a écrit : I don't think there has been any systematic investigations of the effects of cache size after the reading cache was completely reimplemented around 3.5.5. It is possible that a significantly smaller cache than before would be adequate as default. Presumably a large cache is more useful in games which require much reading. You could for example try to replay regression/games/FSF-neurogo.sgf and increase the level to 13 or so, and see whether that behaves differently. i did some runs with different cache size, on this game at level 13 , on the terrible ticket 10 game and on other sample pro games from gobase.org for comparison Probably nothing new for you, or trivial things but here are the results: -M1 seems to give same speed as default -M8 The worst case is at level 13, 10% slower with -M1 , for the ticket 10 game. So default to 8M seems largely enough. my 2 cents :) Alain === gnugo 3.7.7 compiled with gcc-3.2.3 CFLAGS=-O2 -march=athlon-xp (athlon-xp 2200+, =1600 real MHz, 512 kB cache) gcc-4.0.2 seems 5% to 10% _slower_ (google confirm that) === Reference with default params, replay gnugo - 40 min terrible ticket 10 game (opponent _much_ stronger than gnugo) - 22 min regression/games/FSF-neurogo.sgf (opponent weaker, but chaotic) replay one player (games from gobase.org) - 17 min game166 Kato /Takemiya (kato kill huge group) - 15 min Takagawa Kaku / Sakata Eio (huge furikawari) - 7 min game147 Ishida / Takemiya (cool game, nearly understandable) === Reference Neurogo game, level 13 , ordered by decreasing cache size: -- time gnugo --replay white -M128 --level 13 regression/games/FSF-neurogo.sgf Global score: 1905.30 / 5571.52 real68m54.705s user66m46.482s sys 0m4.824s --- time gnugo --replay white -M8 --level 13 regression/games/FSF-neurogo.sgf Global score: 1913.73 / 5579.94 real68m1.381s user66m3.980s sys 0m4.964s --- time gnugo --replay white -M1 --level 13 regression/games/FSF-neurogo.sgf Global score: 1913.46 / 5580.64 real69m29.165s user67m20.877s sys 0m4.588s --- time gnugo --replay white -M0.5 --level 13 regression/games/FSF-neurogo.sgf Global score: 1920.08 / 5579.41 real70m22.111s user68m51.198s sys 0m4.592s --- time gnugo --replay white -M0.1 --level 13 regression/games/FSF-neurogo.sgf Global score: 1943.98 / 5578.18 real80m3.740s user77m18.018s sys 0m6.316s --- time gnugo --replay white -M0.01 --level 13 regression/games/FSF-neurogo.sgf Global score: 1934.58 / 5565.24 real111m24.070s user106m19.267s sys 0m11.113s === Reference ticket 10 terrible game level 13: time gnugo --replay black -M10 --level 13 /Big/GO/new-tests/terrible-18584.0.9handicap.sgf Global score: 2939.84 / 13866.69 real104m55.099s user101m18.448s sys 0m8.637s --- time gnugo --replay black -M1 --level 13 /Big/GO/new-tests/terrible-18584.0.9handicap.sgf Global score: 2956.42 / 13810.38 real113m7.724s user108m27.259s sys 0m8.501s === ___ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
Re: [gnugo-devel] Default reading cache size / Questions
Le Vendredi 13 Janvier 2006 23:58, Gunnar Farneb�ck a écrit : The patch gunnar_7_8.12 in ticket 36 (http://trac.gnugo.org/gnugo/ticket/36) may be somewhat controversial, so I'd like to hear if anyone has objections. Plateform independance seems a very good idea. but i have some questions (i have tons of questions ;-) i tried various sizes for the -M parameter and it seems to have nearly no effect on the speed of the engine while the param is in the range 1 - 512 (little slow down for huge cache) i tried very small size 0.1 , 0.01 and 0.001 there is a significant slowdown for 0.001 (twice slower) but nothing terrible for 0.1 or 0.01 Here is my question : in genmove, at each move during initialisation, there is a call to reset_engine() and it seems that it clears everything , so the cache is only used during one move generation, and does not survive once the move is played. i naively thought that the cache would persist during all the game. Am i correct, or did i miss some important thing ? (i searched in the documentation but did not found this kind of explainations) $time gnugo -M 0.001 --replay white -l /Big/GO/new-tests/c-61.sgf 57s $time gnugo -M 0.01 --replay white -l /Big/GO/new-tests/c-61.sgf 34s $time gnugo -M 100 --replay white -l /Big/GO/new-tests/c-61.sgf 34s Regards Alain ___ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
Re: [gnugo-devel] bug fixed
Le Jeudi 12 Janvier 2006 23:04, Gunnar Farneb�ck a écrit :
The loops are fine, due to this construction:
if (num_dragons MAX_DRAGONS) {
TRACE(Too many dragons!!! Might disregard some semeais.);
num_dragons = MAX_DRAGONS;
}
for (d1 = 0; d1 num_dragons; d1++)
yes
What's not fine is that there's no check that neighbor dragons have
numbers below MAX_DRAGONS.
hmm still it is not very clear for me why B19 dragon is considered involved in
a semeai near T3, when it is really not the case.
I saw the #define MAX_DRAGONS and was instantaneouly sure that it was
implied in the bug
Actually I'm rather sceptical about the approach to truncate the
number of analyzed dragons. I think it makes more sense to entirely
turn off the semeai analysis if there are too many dragons, on the
basis that it would only occur in pathological games where semeai
analysis is not critical for the result. I was going to propose
increasing MAX_DRAGONS first but after looking closer at the two crash
inducing games I changed my mind.
i agree with your analyse, but i dont like exeptions in the code, i prefer a
straightforward engine which handle correctly all the cases.
Because for a newcomer (like me) each exception in the code need a lot of
thinking to be understood, and for coder it must be documented ...
(i ll post a message with a very clear example of this complexity due to
exceptions)
Even in those rare pathological games (2 bug reports in nearly 2 years), GNUgo
behaves well, and is winning.
With the timing-adaptative level we will have no fear to lose on time, because
of obscure semeai search (this semeai are quickly solved by the engine).
So i vote for coding MAX_DRAGONS = MAX_WORMS and against introducing an
exception for 2 pathological cases. (even if gnugo will lose due to that ;-)
Regards
Alain
___
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel
Re: [gnugo-devel] example of confusing complexity ;-)
Hello again This is just an argument for keeping the code as simple as possible, and not introduce exceptions when we can avoid them. Here is one good example of what i call newbie-confusing complexity :-) examine_position is 100 lines function (in engine/genmove.c) * The parameter how_much tells us how much of the work we have to do. * For move generation we have to do it all. For debugging we can * sometimes stop a little earlier. As far as i understand, the normal flow of operation fits in 10 lines, the 90 other lines are here for debugging purpose. But thats 900% overload for my brain ;-) . Instead of reading it in 30 seconds, i spent a lot of time (maybe one hour) to be sure i do not miss something within all the tests. Maybe the debugging code could be #ifdef DEBUG , but thats a big job and another problem... for gnugo 3.10 or 4. ? regards Alain ___ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
Re: [gnugo-devel] bug fixed
Thanks a lot for your very clear explaination.
I was not sure that in C [47][50] points to the same address as [48][0] (in
fortran i know it, but i didnt know if it is a language feature or compiler
one, or something else)
Also i did not think of the consequences on stack space... i have a lot to
learn in GNU go :)
i have tried a lot of small changes and break many things, for understanding
the engine. I m doing some clean-up and will send a weird patch soon, with
regression results (lots of breakages, and probably slower and weaker engine
:o)
Alain
Le Vendredi 13 Janvier 2006 22:04, Gunnar Farneb�ck a écrit :
Alain wrote:
hmm still it is not very clear for me why B19 dragon is considered
involved in a semeai near T3, when it is really not the case.
Consider this code:
for (d1 = 0; d1 num_dragons; d1++)
for (k = 0; k dragon2[d1].neighbors; k++) {
int apos = DRAGON(d1).origin;
int bpos = DRAGON(dragon2[d1].adjacent[k]).origin;
int result_certain;
d2 = dragon[bpos].id;
E.g. when d1=47 there may be a neighbor dragon with id d2=50. If it
turns out to be involved in a semeai, this call
owl_analyze_semeai(apos, bpos,
(semeai_results_first[d1][d2]),
(semeai_results_second[d1][d2]),
(semeai_move[d1][d2]), 1, result_certain);
will index the 2D arrays out of bounds on the second index. The effect
is that [47][50] points to the same address as [48][0]. When the
arrays later are traversed a semeai between dragon 48 and dragon 0
will be found, where the former tends to live in the lower right
corner and the latter in the upper left corner.
i agree with your analyse, but i dont like exeptions in the code, i prefer
a
straightforward engine which handle correctly all the cases.
Because for a newcomer (like me) each exception in the code need a lot of
thinking to be understood, and for coder it must be documented ...
Rest assured that this is one aspect of the code we always take into
account. But there are tradeoffs to make with factors like speed,
memory consumption, robustness, language limitations, portability
issues, and so on.
Even in those rare pathological games (2 bug reports in nearly 2
years),
Not really pathological, although the crashes are and should be rare.
This kind of game is somewhat common against very weak beginners.
There's no way for GNU Go to win by less than 200 points or so,
however, except by crashing.
GNUgo behaves well, and is winning. With the
timing-adaptative level we will have no fear to lose on time,
because of obscure semeai search (this semeai are quickly solved by
the engine).
Time is not much of an issue here at all.
So i vote for coding MAX_DRAGONS = MAX_WORMS and against introducing an
exception for 2 pathological cases. (even if gnugo will lose due to
that ;-)
I wouldn't mind using that except that I'm doubtful about the wisdom
of spending 1 MB of stack space (13*(4/5*19*19)^2) for these arrays or
even the 324 kB they can be reduced to by changing type to signed char
(at the cost of some extra code complexity). In fact I'm fairly sure
that the former is not portable enough and I'd rather avoid the latter
as well. Especially since no more than a tiny fraction of the entries
will ever be used at any one time.
I think the cleanest solution is to special case this situation and
disable the semeai analysis for huge numbers of dragons.
/Gunnar
___
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel
___
gnugo-devel mailing list
gnugo-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/gnugo-devel
Re: [gnugo-devel] bug fixed
Le Mercredi 11 Janvier 2006 23:16, alain Baeckeroot a écrit : In test_owl_attack_move (owl.c : 4942) i have in both cases wrong dr2 int dr2 = DRAGON2(dr).semeai_defense_target; dr2=22 = B19 in _both_ cases !! in both cases, B19 is the first stone/dragon on the board = i suspected loop boundary problem In engine/semeai.c : 47 #define MAX_DRAGONS 100 instead of 50 fixes the problem: we have in one case 51 dragons, and in the other 53 Happyly Alain ___ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
Re: [gnugo-devel] bug introduced in 3.5.5
Le Mardi 10 Janvier 2006 22:11, Gunnar Farneb�ck a écrit : Alain wrote: i had alook after this bug: it appears with gnugo-3.5.5 at level 2 or less no pb at level 3 or higher Moreover it does also appear for current CVS at level 2 or lower. i m slowly investigating ...(this is great fun :) hope this help Did you get any further? It seems to me that it may be the same problem as in http://trac.gnugo.org/gnugo/ticket/61. /Gunnar a first clue :-) in both cases the backstrace of the stack in gdb is the same do_genmove collect_move_reasons owl_reasons test_owl_attack_move owl_analyze_semeai_after_move and gnugo -d 0x0004 (debug worms) does not complete because of the bug ++ Alain ___ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
Re: [gnugo-devel] bug surrounded
Le Mercredi 11 Janvier 2006 19:19, alain Baeckeroot a écrit : Le Mardi 10 Janvier 2006 22:11, Gunnar Farneb�ck a écrit : Did you get any further? It seems to me that it may be the same problem as in http://trac.gnugo.org/gnugo/ticket/61. /Gunnar a first clue :-) in both cases the backstrace of the stack in gdb is the same do_genmove collect_move_reasons owl_reasons test_owl_attack_move owl_analyze_semeai_after_move In test_owl_attack_move (owl.c : 4942) i have in both cases wrong dr2 int dr2 = DRAGON2(dr).semeai_defense_target; dr2=22 = B19 in _both_ cases !! which has no link with the semeais (in near J4 or T3), and is hopefully the wrong color which cause the crash. So it seems the bug is much earlier, in the definition of DRAGON2(dr).semeai_defense_target Well, thats enough for today :) Alain ___ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
[gnugo-devel] erroneous web site info concerning CVS import
Hello It seems there is a small error in the web site at http://www.gnu.org/software/gnugo/devel.html it says cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gnugo -z3 co gnugo which does not work for me (rh fc4) Having a look at savannah, i found that http://savannah.gnu.org/cvs/?group=gnugo says cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/gnugo co gnugo and this works fine :) Regards Alain ___ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
Re: [gnugo-devel] bug introduced in 3.5.5
Le Mardi 27 Décembre 2005 12:44, alain Baeckeroot a écrit : Le Dimanche 25 Décembre 2005 07:58, Markus Wennrich a écrit : ***assertion failure: owl.c:480 - board[apos] == OTHER_COLOR(board[bpos]) near T2*** hello i had alook after this bug: it appears with gnugo-3.5.5 at level 2 or less no pb at level 3 or higher i m slowly investigating ...(this is great fun :) hope this help alain ___ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel
Re: [ABUL/tech][Debian] Portable
Le Lundi 15 Décembre 2003 23:58, Tanen a écrit : Salut, J'aimerais savoir si quelqu'un a déjà installé une woody sur un Inspiron 8200, et si oui, comment a-t-il fait pour configurer la carte Vidéo NVIDIA GeForce 4 440 Go. Actuellement j'ai essayé d'installer le package xserver-svga, sans résultat, et quand j'essaie de compiler les drivers NVIDIA GLX et Kernel, j'obtiens une erreur a propos de cc sanity. Donc si quelqu'un pourrait m'aider, déjà pour empêcher X de se lancer au démarrage, car la je n'ai aucun moyen de le stopper je ne vois rien juste quelques lignes incompréhensible puisque l'affichage est mal configure, et par la suite comment configurer cette carte vidéo. Pour info j'ai essaye de changer de console, mais aucune n'est en VRAIE console, CTRL1.. 2.. 3.. 4.. mais aucune ne revient au prompt. Si quelqu'un pouvait m'aider ... Merci de vos infos. Bonjour http://www.laptop.org/ contient plein de renseignements sur les portables sous Linux Ca ne reponds pas à la question, mais ca permet de comparer avec d'autres ;) Cordialement alain Alain
