gonmf / matilda Goto Github PK

More unitary and regression testing are needed.

Parameter optimization is mostly missing for board sizes above 9x9.

See things marked TODO.

We currently have no more accurate scoring function that counting stone and area

Optimize first for 9x9, then use the results for the domain for 11x11 optimization; repeat this increasing the sizes.

Not available on text mode? Allow instead muting stderr on GTP mode?

ob_lean/ob_gen do not detect modified header files. Take this opportunity to refactor and use the generic hash table implementation in these programs

Performance optimization - it has been a while since the last time it was ran.

• profiling with valgrind for most important improvement areas
• playout caching, try only updating data when needed
• when playing very fast the non-critical parts, GTP protocol, kifu, could be improved; this would improve the speed of fast optimization

Also consider using the free https://aws.amazon.com/ec2/ to run 9x9 matches.

issue continues on #95

Given the implementation matilda should be stronger even playout per playout.

Matilda appears to be ~150 ELO weaker in 9x9 with 1000 simulations/turn! With large patterns disabled.

Possible causes:

• playout policy - move selection?
• playout policy - stopping early
• AMF/RAVE schedule? - michi uses equiv schedule and before and after amaf data, not just after
• UCT priors?
• UCT tactical restrictions, self-ataris? - strength improved how much? #34
• definition of eye -- strength improved but little
• 3x3 pattern weights?
• expansion delay?
• owner maps?
• 3x3 patterns and their weights?
• not cleaning states between matches/turns?
• ignoring transpositions?
• matilda running multi threaded and suffering from virtual loss more?
• michi is counting simulations as number of playouts instead of MCTS traversions and as such playing more simulations based on expansion delay?
• RNG

Winrate against Michi-C, 1000 playouts/turn, no multi-threading: 23.8% (-202 ELO)

taking out parts of michi to see strength decreases

• base wr against michief, 1k/turn, no o.b., no multithread: 25.4%, 67 games T(5.1 vs 70)
• against michi, with o.b., multithreaded: 14.3%, 7 games, T(1.4 vs 137.1)

even just barebones UCT with no priors and random playouts beats matilda!!

• base wr against michief, 1k/turn, no o.b., no multithread: 38.5%, 26 games T(5.4 vs 27.4)

what could it be?

• self-atari prevention?
• AMAF/RAVE again?

With Matilda final_score corrected

• against michief: 86.9%, 61 games, T: 5.7 to 54.7
• against michi-c: 18%, 50 games, T: 3.9 to 5
• against michi-c with expand_visits=0: crashes
• against michi-c with expand_visits=2, mat with e.v=4: 33.1% 178 games
• against michi-c both with expand_visits=4: 31.5% 73 games, T: 3.6 to 5.3
• ^ without 3x3 patterns in playouts for michi-c: 42.9% 70 games
• ^ without capts in playouts for michi-c: 55.7% 70 games
• ^ without empty priors: 29.6%, 71 games
• against michi-c both with expand_visits=4: 23.7% 169 games, T: 3.2 to 4.9

26.8%, 314, 3.3 vs 5

nothing works, even without fix_atari michi is close to 50% but beating matilda

• AMAF again using both before and after traversions?

Might be unrelated but investigate why is the MSE equivalence parameter so different in michi and matilda.

Ditch UCB1-tuned like Michi

• Optimize RAVE equiv/b for use without UCB check if ~2000 is really optimal point
• Clean up references to UCB in code
• Compare with the use of equiv=3500 that Michi uses

winrate vs michi-c now 37% (135 games, T 2.8 vs 5.3 no multithread)

winrate vs michi-c now 46.5% (310 games, T 2.6 vs 5.6 no multithread)

winrate vs michi-c now 48.5% (135 games, T 2.5 vs 5.6 no multithread)

• Matilda vs Michi-C with 10k/turn: 27% (37 games, T16.6 vs 45.9)

issue continues on #95

Testing things like playout speed but attempting to lower the impact of the actual MCTS.

on-hold due to lag and other practical issues

Optimization related to research paper.

• optimize linear
• benchmark linear
• optimize geometric
• benchmark geometric
• optimize geometric byo yomi
• benchmark geometric byo yomi

To be used together with disabled or reduced transpositions table cleanup.

• allow illegal plays that may produce a legal play
• relax tactical restrictions

Because of tactical restrictions it plays a weak Frisbee Go!

Review if the joseki extraction is correct when compared with the use of sgfutils sgfvarsplit, and think further on how to implement and use a joseki dictionary.

• test using different OMP division of the main parallel for work (time based)
• test using configurable time based vs playout based; with variable nr of playouts
• test different OMP simulation batch sizes (time based)
• test passing immediately if pass possible and winrate > 0.95
• test stopping early if best play is significantly better than 2nd best (by quality? nr of sims?)

Very serious.

May have affected multiple optimizations:

• removal of relaxed_eye and use of eye only
• the improvements of PR #34
• the tests of issue #5

Play grouping did not work but looked promising. Think further on the criteria for grouping and see if the increased performance makes it worth it.

• count captured stones
• discourage MCTS to play suicidal plays, slightly maximizing the score difference instead of win rate
• add a scoring function by Japanese (area) scoring
• switch to Japanese byo-yomi time system by default if the rules are Japanese
• add an option to choose Chinese or Japanese rules

Implement this to some extent even if ignored by MCTS.

Is there even a fix for this without automake or newer making tools?

Experiment with simpler safe_to_play function and testing captures by tactical reading instead of immediate capture only.

• Decide whether spb or ob take precedence
• Version 20
• 3x3 pattern experiments
• CLOP time factor only; with self-play, 2s/game and OB turned off #72
• Generate more thorough O.B. #59 (4a)
• Benchmark self-play with vs without OB/SPBs
• CLOP playout heuristics; with 400 playouts/turns vs gnugo lvl 0
• Version 21 and merge #68
• CLOP time factor and RAVE; with self-play with about 30s/game and OB turned on (5a,6a,S,D)
• Test using amazon instance or digital ocean instance for tournament play, suggested: c4.2xlarge #69
• Benchmark vs GNU Go for rank estimate

Previous experiments couldn't provide a suitable implementation of dynamic komi, but they were not run with CLOP, so one day try again. It is relatively fast to implement too.

https://en.wikipedia.org/wiki/Hash_table#Transposition_table

Covering at least:

• Overall architecture, assumptions and conventions.
• Using parts of matilda in other programs.
• User manual with options and examples of use of the different programs.
• Short description of each component.

Remove stdout from the options and have text mode also only use stderr

Read more:
http://homepages.cwi.nl/~aeb/go/misc/ugf.html