New android app "BadukAI"

[And]

with the g170 10 block d67M network
Why is the g170e 10 block d204M estimate around -90, and the other networks around -190?

[go4thewin]

the other networks think the bottom group is dead but why

[And]

the other networks think the bottom group is dead but why

Do you think that it is not g170e 10 block d204M that is wrong, but other networks?

[go4thewin]

yeah it seems to me the other networks are wrong and bottom group is alive.
edit: sorry i have roughly 68 for white 22 seki and 270 for black, so -212, you are right

[And]

the other networks think the bottom group is dead but why

I don't understand where this conclusion comes from

[And]

no comment (after 323 moves, sgf viewtopic.php?p=260473#p260473)

[And]

lightvector
why is g170e 10 block d204M estimate so different?

[akigo]

I made a new version (0.10). Now LeelaZero also has a configuration dialog which (among others) includes the parameter to randomize some moves from the beginning. The configuration dialog of KataGo was enhanced by cache size and resign parameters.

[And]

@akigo
many thanks!!!
what size of the cache can I set? min and max? and what does it affect? value in mb?

[And]

unfortunately bug (viewtopic.php?p=260107#p260107) remained (in all versions). sometimes it is impossible to load the sgf, you have to restart the application. after opening the loading window, the board in the background jumps down (always!), then back, but sometimes does not snap into place. as if the application is "inconvenient" on the screen. can I do any tests to find the cause? this bug is only on the tablet, everything is fine on the emulator. if I minimize the application on the emulator, and then expand it, then everything is as it was. but on the tablet for some reason the application restarts

EDIT maybe to use third-party tools for downloading? such as in AQ?
then, for example, you can use the file manager or total commander

[And]

10 block, playouts 100, threads 2, resignThreshold -0.999. plays white
after move 97 freezes for a few seconds, then shows the winrate, as if playing black, and then it is completely incomprehensible! look at the winrate - it should be the other way around!
is this possible due to the "wrong" network?

[lightvector]

lightvector
why is g170e 10 block d204M estimate so different?

Probably just random chance. It's very rare that the networks will see such an extremely lopsided position because it doesn't happen much in high-level play, so they don't have a lot of training for it.

You can think of it like the network just not bothering to actually count - when you're ahead by this crazy amount you don't care what the exact score is, you're just ahead by "a lot" and the network just makes up a random big number that means "a lot". Different networks randomly giving different answers is not surprising.

[akigo]

@And

1) Cache
The number you enter in the config dialog is the power of 2 for the cache size, for example:
you enter 1 (smallest possible value): cache size = 2^1 = 2 positions
you enter 20 (default value): cache size = 2^20 = 1048576 positions

I don't know how many bytes a position needs, but this doesn't really matter, as you have to tune the cache size for your tablet experimentally anyway.

I would suggest that you start by entering 1 to see if the memory problems disappear with practically no cache at all. If this happens, you can then increase the number until you get memory problems again and then choose the number below that.

2) Loading sgf
You can already load an sgf file by a 3rd party file explorer: Just open a file picker app, select the sgf file, choose "Open in" or "Share" and select "BadukAI" as target. Then BadukAI will pop up with the sgf loaded (does not matter if it was running before or not).

3) Winrate display
When KataGo is asked to generate a move, it sends two kinds of messages
a) analysis messages (including the winrate)
b) the move message
The winrate is always for the player to move.

According to KataGo's GTP extensions, it always sends several messages of type (a), then one message of type (b). Then everything works fine.

I suspect, that in this special moment (due to the hickup you observed) a message of type (a) was sent (or received) after the message of type (b). Since the message of type (b) was consumed first, it was already black's move when the trailing message of type (a) was interpreted. So the high winrate was attributed to the wrong side.

This should be a very rare exception (I never had this on my test device). Nevertheless I will check if I can enhance the code to detect such kind of disorder and react accordingly.

[go4thewin]

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

[lightvector]

According to KataGo's GTP extensions, it always sends several messages of type (a), then one message of type (b). Then everything works fine.

I suspect, that in this special moment (due to the hickup you observed) a message of type (a) was sent (or received) after the message of type (b). Since the message of type (b) was consumed first, it was already black's move when the trailing message of type (a) was interpreted. So the high winrate was attributed to the wrong side.

This should be a very rare exception (I never had this on my test device). Nevertheless I will check if I can enhance the code to detect such kind of disorder and react accordingly.

I don't actually see currently in the code how it could happen - the code is written with the intent that this should never be the case - the thread that loops and produces this callback is terminated and explicitly waited on (thread.join) by the code that proceeds to conclude the response to the gtp command. It's possible there is a sneaky bug in that code, but I currently don't see it.

Are you using 'kata-analyze' followed by 'play' in that situation or are you using 'genmove-analyze' in that situation? And do you always wait for the double newline that signals the end of the gtp response? Keep in mind that gtp input and output can be arbitrary out of order - you are free to tell KataGo to 'play' a move in the middle of while it's doing a 'kata-analyze' or some other thing, and even send multiple other commands - making the input far ahead of the output. And you are free to make your GUI update its own state far ahead of where KataGo's output has caught up to at that point, if your GUI is capable of handling the asynchronousness, but the output should still process commands in the order received, outputting the normal '=' and double-newline for each one, as it catches up.

If you can give me a log where the output happens out of order where I can see the sequence of commands that triggered it, then I can try to dig into it using that command sequence as a guide.