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
https://lifein19x19.com/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.

it seems strange to me that
1 thinks for black (played only for white)
2 button "play b" is not highlighted
3 made one move back, although it does not respond to buttons other than "save"
I agree, it's not that important. only information

how does "back to main" work? if it doesn't work, can a "new game" be made instead? (with y/n)
perhaps "menu" - "edit config" - "save" is not clear to everyone

@And

"back to main" only does anything if you loaded an sgf. Then it works as follows:

If you make some "manual" moves (either by playing yourself or by letting the AI play), you quit the main line of the sgf. If you then tap "back to main", you get back to the position where you left off the main line of the sgf.

The intended use is for analysis. You load a game that you want to analyze, then you explore alternative moves in a critical situation, then you want to get back to the main line of the sgf to step forward to the next interesting situation. That's what the button is for.

There are two "more obvious" ways to start a new game:
1) Tap on the first segment of the histogram. Then BadukAI goes back to the starting position (empty board).
2) Restart the whole app.

But the way you use (edit config, save) is the best one as it is faster than (2) and cleaner than (1), since the AI engine is restarted.

@akigo

Thanks! I have information about problems again
1 KG plays as black, suddenly the winrate for white turns on, and it is wrong (screenshot kg & lz)
2 LZ plays as white, at the end of the game, the winrate suddenly shows a win? (screenshot kg & lz 1)
3 KG is does again suicidal moves. even 1 stone (275, 277). Chinese rules?
4 KG after saving sgf (screenshot kg & lz 2)

I hope the information is helpful. and thank you very much again!

sgf and log, for some reason there is no LZ log
KG 10 block, playouts 50, LZ 15 block, playouts 20 (~time parity)

I made a new version (0.12).

It should fix the bug that occasionally led to the problems that @And described in posts 146 and 169 (thanks for reporting this).

Moreover, as @Amigo missed a score estimate during play, there is now a numerical display of current winrate and score-lead during play below the winrate histogram (if "winrate on play" is ticked in settings).

Excellent work, Andreas! It is so awesome to have this working on my android e-reader and play against the computer in my spare time

I have a feature request whenever you get around to it: Currently, if the app crashes or is closed by Android OS to free up resources, the current game and some of the settings (e.g.: Input Offset, kyu-rank) get reset. It would be good if BadukAI saved the state of the game and settings after each move, and reloaded them on startup (or asked on startup if they should be reloaded).

Thanks again for the awesome app
- Dmitriy

I made another small update (0.13) in which I improved the board graphics (at least in my opinion).

@akigo

thank you very much!
I loaded the sgf (posts 169, 170) into Sabaki and did the analysis with the 10b network. winrate is almost the same as LZ showed. that is, KataGo:
1 lost a game that have already won!
2 not LZ, but KataGo was showing the wrong winrate at the end of the game.
could this be due to a winrate inversion bug? and you may have seen it, then I should not worry?

version 0.12, KataGo again frozen at the end of the game, this time no reaction at all

it can be assumed based on the results of the match on the computer for example LZ 15b 20pl - KG 10b 50pl 100 games, what will be a similar result on the tablet? that is, are there factors that can affect the game - memory speed, processor ...? and the program code is different. or with the same playout value, should the results be similar? (with enough games)

Yes indeed, this is a consequence of the winrate inversion bug. Due to the bug, the stones, that KG saw, were different from the stones visible on the screen. So it showed the wrong winrate and made moves that were good on the board he saw, but terrible on the board visible on screen. So KG lost an already won game.
And yes, you shouldn't worry, since this bug should not occur anymore from version 0.12 onwards.


The freezing at the end of the game is a completely different problem which I can't reproduce and therefore not address.
The game in the log already has 471 moves, perhaps this is simply too much for one of the programs involved (memory issues). KG already passed at move 313, so I assume that game could have been safely stopped there.
Keep in mind that LZ in BadukAI is configured to never resign (otherwise even low handicap games against LZ would be problematic), so it will continue to play until the board is full. So I strongly recommend to stop games involving LZ manually when everything is decided.


I would assume the results to be similar. With fixed playouts the HW of the tablet should only affect the time needed.

@akigo

Many thanks for the detailed answer! and again for your excellent work !!!
... but suicidal moves?

Suicidal moves were also a consequence of the winrate inversion bug: KG saw a different board and on this board his moves were not suicidal.

So suicidal moves should also be gone from version 0.12 onwards.

@akigo

it's just fantastic! I'm so happy!