gnugo-devel
[Top][All Lists]
Advanced

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

[gnugo-devel] Owl tuning


From: Nando
Subject: [gnugo-devel] Owl tuning
Date: Mon, 28 Oct 2002 11:07:03 +0100

List of changes :

A207c:   Modified
A207d:   New
A208b:   New
A411:    Modified constraint
A411a:   New
A413a:   New
A414a:   New
A1017:   New
A1018:   New
A1019:   New
A1020:   New
A1120:   Removed
A1130:   New
D1004:   Modified constraint
D1102a:  New


Performance :

268957 owl nodes saved, out of 1486471 (i.e. -18.09%)

(A1120 removal alone: -291398 owl nodes)



Regression breakage :

(A1120 removal alone : 21 PASSes and 28 FAILs)

* 22 PASSes

Sorry, but I didn't even spent one minute checking these. Call me
lazy if you want, but it was a long work for me (I'm still new to
this) to try to find good replacements for A1120 and I feel a bit
tired now. I think it's ok to assume that even if many of these
passes are "lucky" (I don't think it's the case though), the patch
is very beneficial anyway.

In case it's considered mandatory that each of these PASSes is to be
checked carefully, then I'll do the job, but it will take me some
time, because I'd like to work on something else for a while.

- owl:259
- strategy:20,34
- neurogo:12
- strategy2:89
- nngs:700,1700,1800
- strategy3:137
- trevord:880
- handtalk:10
- nngs2:120,410
- nngs3:110,140,280,460,680
- strategy5:224,225,234
- auto03:12

  
* 12 FAILs

I talked in an earlier post about a future patch for dragon cuts.
In the following, the mention "dragon cut" means that I think the
problem should/would be properly solved once this patch is
available.

- nngs1:8

  Dragon cut.

- nngs1:33

  A1120 was causing an owl node limit exceeding which was driving
  the engine to think that the lower right white dragon could be
  possibly saved. Now, it sees the kill and the old (and unrelated)
  problem around S9 has surfaced again. I tried to look at it, but
  it looks quite tough. 

- rosebud:1

  Actually, I solved the problem with this defense pattern :

  XOX  (with a couple constraints, of course)
  XO.
  ..*
  ...
  ---

  Basically, I think this pattern is good, this kind of move is to
  be considered in some situations. Though, I tried it and while it
  has no nasty effects (no failures, owl nodes impact quasi null),
  it only corrects this failure by pushing the owl reading over the
  limit. So I didn't include it in the patch and I'm waiting for
  comments about this issue.

- lazarus:6

  Dragon cut.

- nngs:510

  Dragon cut.

- nngs:1320

  Gnu Go doesn't think that O18 kills M17 any longer. I'm not sure,
  but I don't think M17 is that easy to kill. Anyway, I think O18
  valuation is now largely underestimated (just chasing the now weak
  stones, making points and gaining strength/influence, looks fairly
  enough to me) and that should be the target for investigations
  (which I haven't started)

- global:1

  Well, A4 wastes a ko threat, but that's not the point here. Gnu
  Go has changed its local evaluation quite a lot. It now thinks
  that the E9 dragon can't be saved, because it found the severe
  W E6 (generated by A1017, which I'm quite happy with). Now, we
  need to teach the engine that the dragon can be saved by
  sacrificing some stones. Globally, I think there's an improvement
  here.

- 13x13:149

  Owl nodes limit problem. With 1100, Gnu Go still plays L7

- trevord:230

  IMHO, L9 is better than the proposed solution. Sure, it's already
  very late to start reducing black's moyo, but we are already way
  behind (Gnu Go is aware of it) and killing these 3 light stones
  won't save the game (after W G6, I'd play B G8)

- strategy4:179

  Owl reading mistake. Gnu Go thinks O5 kills and I haven't managed
  to correct this so far. But it seems feasible, so I think this
  FAIL is acceptable.

- strategy4:181

  Owl reading mistake again. Now that attacking has been improved,
  the engine needs about 1300 nodes to realize that P5 can be
  defended (and 2600 to see that it's alive as it stands). I dunno
  in which direction I should look to solve this problem.
  Suggestions anyone ?

- safety:5

  Previously, Gnu GO based its decision to jump out on the belief
  that P9 would otherwise get killed. I think this analysis is
  wrong, i.e. I haven't found a way to kill P9 (L9 doesn't seem to
  work, because black is a bit thin around M6). But for sure, the
  threat should be enough to push White to do something locally.
  In conclusion, this FAIL looks acceptable to me.



/nando

Attachment: nando_3_11.1
Description: Text document


reply via email to

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