It is currently Wed Oct 28, 2020 2:33 am

All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 189 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10  Next
Author Message
Offline
 Post subject: Re: New android app "BadukAI"
Post #141 Posted: Wed Oct 14, 2020 8:11 am 
Lives in gote
User avatar

Posts: 537
Liked others: 106
Was liked: 79
no comment (after 323 moves, sgf https://lifein19x19.com/viewtopic.php?p=260473#p260473)


Attachments:
g170e 10 block d204M.jpg
g170e 10 block d204M.jpg [ 208.06 KiB | Viewed 649 times ]
Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #142 Posted: Wed Oct 14, 2020 9:17 am 
Lives in gote
User avatar

Posts: 537
Liked others: 106
Was liked: 79
lightvector
why is g170e 10 block d204M estimate so different?

Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #143 Posted: Wed Oct 14, 2020 12:25 pm 
Dies in gote

Posts: 48
Liked others: 11
Was liked: 60
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.


This post by akigo was liked by 3 people: Amigo, And, go4thewin
Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #144 Posted: Wed Oct 14, 2020 10:03 pm 
Lives in gote
User avatar

Posts: 537
Liked others: 106
Was liked: 79
@akigo
many thanks!!! :D
what size of the cache can I set? min and max? and what does it affect? value in mb?

Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #145 Posted: Wed Oct 14, 2020 10:13 pm 
Lives in gote
User avatar

Posts: 537
Liked others: 106
Was liked: 79
unfortunately bug (https://lifein19x19.com/viewtopic.php?p=260107#p260107) remained :sad: (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


Attachments:
AQ-267.jpg
AQ-267.jpg [ 95.53 KiB | Viewed 542 times ]
AQ-267 1.jpg
AQ-267 1.jpg [ 27.84 KiB | Viewed 542 times ]
Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #146 Posted: Thu Oct 15, 2020 3:56 am 
Lives in gote
User avatar

Posts: 537
Liked others: 106
Was liked: 79
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?


Attachments:
kg 10b.sgf [849 Bytes]
Downloaded 4 times
20201015-130458-DA9D4815.LOG.GZ [28.92 KiB]
Downloaded 4 times
kg 10b.jpg
kg 10b.jpg [ 137.29 KiB | Viewed 531 times ]
Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #147 Posted: Thu Oct 15, 2020 8:34 am 
Lives in gote

Posts: 567
Liked others: 90
Was liked: 623
Rank: maybe 2d
And wrote:
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.


This post by lightvector was liked by: And
Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #148 Posted: Thu Oct 15, 2020 12:20 pm 
Dies in gote

Posts: 48
Liked others: 11
Was liked: 60
@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.


This post by akigo was liked by: And
Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #149 Posted: Thu Oct 15, 2020 2:59 pm 
Dies with sente

Posts: 75
Liked others: 105
Was liked: 20
Rank: 25 kyu
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

Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #150 Posted: Thu Oct 15, 2020 4:53 pm 
Lives in gote

Posts: 567
Liked others: 90
Was liked: 623
Rank: maybe 2d
akigo wrote:
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.


This post by lightvector was liked by: akigo
Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #151 Posted: Thu Oct 15, 2020 5:04 pm 
Lives in gote

Posts: 567
Liked others: 90
Was liked: 623
Rank: maybe 2d
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.


This post by lightvector was liked by 3 people: akigo, And, go4thewin
Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #152 Posted: Fri Oct 16, 2020 2:11 am 
Lives in gote
User avatar

Posts: 537
Liked others: 106
Was liked: 79
@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! :)


Attachments:
bug.jpg
bug.jpg [ 82.09 KiB | Viewed 404 times ]
Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #153 Posted: Fri Oct 16, 2020 3:17 pm 
Dies in gote

Posts: 48
Liked others: 11
Was liked: 60
@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.

Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #154 Posted: Fri Oct 16, 2020 3:23 pm 
Dies in gote

Posts: 48
Liked others: 11
Was liked: 60
@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 ...


This post by akigo was liked by: And
Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #155 Posted: Fri Oct 16, 2020 6:34 pm 
Lives in gote

Posts: 567
Liked others: 90
Was liked: 623
Rank: maybe 2d
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. :blackeye:. 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.

Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #156 Posted: Sat Oct 17, 2020 11:35 am 
Dies in gote

Posts: 48
Liked others: 11
Was liked: 60
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 ...


This post by akigo was liked by 2 people: Amigo, And
Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #157 Posted: Sat Oct 17, 2020 12:09 pm 
Lives in gote
User avatar

Posts: 537
Liked others: 106
Was liked: 79
@akigo
I am very grateful to you! as soon as I get to the tablet, I'll check it and write! thanks!!! :D

Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #158 Posted: Sun Oct 18, 2020 1:10 am 
Lives in gote
User avatar

Posts: 537
Liked others: 106
Was liked: 79
@akigo
everything is good! the bug is gone! :D
thank you very much!!!

Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #159 Posted: Sun Oct 18, 2020 1:36 am 
Lives in gote
User avatar

Posts: 537
Liked others: 106
Was liked: 79
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

Top
 Profile  
 
Offline
 Post subject: Re: New android app "BadukAI"
Post #160 Posted: Sun Oct 18, 2020 4:42 am 
Lives in gote
User avatar

Posts: 537
Liked others: 106
Was liked: 79
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)


Attachments:
10b.sgf [1.97 KiB]
Downloaded 3 times
20201018-125331-34319C2C.LOG.GZ [69.82 KiB]
Downloaded 3 times
freeze.jpg
freeze.jpg [ 169.07 KiB | Viewed 176 times ]
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 189 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10  Next

All times are UTC - 8 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group