Life In 19x19

go4thewin wrote:Thanks so much. It is a very lightweight app now for me when i change the cache size box value to 1. Also the fixed playouts and randomizing the first moves for leela really helps playability for me. Setting to one playout and passing the first move for black to give komi and first move to white gives a really great experience. What a wonderful app. At low fixed playouts (<10), does eliminating the cache affect the strength of the katago? I dont notice any speed problems at low playouts, I dont notice any strength difference either but not sure. Really perfect app for me

There should not be a significant effect on strength, cache mostly only affects performance. It will also mostly only matter for deeper searches - one of the functions of the cache is to reduce the computation when multiple branches of the search result in the same board position, but that typically requires at least two branches of the search that are each a minimum of 4 playouts each (bA wB bC wD vs bC wD bA wB), so will never happen for super-shallow searches. The other function is to speed things up if you go back and repeat the analysis of earlier positions when reviewing a game - if some of it is cached, it won't have to re-do the work it did earlier.

That said, there is really no reason to go all the way to 1. That's kind of silly. Try like 10 or something at least (2^10 = 1024). Each one uses about 3kb if ownership is on, so 10 will use up to 3mb, which shouldn't be much at all.

@akigo

Thank you very much!
sorry, I was in a hurry and did not write that the bug also manifests itself when saving and changing the network. but opening edit config works without problems! there was never a failure! maybe if you make the window smaller (for loading, saving and changing the network move the upper border of the window by 10 percent? or how for edit config?) will it be all right? could you do a test release? please!

@lightvector

Thank you very much for looking into that.

The scenario I described was just a straightforward possibility how a winrate "inversion" could happen (it came to my mind immediately because LeelaZero sometimes exhibited that behaviour after the command lz-genmove_analyze).

After you posted that this can never happen with KataGo, I checked @And's attached files for additional clues and found out that KataGo was told to make a move for white three times in a row (the middle one was attributed to black so the winrate display was "inverted"). That's also the reason for white's winrate suddenly climbing to nearly 100%.

So clearly an error of my UI (unfortunately not reproducible, might be caused by the freeze that @And observed).

Sorry for suspecting KataGo.

@And

I found the reason for the black bar remaining after the file dialogs. So I am optimistic that I can work around it with the next version ...

akigo wrote:@lightvector

Thank you very much for looking into that.

The scenario I described was just a straightforward possibility how a winrate "inversion" could happen (it came to my mind immediately because LeelaZero sometimes exhibited that behaviour after the command lz-genmove_analyze).

After you posted that this can never happen with KataGo, I checked @And's attached files for additional clues and found out that KataGo was told to make a move for white three times in a row (the middle one was attributed to black so the winrate display was "inverted"). That's also the reason for white's winrate suddenly climbing to nearly 100%.

So clearly an error of my UI (unfortunately not reproducible, might be caused by the freeze that @And observed).

Sorry for suspecting KataGo.

Well, it would be far from the first time that someone's reported a bug with KataGo or other things I've written. . I don't mind, I just pay close attention when anyone mentions stuff like this because if it's real, then I get to fix it and make it better. Thank you too for investigating more.

I made a new version (0.11).

It includes a potential fix for the winrate "inversion" problem from @And's post (not sure because I could not reproduce it). Furthermore it addresses the problem of the status bar popping up when opening file dialogs (which might later lead to a black bar remaining). This should now happen only on first access of a file dialog after app installation and then never again.

@And
At least that's the way it worked on my phone. Please try it ...

@akigo
I am very grateful to you! as soon as I get to the tablet, I'll check it and write! thanks!!!

@akigo
everything is good! the bug is gone!
thank you very much!!!

Mobile Linpack 1.4

emulator nox
threads:2 max:9.33 mflop/sec, threads:1 max:7.78 mflop/sec

tablet
threads:4 ~70 mflop/sec, threads:1 ~50 mflop/sec

but the tablet works with BadukAI 2 times slower!

the built-in tool is more suitable for assessing performance.
network 10b, 60 sec, analyse all, and see how many visits

I have:
emulator nox 2 threads ~350
tablet 4 threads ~180

when repeated, the results differ only slightly. but you need to do a reset - edit config, save

@akigo, @go4thewin, @Vargo wondering what results you have

freezes again at the end of the game
g170 10 block d67M, playouts 100, threads 2, resignThreshold -0.999
waited a few minutes, only reacts "save" (does not bother, informing)

akigo wrote:@Amigo

I am not sure that I understand correctly what you mean by "territory counting".

If you want to count the territory in a position in BadukAI where the game is (practically) finished, you can just tap "ponder". KataGo will show the best moves on the board and below the histogram. Each move will contain the winrate and the estimated score. When game is (practically) finished, this "estimate" will be the exact score (i.e. territory difference + stone difference + komi). If you want to get territory difference alone, you can subtract prisoner difference and komi.

If you want to count the territory in a position you encounter outside of BadukAI, just load the sgf into BadukAI and do the same. If you don't have an sgf file describing the position, you can take a photo or screenshot of it and use my app ImgToSgf to create an sgf from the image.

If you had something else in mind, please tell me ...

I mean, for example, like it is in the Crazy Stone, how it counts and shows the territory when the game is not finished and when it is finished. maybe there is a similar ready-made tool to add.

and thank you very much for the new versions! the wonderful program keeps getting better and better!

@And,

on my device (Snapdragon 855+) with 4 threads I get:

9100 with cache size parameter = 1
13600 with cache size parameter = 10
29200 with cache size parameter = 20 (default)

So cache size matters a lot here (in the beginning, positions repeat often due to symmetry). Make sure that cache size is equal when comparing your devices.

Another important point is the following:
Raw mflops/sec are not the only decisive HW factor. The speed in accessing the data for the calculations is also very important. So the RAM speed and the size of the cpu cache matter a lot. And in this regard the tablet is probably much weaker than the pc that the emulator runs on.

addition to
viewtopic.php?p=260671#p260671
I doubted yesterday whether to post it, but I decided that maybe it will tell you the reason for the hangup.
I minimized the BadukAI to copy the log, and when I expanded it was this - screenshot.
instead of "KG is generating w move" it became "KG is generating b move". the application is still frozen, and as if the red arrow is out of place. I compared the log, it remained unchanged.

@And

Thanks for the additional information. In the second screenshot BadukAI obviously went one move back, but this seems to have been a regular operation, since all is consistent: the red arrow is one segment before the last one, the position on the board is the one from the next to last move, there is a "next move"-marker in the correct place and it shows "black to play" (this is also the reason for the different status message). So I think that during minimization/expansion BadukAI somehow registered a click on the "back"-button or the histogram to induce a regular "one move back"-operation.

So we are back to the original problem: Why is there no response to the last move request for white in the log ? It can't be any special property of the current position, since I loaded the sgf and went to the end several times and I always got a next move from katago.

I am sorry, but without being able to reproduce the problem, I can't do anything here. But as it only happens when game is practically finished, this shouldn't matter too much.