Announcing GoReviewPartner - v0.15 with Pachi and PhoenixGo

djhbrown · **#101**

Satorian wrote:

I'm more interested in looking at my three to five biggest mistakes per match

the biggest red bars are your biggest blunders, and they do stand out on the graph, but how much nicer would it be if grp could highlight them on the board itself? easy enough to compute - eg those that are more than 2 standard deviations from the mean difference between you and the oracle.

being shown where you went wrong is useful, but Monte-Carlo can't tell you why it is wrong - for that, you need either Swim or Michael Redmond.

pnprog · **#102**

djhbrown wrote:

being shown where you went wrong is useful, but Monte-Carlo can't tell you why it is wrong - for that, you need either Swim or Michael Redmond.

Well, as soon as there is a GTP version of Michael Redmond available for download, I will add support for Michael Redmond in GoReviewPartner :lol:

But in the meantime, here is GoReviewPartner v0.8, the new features are:

Win rate graph and comparison graph, as explained above
Added a way to select what game variation to use for the analysis, in case the SGF tree has more than one branch

To have the graphs work in a elegant way, I added some "private SGF properties" to the RSGF file, that I use to store the informations needed to plot the charts. Namely:

BWR: black win rate
WWR: white win rate
CBM: computer best move

I plan to use this sort of non standard SGF properties more intensively in the future, instead of passing the information through the SGF comments. This is a point where I really think the SGF standard needs an update. Clearly, we are entering a new era of Go, where computers are showing the direction, and the SGF format was not designed with that in mind 20 years ago...

Beside, I also put a lot of effort into writing some (much needed) documentation on how to install, configure and use GRP. I also separated the windows download in 3, depending of what bot you plan to use, this make the download much faster. Finally, I made a home page for this project, that looks like a real project home page :mrgreen:

So as usual:

Windows download from the home page
Source code from Github

I have not real to do list for v0.9, GRP is full-filling all my needs now. What I have in head for a potential next version:

I will probably spend a bit of time doing some code re-factoring, to make it easier to add support for other bots, a bit like add-ons.
I am also thinking in adding support for other language, not only English
I need to find a way to export the pictures in *.png, not *.ps
I am opened to adding support for other strong bots

Let me know if any issue or comments!

djhbrown · **#103**

pnprog wrote:

a GTP version of Michael Redmond

i guess there is such a thing, for as a professional, i am sure Michael would tell you his move for a small fee. A freeware Michael is a different matter; you would have to ask pnprog to make one for you based on Swim.

GRP could report (YourWR - 50%) by a traffic light next to your name on the display - then, keeping your finger on the arrow (next move) button would create an animated colour change as the game progresses.

... and at the risk of repeating myself, at the risk of repeating myself, you could colour the Your stones with a colour gradient according to temperature(YourWR-OracleWR) instead of drawing a graph.

the traffic light tells you when you started to lose (or win), and the stone colours tell you how much each of your moves is wrong

as to other bots, there is one called "gomap".... it doesn't make moves but it does draw pretty pictures that could be a useful learning aide, if it were available as an optional display toggle button; eg when the button is down, the gomap is displayed on the board, and when it is up, it isn't. if the gomap toggle were the letter "c" (or caps lock), you could press/unpress it with the left hand, leaving your right hand free to press/unpress the arrow button.

pleiade67 · **#104**

Tested version 0.8 on Mac. Everything works perfectly with Gnugo and Leela (the graphs are a most useful feature). Thank you so much.

If I may be permitted to add one more suggestion:
- an option for batch processing several games (useful for processing a collection of games overnight).
Besides, If you consider introducing go board and stone artwork, there are some available. For instance by the author of sabaki sgf editor:
https://github.com/yishn/Sabaki/tree/master/img/goban
There was also a forum thread on this topic: For developers: Easy ways to render nice stone graphics:
https://lifein19x19.com/forum/viewtopic ... 10&t=10226

Best,

pnprog · **#105**

pleiade67 wrote:

Tested version 0.8 on Mac. Everything works perfectly with Gnugo and Leela (the graphs are a most useful feature). Thank you so much.

Thanks for reporting it working on Mac, that's the one platform I cannot test myself!

pleiade67 wrote:

an option for batch processing several games (useful for processing a collection of games overnight).

At the very beginning, that was possible to run the analysis from a terminal command, even in a no graphical environment. The possibility was lost as the application became more and more "graphical"... but I plan to bring it back. In fact, originally, I had made a script that would check every few hours for new game on my OGS account, then run an analysis automatically if new games were played. As I used to play at work during lunch time, I would have the analysis ready when I get home.

pleiade67 wrote:

Besides, If you consider introducing go board and stone artwork, there are some available. For instance by the author of sabaki sgf editor:
https://github.com/yishn/Sabaki/tree/master/img/goban

Those are nice. I guess I really should try to make GRP more visually appealing :lol:

ez4u · **#106**

Any chance for an unbundled windows version? Those of us just updating already have the engines and may already be using Lela 11 as well.

pnprog · **#107**

Hi!

ez4u wrote:

Any chance for an unbundled windows version? Those of us just updating already have the engines and may already be using Lela 11 as well.

You have different choices:

Download the GnuGo bundled, because it's the lightest, then get rid of GnuGo inside (delete the goreviewpartner-0.8_gnugo-3.8/gnugo-3.8 sub folder, clean the gnugo command parameter in the Settings) then configure it to use Leela instead
Run from the python source
I should made a Windows download without bot

Do you mean Leela 11 beta?

pnprog · **#108**

Hi!

I made some improvement on the aesthetic of GRP, goban and stones.
Finally I did not used any image, but went for generated texture, the goban looks like this:

Attachment:

wood.png [ 39.15 KiB | Viewed 18036 times ]

Now, because this is "generated", it's easy to add a salt of randomness inside, so that every time, the goban will look different.
I did something similar for the stones, but it's less obvious:

Attachment:

stones.png [ 91.32 KiB | Viewed 18036 times ]

Notice that both gobans are different.

I still plane to play a bit with that (on my local version, the goban wood has "nodes", and the stones bright spot position change with the time...), but I am already quite satisfied.

ez4u · **#109**

I like the work you are doing on this. However, should the 'grain' of your texture be oriented top to bottom rather than left to right?

pnprog · **#110**

ez4u wrote:

I like the work you are doing on this. However, should the 'grain' of your texture be oriented top to bottom rather than left to right?

Now that you mention it, I seem to only find representation of Goban with vertical "grain" (wood fiber), and parallel with the Goban grid.

Is there some sort of aesthetic convention for that?

By the way, I have been looking at the AQ bot today, I think I will be implementing support for that bot as well in the coming v0.9

djhbrown · **#111**

pnprog wrote:

aesthetic convention

the eye is naturally drawn to contrasts, which in the case of incidentals, can detract from understanding.

So yes, it would make seeing what's happening on the board easier by adopting the convention of vertical grain, and it would be helpful to make the grain very soft, so that it does not attract the eye. The same goes for marking the handicap points, gridlines and coordinate letters/numbers, which could be more muted.

The last move could be indicated by a small grey blob instead of a large bright triangle, which grabs attention.

The opposite applies to markups - the annotator wants to draw the viewer's attention to the letter "A", so it should stand out clearly; computers have given us colour - so letter marks could be temperature coloured... oh! you do use colours - blue for >50%win and red for <50% - that's great, but unfortunately bright red catches the eye more than dull blue; so how about bright green for >50% and dull red for <50% (with the idea that green is good (safe) and red is bad (dangerous))?

btw, all the various stats Leela provides are only of interest to Leela developer; all a player needs to know is win%

jeromie · **#112**

pnprog wrote:

ez4u wrote:

I like the work you are doing on this. However, should the 'grain' of your texture be oriented top to bottom rather than left to right?

Now that you mention it, I seem to only find representation of Goban with vertical "grain" (wood fiber), and parallel with the Goban grid.

Is there some sort of aesthetic convention for that?

When sitting at a real go board, it is conventional to align the board so that the grain traces lines between you and your opponent. In Japanese style boards that are not perfectly square, this also maintains the correct orientation of the board.

At a computer, it is natural to think of yourself as playing from the bottom and your opponent from the top, so vertical grain maintains this convention.

pnprog · **#113**

Thanks both for the explanation, I have change the wood fiber direction to be vertical now.

pleiade67 wrote:

an option for batch processing several games (useful for processing a collection of games overnight).

I have just finished to implement that, but it had to be used in command line, with python.

Usage: python bot_analysis.py [--range=<range>] [--color=both] [--komi=<komi>] [--variation=<variation>] <sgf file1> <sgf file2> <sgf file3>

Here are a few examples:

Code:

python leela_analysis.py mygame.sgf

Analysis of mygame.sgf, first variation, using Leela, all moves, both colors, komi as indicated by the SGF file

Code:

python leela_analysis.py mygame1.sgf mygame2.sgf mygame3.sgf

Same as above, for the three SGF files will be analyzed

Code:

python ray_analysis.py *.sgf

Same as above, but all the SGF files will be analyzed, and the analysis will be performed by Ray

Code:

python ray_analysis.py --color=black mygame.sgf

Analysis of black moves only

Code:

python aq_analysis.py --range="10-20, 44,46, 100-110" mygame.sgf

Analysis of moves 10 to 20, 44, 46 and 100 to 110 by AQ

Code:

python aq_analysis.py --variation=3 --komi=7.5 mygame.sgf

Analysis of variation 3, with setting the komi at 7.5 (some SGF files do not include komi)

pleiade67 · **#114**

Awesome ! Thank you very much ! :clap:

pnprog · **#115**

Hi everybody!

Here comes GoReviewPartner version 0.9 !

The mains changes compared to v0.8 are:

Added support for AQ, the new bot that apparently is stronger than Leela and Ray
Lot of "eye candy" improvement (goban/stones, interface, logo)
I put a lot of work into handling issues at run time (error when launching the bot, accessing/reading the config file or SGF file...) in order to intercept most of errors and fail gracefully (in a way that tell the user what happened)
Added some scripting features for batch analysis (also useful for me to automatize testing)
And a lot (really a lot) of code factorization, that will allow me to add support for new bots pretty easily in the future.

I made several download zip file for Windows (one for each bot), they can be found on the home page together with the updated documentation: http://ns1297.imingo.net/

For the next version, I am considering adding minimal support for other languages. I guess I can handle the French translation by myself, maybe also the Chinese translation. Then I would appreciate if some of you can support me for other languages.

johnsmith · **#116**

Can we soon expect adding Leela Zero in the list of engines?

roy7 · **#117**

LZ isn't ready for use for reviewing, it's still very weak.

yoyoma · **#118**

roy7 wrote:

LZ isn't ready for use for reviewing, it's still very weak.

It's so that we can review LZ. :cool:

johnsmith · **#119**

@roy7
I am aware that LZ isn't that strong yet, but it will be dan level before Christmas, don't you think? It wouldn't hurt to have it as a tool even now. GRP author mentioned that he had found a way to easily implement new engines. And GRP is my favourite tool in combination with Leela (Zero). I have a feeling that I could skyrocket my rank if I analyze games with GRP every day. Like a 9p sensei by my side at all times

@yoyoma
Always one step ahead

djhbrown · **#120**

johnsmith wrote:

I have a feeling that I could skyrocket my rank if I analyze games with GRP every day.

i have a feeling you could skyrocket your rank if you asked Leela's advice before making a move; asking after is too late, because whereas children learn by imitation and Alfie learns by hill-climbing, the adult brain stubbornly refuses to believe that what it already believes could possibly be wrong even when faced with stark evidence of its flawed nature, so at best it can only learn cognitive dissonance. One evidence of this biological certainty is that you won't believe what i just said.

Announcing GoReviewPartner - v0.15 with Pachi and PhoenixGo

Who is online