Pachi 12 for Windows

[lemonsqueez]

I had a try and it seems to work just fine now. By the way, I am curious how Pachi can decide when the fuseki is over.

Nothing fancy right now, fuseki is fixed at first 20 moves for 19x19, less for smaller boards.

Code: Select all

[280000] best 49.0% xkomi 7.5 | seq Q16 L17  D4 C11 | can b Q16(49.0) Q17(48.5) K10(49.0) P16(49.0)

• 280000 is the total number of play outs/simulations reached up to that point?
• 49.0% is the winrate associated to the best move found up to that point?
• seq Q16 L17 D4 C11 indicates the best move so far is Q16 (the one associated with the 49.0% from above), and L17 D4 C11 the expected follow up?
• Q16(49.0) Q17(48.5) K10(49.0) P16(49.0) are the other moves considered by Pachi at this point? (alternative moves)
  • They do not appear ordered from best to worst (Q17:48.5 < K10:49.0), so is it safe to order them from best to worst using the % value, or that order is somehow important and should be preserved? (lower % but more thoroughly tested with more play outs)

Yes, that's correct.
The candidates are ordered from best to worst, but for mcts best means most visited, the winrates are more indicative and can be out of order.

• The number of move of the follow up sequence seems to always be 3, regardless of how much thinking time I put in it. Is this a fixed parameters?
• The number of alternative moves seems to always be 3, regardless of how much thinking time I put in it. Is this a fixed parameters?
• Is there a way to get a follow up sequence for those moves as well? I noticed that for some of them, a follow up sequence can sometime be found in the other log lines above, but it might not be the most probable follow up I guess

Yes, these lines are more of a summary, they only show the 4 best candidates and follow-up moves regardless of how deep the tree is. You can get the full picture by looking at the whole tree:

Code: Select all

pachi -d4 -t =5000
[1000] best 62.8% xkomi 0.0 | seq K14 M15 F19 G19 | can w K14(62.8) M14(65.0) M15(56.6) J17(60.9)  | 0.6Mb
[2000] best 63.4% xkomi 0.0 | seq K14 M15 M14     | can w K14(63.4) J17(66.6) M14(62.3) M15(58.7)  | 1.1Mb
[3000] best 76.6% xkomi 0.0 | seq  H8  O4  K8     | can w  H8(76.6) K14(62.8) J17(65.9) M14(61.9)  | 1.7Mb
[4000] best 77.3% xkomi 0.0 | seq  H8  H4  H5  H3 | can w  H8(77.3) K14(62.8) J17(65.9) M14(61.9)  | 2.1Mb
[5000] best 76.7% xkomi 0.0 | seq  H8  F2  J8  O4 | can w  H8(76.7) K14(62.8) J17(65.9) M14(61.9)  | 2.7Mb
(UCT tree; root black; extra komi 0.000000; max depth 7)
[pass] 0.693/5016 [prior 1.000/0 amaf 1.000/0 crit -0.693 vloss 0] h=0 c#=165 <857b68360000024f>
 [H8] 0.768/2548 [prior 0.961/257 amaf 0.738/10099 crit 0.015 vloss 0] h=0 c#=165 <857b688b000002a4>
  [F2] 0.746/657 [prior 0.056/177 amaf 0.751/4072 crit 0.000 vloss 0] h=0 c#=163 <857bae8000004899>
   [J8] 0.740/154 [prior 0.944/180 amaf 0.760/1592 crit -0.000 vloss 0] h=0 c#=163 <857bb28c00004ca5>
   [G6] 0.766/107 [prior 0.500/20 amaf 0.798/914 crit 0.020 vloss 0] h=0 c#=163 <857bb27d00004c96>
    [G7] 0.727/77 [prior 0.056/180 amaf 0.731/234 crit 0.012 vloss 0] h=0 c#=161 <857bde5f00007873>
   [G7] 0.854/96 [prior 0.722/36 amaf 0.807/886 crit -0.000 vloss 0] h=0 c#=163 <857bb28500004c9e>
   [S15] 0.790/81 [prior 0.500/20 amaf 0.795/623 crit -0.102 vloss 0] h=0 c#=163 <857bb2b800004cd1>
  [H4] 0.791/406 [prior 0.090/111 amaf 0.732/2750 crit -0.176 vloss 0] h=0 c#=163 <857bae95000048ae>
   [H5] 0.859/191 [prior 0.908/109 amaf 0.850/707 crit -0.001 vloss 0] h=0 c#=163 <857bb1d000004be9>
...

For long thinking times this can be huge, max depth will be much bigger. First number is winrate, second is visits for each line.

If you want to use this in GoReviewPartner try json reporting:

Code: Select all

pachi -t =5000 reporting=json
{"move": {"playouts": 5064, "extrakomi": 0.0, "choice": "H8", "can": [[{"H8":0.792},{"F2":0.778},{"G6":0.831},{"G7":0.815}], [{"K14":0.603},{"L13":0.593},{"M13":0.627},{"K13":0.593}], [{"M15":0.603},{"L13":0.724},{"M13":0.778},{"K13":0.700}], [{"M14":0.627},{"M15":0.647},{"N15":0.596}]]}}

Might be easier to use. Also you get best sequence for each candidate. Number of candidates is fixed at 4 but this could be increased. Same for sequence length. There's also 'reporting=jsonbig' which has even more stuff.

[pnprog]

Hi!
Thanks for the detailed reply!

The three view offers a lot of information, but it's a little overwhelming. GRP would needs a "tree" view of the game to take advantage of this, and I am trying to avoid that (I am a proponent that less information, is easier to navigate and becomes more useful).

The json report is very handy I guess I will go for this.

4 alternatives + 4 moves per alternative is probably enough. FanHui was quoted saying that, if you can read 3 moves deep, then you are already dan level

Just one question:

Code: Select all

{"move": {"playouts": 5064, "extrakomi": 0.0, "choice": "H8", "can": [[{"H8":0.792},{"F2":0.778},{"G6":0.831},{"G7":0.815}], [{"K14":0.603},{"L13":0.593},{"M13":0.627},{"K13":0.593}], [{"M15":0.603},{"L13":0.724},{"M13":0.778},{"K13":0.700}], [{"M14":0.627},{"M15":0.647},{"N15":0.596}]]}}

From comparing the outputs for different reporting, it appears that in the above case:

• Pachi estimates H8 with a 79.2% win rate
• Pachi estimates K14 with a 60.3% win rate
• Pachi estimates M15 with a 60.3% win rate
• Pachi estimates M14 with a 62.7% win rate

Now, looking only at the first variation, the continuation moves H8, F2, G6, G7, they all have associated win rates:

Code: Select all

[{"H8":0.792},{"F2":0.778},{"G6":0.831},{"G7":0.815}]

• H8: 79.2%
• F2: 77.8%
• G6: 83.1%
• G7: 81.5%

How come they don't share the same winning percentage?

I was under the impression that Pachi was performing a sort of mini max algorithm, so the win rate of the complete "path" would be deduced from the deepest leaf (following a "mini max" propagation from deepest leaf to first leaf) of something like that (although here, I understand that Pachi goes deeper than 4 moves, to we don' know the value of that latest leaf).

Said differently, what are the meaning of those values

[lemonsqueez]

Hi again !

How come they don't share the same winning percentage?

I was under the impression that Pachi was performing a sort of mini max algorithm, so the win rate of the complete "path" would be deduced from the deepest leaf (following a "mini max" propagation from deepest leaf to first leaf) of something like that (although here, I understand that Pachi goes deeper than 4 moves, to we don' know the value of that latest leaf).

Well that makes sense, for each node the percentage is the average winrate over all followup moves explored. Within this subtree mcts explored other moves besides this sequence so the winrates are going to differ depending on what was explored: better moves pull it up, worse ones pull it down.

To get an idea of the situation at the end of the sequence you would look at the winrate of the last node (provided there are enough playouts for this node or it won't be very significant).

[pnprog]

Hi again!

If you want to use this in GoReviewPartner try json reporting:

So I implemented support into GoReviewPartner using json reporting, so far so good. I am very satisfied with the result

Number of candidates is fixed at 4 but this could be increased.

I searched in the code, and modified the values for the number of variations, and deepness for each variations. But the resulting json formatting was incorrect (some comma missing between elements of arrays). I was able to modify the code to fix it, compiled it and tested it on my computer.

Next I sent a pull request on the project's Github, and got a tons of issues with that Travis CI build. I don't know much about C++, but I am fairly confident this is unrelated to the code changes I mage:

Code: Select all

The command "if [ "$TRAVIS_OS_NAME" = linux ] && [ "$DCNN" = 1 ]; then sudo apt-get install libcaffe-cpu-dev -y ; fi" failed and exited with 100 during .

I don't know what to do next to have that pull request, accepted. Could you help me check?

[lemonsqueez]

update: Nov 06, Pachi 12.20 is out.

• dcnn: handle smaller board sizes
• don't play slack when taking handicap
• mm patterns fixes, better prediction rate
• use joseki engine when playing without dcnn

See homepage for more info.

[lemonsqueez]

Pachi 12.30 is out:

• lizzie support !
• dcnn pondering
• japanese rules: territory scoring in playouts
• full gtp undo

See homepage for more info.

[lemonsqueez]

Pachi 12.40 is out:

• speedup, about 20% faster
• multiple dcnns support: detlef44, detlef54, darkforest
• lz-genmove_analyze support (get winrates in sabaki etc)
• lz-analyze: handle frequency
• set engine options over gtp
• dcnn pondering fix

See homepage for more info.

[WinPooh]

I wonder why Pachi engine is so weak in Android application AhQ Go. Not only it plays at 15k level but also sometimes makes illegal moves.
Computational power of my phone is enough for AhQ Go / Leela to play at 4d KGS strength...

[lemonsqueez]

Pachi 12.50 is out:

• fixed analyze issues in Sabaki
• automatically grow tree memory as needed
• fixed kgsgtp-3.5.20+ crashes (kgs-chat disabled by default now)

See homepage for more info.

[lemonsqueez]

Pachi 12.60 is out:

• fixed remaining seki issues
• fixed tree gc issues
• removed --accurate-scoring, unnecessary now
• --smart-pass: more user-friendly pass behavior

See homepage for more info.

[And]

Pachi 12.70 https://github.com/pasky/pachi/releases

• Joseki fixes from Pachi games (2018-2022)
• Allow to override joseki sequences by editing an SGF file
• Better bent-four handling
• Fixed some dcnn blunders (first-line connects)

Joseki fixes are meant for online play primarily and need an external engine setup (KataGo), but will work for local play too if you take the time to set it up. See josekifix/README and josekifix/katago on how to update the database and setup KataGo.

[lemonsqueez]

Thanks And =)

[lemonsqueez]

Pachi 12.80 is out:

• Filter more dcnn blunders
• Better MM atari patterns
• Updated joseki fixes database (2023-05-12) + code
• UCT search speedup

Haven't tested extensively yet, if you see something unusual please let me know (create an issue on github).
Enjoy =)

[lemonsqueez]

Pachi 12.82:

• Retuned dcnn and pattern priors
• Use progressive dcnn prior
• Normalize pattern probabilities
• Set number of threads for dcnn evaluation

Retuned prior parameters, slightly stronger than 12.80 and should deal with dcnn blind spots better.
Have fun =)

[lemonsqueez]

Pachi 12.84:

• Added --banner option (replaces "banner" uct param)
• Fixed options that got broken in 12.80 (--kgs, --kgs-chat, --noundo, --name work again)
• Fixed memory corruptions found by address sanitizer
• Minor josekifix and mm fixes
• Updated joseki fixes database (2023-08-21)