New Ray is out which is ladder-conscious. It uses elf network with human added ladder knowledge. Someone on reddit said that the new Ray is beating LZ 100% because of no ladder weakness.
https://github.com/zakki/Ray/releases

But for some reason, GRP doesn't work with this ray. Is it just me?

Are you running the RLO version? If so, it has a different GTP name, "RLO", instead of "Rayon." I made these changes to ray_analysis.py just as a workaround, although this is not a formal fix. (Just change Rayon to RLO everywhere.)

diff --git a/ray_analysis.py b/ray_analysis.py
index d4a3a46..aa3adbf 100644
--- a/ray_analysis.py
+++ b/ray_analysis.py
@@ -132,7 +132,7 @@ class RayAnalysis():
return ray

def ray_starting_procedure(sgf_g,profile="slow",silentfail=False):
- return bot_starting_procedure("Ray","Rayon",Ray_gtp,sgf_g,profile,silentfail)
+ return bot_starting_procedure("Ray","RLO",Ray_gtp,sgf_g,profile,silentfail)


class RunAnalysis(RayAnalysis,RunAnalysisBase):
@@ -305,7 +305,7 @@ class RayOpenMove(BotOpenMove):

Ray={}
Ray['name']="Ray"
-Ray['gtp_name']="Rayon"
+Ray['gtp_name']="RLO"
Ray['analysis']=RayAnalysis
Ray['openmove']=RayOpenMove
Ray['settings']=RaySettings

Awesome, it works!

Baduk1 channel from youtube made a nice analysis of the most recent Lee Sedol game using Elf engine with a lot of playouts: https://www.youtube.com/watch?v=8yZjtJu2lM0
And here's the sgf: http://eidogo.com/#1fo7mSKKW
I wanted to analyze this game myself, but baduk1 did it first

Besides a beautiful game, one thing to notice is that baduk1 channel used GRP v10. I don't know why he used v10, but I also prefer v10 because the winrate is shown for every move in this format B%/W%. And no need to scroll to see all comments for every move.

Edit: some more.
https://youtu.be/EvbM8kUEsRI
http://eidogo.com/#vnfyKPNS

https://www.youtube.com/watch?v=IseK4Bh1LDk
http://eidogo.com/#ymzstdin

I basically agree, I need some time to think over this, and come up with a good solution (something simple).

For the moment, this option is available when running GRP with python, it can be scripted in a BAT file (windows) or bash file (Linux/MacOs). I know running it from command line is not ideal

_________________
I am the author of GoReviewPartner, a small software aimed at assisting reviewing a game of Go. Give it a try!

It's good to see this project active again!


Wow, that's cool! I have been busy those past two weeks, so I have many things to catch up. If it works for you, could you send a pull request on the github project? I will gladly accept it. I guess future version of Ray will all be name RLO anyway, and it's better to support the latest version anyway.

_________________
I am the author of GoReviewPartner, a small software aimed at assisting reviewing a game of Go. Give it a try!

Yeah, the text boxes could stand to be a little taller so you can read everything without scrolling. That's a change I made locally after unsuccessfully trying to get the Tk layout engine to resize them automatically.

Very nice video, thanks for the share! It's fun, I started noticing mentions of GRP in many places
One such mention of GRP was on this Taiwan blog: http://www.kenming.idv.tw/let-go-ai_as_the-go-review-partner/


Yes, I also miss that info. I will find a way to put it back in the UI.

Regarding the UI: I received a lot of help to improve the UI last months. It's still in development, but the current UI looks like this:

So there is only one comment box now, on the right side. By default, it shows the comments that were used in the left side box. And when a variation is displayed, the comment then show the variation data. Those comments are very verbose, and are intended for users that don't have much experience with bots, GRP and all that AI vocabulary.


Then, it's possible to replace those comments by the table. It's still work in progress, but the idea is that the table is for more experienced users, sort of "hardcore gamers". They are the same info, but will be condensed a lot, and not verbose at all. But all infos are available at a glance.


The size of both gobans and the comments/table panel can be adjusted horizontally (and GRP can be resized vertically) at your convenience, to the point that you can make the left goban (or the right one) totally invisible.

The current development version is very buggy, so maybe don't try it at the moment. I received support (and a new translation) from one Chinese user, and he help me find plenty of encoding issues when working with SGF files that have eastern encoding. I have still a lot of work to do to make it work properly.

_________________
I am the author of GoReviewPartner, a small software aimed at assisting reviewing a game of Go. Give it a try!

Well, it's very well deserved and useful.

Totally agree on this. I prefer "hardcore gamer" layout myself as a 6d, because it's very neat and you can glance at all the necessary data quickly and efficiently. But then there would be lots of guys asking what everything means, which may turn away some people. So a switch button seems ideal, or text explanation underneath just like in Lizzie?

Nice idea, since that way you can satisfy both one-screeners and two-screeners. and B%/W% format can maybe be satisfied with one extra column to the table on the last screenshot? Just an idea...

Can I suggest a tiny-small-little change? I originally suggested a yellow bar somewhere in this thread, but as I'm a nightly owl, I usually have f.lux turned on all the time, and have problem seeing the yellow_bar. I myself can change it in dual_view.py (to something like this color #F39C12 for example), but maybe some people would like a darker color instead and don't know how to do it.

Great work as always, thx!

Yes please! This affects me as well.

Really liking that new UI, can't wait!

Quick question and my apologies if it's been asked before: I'm noticing that GRP with Leela is using what I would consider a low number of playouts for each of the top recommended moves in a 19x19 game:



I've seen that number go as high as 15K but most are around 5K. I could very well be mistaken, but aren't they supposed to be around 100K; or is that for all variations combined? The settings I used to run the SGF analysis are below for reference.



Thanks,


sleepy

_________________
Playing since: March 2018
The road of life is rocky, and you may stumble too. So while you point your finger, someone else is judging you. --Bob Marley

I actually think this BAT file idea would allow me to do some really fun stuff. I'd be really interested to use GRP this way.

However, so far I'm getting errors when I try to run at the command line:

The stats about my sgf file give me hope that the script is basically finding the file and starting to work, but then the sgf path seems to be cut down to one character long and GRP fails to find it the second time?
Could you offer any advice?

My bad, 2 days ago, I made a modification in order to be able to resume an interrupted analysis (or perform a new analysis pass on a subset of moves), it's working well with the GUI, but did not try it with the command line, I guess that's the reason for the issue. I will fix that today.

_________________
I am the author of GoReviewPartner, a small software aimed at assisting reviewing a game of Go. Give it a try!

I just fixed it, please have a try.

For now, the feature to stop/resume the analysis is not available in batch mode.

_________________
I am the author of GoReviewPartner, a small software aimed at assisting reviewing a game of Go. Give it a try!

This is working wonderfully, and I'm having fun with it!

Also really like the new review gui. Thank you for all your hard work.

I've been really enjoying using GRP in a slightly alternative way to look at what AI thinks about popular human moves.

It's no good looking at a move in just one circumstance as bots are really good at whole board thinking and game management so the choice of moves might be based on the specific circumstances. Automating GRP on the command line has helped me to review a large set of human pro games and pick out the moves I'm interested in to see what the bot thinks in each case.

A really usefull feature for this has been the ability to use GRP at the command line with a line like this:


The range parameter allows me to specify a range of moves for GRP to analyse, or in my case one specific move. Using this I can:

• Use Smart go for windows to patern search for the move I'm interested in in the gogod database and export a list of all the relevant games and the move numbers where the patern search finds it's match
• Make a little script to turn this list into a list of command line statements like the one above (I actually just used excell this time)
• Put these statements in a .bat file and run. GRP runs through each game skipping straing to the interesting move.
• Check out what the bot thinks without having to wait at each move! I also found r2sgf.py useful to convert to sgf so that I could quickly check through the games in SmartGo.

Not really the core intended use for GRP but I'm finding it really useful. Maybe other's can find interesting things with these great tools?

Too complex for me at the moment but very impressive innovation in the use of an already great tool!

_________________
Dave Sigaty
"Short-lived are both the praiser and the praised, and rememberer and the remembered..."
- Marcus Aurelius; Meditations, VIII 21

Hi pnprog,

I've also been using GRP in a non-intended way, to analyse games for bot-similarity and how many and how large mistakes the players make. Basically what I want is how much winrate vs bot's #1 move does the played human move lose (or rarely gain). At the moment this is a bit of a pain to get as:
- #1 you need to go 1-by-1 through each move, transcribing to your spreadsheet
- #2 you need to scroll down the textbox to see the win probabilities (I see you've addressed this in dev version)

This info is basically the raw data behind the win rate delta graph, so if you could somehow dump out the data for the whole game as text/file somewhere that'd be super useful, e.g. a CSV (I added a few bonus columns) like


Thanks.

(I have just realised that using absolute loss of percentage winrate is not such a good idea for measuring size of mistake : if you are 50% and drop 1% to 49%, that's not such a bad mistake as being at 15% and dropping to 14%, better to say the former is 1/50 = 2% relative loss of winrate and later is 1/15 = 7% loss of relative winrate).

Edit:
<mod>
I moved the posts about winrate deltas etc to a new thread so we don't distract from Go Review Partner too much.
</mod>

I would also like to acknowledge that the author of GRP has been working on providing me exactly what uberdude asked for, a parser from rsgf to csv files that suits my type of analysis. Just today I am going to try out a hopefully final version of it that should speed up an analysis of the games. My view also is that regardless of the outcome of any current analysis we really need to develop methods and software to check if someone used an AI help or not. I am afraid we will face much more of "using AI accusations" in the future, even in regular games not played on internet. So, I really appreciate pnprog's help and work.

Hi Uberdude,

As AlesCieply mentioned above, yes I can certainly do that

One question: What is "Bot Choice"? Is that the rank of the player's move among all Leela's proposed moves?

Also, I need to clarify the methodology for calculating the winning probability for the move played by the player.
Let's take an example:Here, because J3 is part of Leela's best moves, then we could consider that the win rate for the move played by the player is 47.5%, but maybe it is not the best idea.

Another example:Now, K4 is not part of Leela's best moves, so how to evaluate K4 win rate? GRP solves this issue by having Leela play K4, then asking Leela for white next best move. If Leela says that white next best move is N3 with a 61.1% win rate for white, then GRP deduces that the win rate for black K4 was 38.9% (100% - 61.1%).

In fact, even if the player's move was part of Leela's best move, I use the opposite probability of the next move to estimate the player's move win rate. It allows Leela to use all her thinking time/power on the player move this way, not only a fraction of her playout, so the win rate is more accurate.

To continue with the example above: So here, the player's move and Leela best moves are the same. So delta will be 0

But if I now ask Leela for the best answer to black 17 at D15, maybe I will get:Here we can see that Leela's best answer is D15/45.7% which indicates that now, Leela re-evaluated black 17 at D15 at a win rate of 54.3% (100% - 45.7%) instead of the former estimation of 54.1%
This is because for this turn, all Leela's thinking power was focused on the continuation after black 17 at D15, so this new evaluation should be more accurate.

Because Leela's best move and the player best move are the same, then the delta is zero regardless of the probability, so I won't impact the histogram. But I just wanted to make the methodology clear.

The CSV can also incorporate both winrate values, it's not an issue.

One last precision, GRP does not rank Leela's moves based on probabilities, the moves have the same ranks as provided by Leela. So low ranked moves could have higher win rate than Leela's top move. The alphabetical order used by GRP truly reflects Leela's best moves order. I guess we are all ok with that?

_________________
I am the author of GoReviewPartner, a small software aimed at assisting reviewing a game of Go. Give it a try!