gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gnugo-devel] nando_3_9.4c


From: Nando
Subject: [gnugo-devel] nando_3_9.4c
Date: Sun, 29 Sep 2002 02:47:15 +0200

Hi,

This patch needs nando_3_9.9 in order to work properly and supercedes
nando_3_9.4b.

I implemented many of Arend's suggestions (see his post) and added a couple
features as well. It's late and I'm too tired to list these. I'll simply
paste the notes I took while analyzing the regression breakage.


Without --experimental-owl-ext, there is (of course) no change, neither in
terms of results, nor in terms of performance (owl nodes).


When enabled :

---- File [owl.tst]
148 FAILED: Correct '1 A5', got '5 A5'

 Test should be fixed. '(1|5) A5'

---- File [blunder.tst]
12 PASSED
20 PASSED

 No comment

---- File [neurogo.tst]
13 FAILED: Correct '!P7', got 'P7'

 I haven't investigated this one yet. Most probably, it spots an 
 interaction problem between a ko situation and GAIN/LOSS. 

---- File [trevorb.tst]
290 PASSED

 Gnu Go plays now E10. I'm not sure it does this for the correct reason
 though (fight the ko), but it's possible after all. I gotta verify it.

---- File [nicklas5.tst]
1203 PASSED

 Not a real pass, but interesting. I recall this one failed with a
 recent patch, but L19, while being a bit strange, is actually ok. The
 engine now prefers K18 again because of this :

 owl_does_defend L19 M18(M18), result 2 (9, 3964 nodes, 0.06 seconds)

 L19: defense of worm M18
 L19: -1.80 - suspected ineffective defense of worm M18

 So, the engine is starting to understand that it will have to
 sacrifice N17, but it currently doesn't see that the same thing will
 happen with the newly chosen move, K18. Still some work to do...

---- File [trevor.tst]
290 PASSED

 Expected, no comment.

---- File [vie.tst]
38 FAILED: Correct '1 (B6|A4)', got '5 B6'

 Test should be fixed. '(1|5) (B6|A4)'

---- File [arend.tst]
17 FAILED: Correct 'C7', got 'C9'

 At first it seems that when trying to connect at C7, Gnu Go gets
 worried of the cut C9 and doesn't consider playing D11 because E10
 isn't in the goal (find_superstring() only adds the stones of the
 bottom half of that neighboring dragon. Possibly it thinks that it
 cannot do anything against the loss of E10 stones, but then I don't
 understand why it isn't more worried about loosing G9.
 I have to investigate this one more.

---- File [strategy4.tst]
199 PASSED

 Bogus, just a horizon effect.

 CVS : 
   owl_defend G5, result 0 PASS (810, 133377 nodes, 1.28 seconds)
 now :
   owl_defend G5, result 5 N5 (1000, 162987 nodes, 4.45 seconds)
 and with --owl-node-limit 2000 :
   owl_defend G5, result 0 PASS (1748, 286753 nodes, 7.91 seconds)

---- File [nngs2.tst]
240 FAILED: Correct 'F17', got 'B14'

 Horizon effect again. Gnu Go is now uncertain of the safety of the
 F16 dragon. So it prefers B14, which is supposed to defend better
 than F17 (there's probably a problem here). B14 beats F17 by 0.2
 only though.



Total: 4 "good" passes, 2 serious failures and a measured overhead of about
3% more owl nodes.

Like my IRC friends would say, :/

/nando

Attachment: nando_3_9.4c
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]