It is currently Thu Mar 28, 2024 1:46 pm

All times are UTC - 8 hours [ DST ]




Post new topic Reply to topic  [ 4 posts ] 
Author Message
Offline
 Post subject: More questions about supporting Daoqi in KataGo
Post #1 Posted: Fri Jun 17, 2022 6:53 am 
Dies in gote

Posts: 25
Liked others: 0
Was liked: 2
Rank: AGA 6D
I've been training Daoqi model from my KataGo fork/branch. It seems working fine. However I noticed a few issues:

In some games, I noticed suicide moves are generated in some games. multiStoneSuicideLegals is set to "false,true". Not sure what that means but I suppose it won't allow suicide. Could this be an issue or this is normal?

In the middle of some games, pass is generated. Is this result of training? Can it be prevented?

In some games, some stones are added to the board and they are not handicapes. Is this normal?

Can I tweak or change the config file or the model kind and re-run the command to continue? Will there be a compatibility issue with the generated model etc? Which options can be changed and which can not?

Other than what I have done with wrapping around the board, what else should be modified (that is not applicable to Daoqi because of the board difference). It seems there is special logic for mirroring, center of the board etc. I feel they should be handled differently but haven't looked closely yet.

The training plateaued before reaching D level (the new model loses or wins in a small margin, e.g. 50~60% win rate against the old model). What can I do when it plateaued?

References

An introduction to toroidal Go: http://goplayerjuggler.blogspot.com/201 ... al-go.html
My KataGo branch for Daoqi: https://github.com/gcao/KataGo/tree/cao/daoqi
My PR for Daoqi: https://github.com/gcao/KataGo/pull/6/files
My training command: python/selfplay/synchronous_loop.sh DAOQI ../daoqi-opencl daoqi b20c256 1
My self play config: https://github.com/gcao/KataGo/blob/cao ... fplay1.cfg
Model kind used in the training: b20c256

Top
 Profile  
 
Offline
 Post subject: Re: More questions about supporting Daoqi in KataGo
Post #2 Posted: Tue Jun 21, 2022 12:41 am 
Beginner

Posts: 5
Liked others: 4
Was liked: 0
Rank: OGS 6 kyu
It's definitely a big idea.

I will recommend you to ask the issue on disord or github, there will be more lively.

And I wanna to play 19^2 Daoqi with 29^2 KataGo, it is just a primary mathematics conversion, but it not starts yet.

Top
 Profile  
 
Offline
 Post subject: Re: More questions about supporting Daoqi in KataGo
Post #3 Posted: Tue Jun 21, 2022 7:11 am 
Dies in gote

Posts: 25
Liked others: 0
Was liked: 2
Rank: AGA 6D
Yes I posted it on Discord and got it answered. I included the responses below for reference:

cmf — 06/17/2022
Quote:
multiStoneSuicideLegals is set to "false,true", I think this means half games will allow suicide, half won't. If you don't want suicide to be allowed, you should just set it to false.


lightvector — 06/17/2022
Quote:
* Yes, cmf is right

* Pass is just a move like any other move like C3, so you can't prevent it any more than you can prevent a move like C3. For most of the game, passing is a very bad move though, so it should be learned quickly that it's a bad move, so either your net hasn't trained enough or somewhere you have a bug (bad neural net implementation, bad training data, etc).

* Non-handicap stones are normal. Some rules have free placement, so it's good to learn how to handle extra black stones that aren't on the star points.

* You can change almost anything you want, you just have to deal with the consequences. Sometimes it's easy, if you change # of visits or search parameters or rules, then only thing that happens is that you generate new data with the new parameters. Of course, the neural net may or may not work well at first with the new parameters, for example if it's never seen certain rules before and then you suddenly add them.
Sometimes it's hard. If you change the size of the tensors in the npz data that are written, then you will have a mix of different tensor sizes, and that will cause the shuffle script to fail when it tries to make batches, so then you would need to manually pad the data files to make the tensor sizes match.
If you change the TRANINGNAME you can start training a new net with a new name on the data you already have and if you like you can make it a new MODELKIND to change the size of the net, but it will be starting from scratch, so it will generate very weak data when it gets used for selfplay next. So probably you will want to manually run the training scripts and shuffle scripts as necessary to train it enough on the existing data until it catches up in its policy and value loss stats, then resume the full loop as normal.
* The mirroring code is not used during training, so for training it doesn't matter, but yes you should disable it and other code you find that is similar. I haven't thought about what you need to change, you'll have to use your best judgment.
* When something plateaus and is very weak compared to what you would expect, then you probably have a bug and you should extensively verify and test every step on its own to find the bug. If it plateaus but is strong and working properly, then you would try lowering the learning rate, or increasing the search parameters, or using a bigger model.


lightvector — 06/17/2022
Quote:
-----------------
By the way, skimming your code, I can already see a possible bug - unless you train exclusively on a single board size, and you make sure all your tensors exactly match the board size, otherwise your openCL code is buggy because the xSize and ySize there are not the same as the board size. The xSize and ySize there are the tensor size, and these can differ. For example if you train on board sizes 7-19, then all board sizes 7-19 will get mixed into the same batch, even though the tensor size will always be 19.

Also I'm not 100% sure that your code in the winograd unTransform is correct even if you ignore the above problem, I think applying any torus condition there at all could be bad.

I would recommend you do some detailed testing of every part of your code one at a time - make sure move legality and liberty counts and so on are always correct even when wrapping around the board. Make sure the neural net produces identical output except for tiny floating point differences between Tensorflow and OpenCL on several different board positions. Make sure the data is getting written out the way you expect. Etc, etc.

Top
 Profile  
 
Offline
 Post subject: Re: More questions about supporting Daoqi in KataGo
Post #4 Posted: Tue Jun 21, 2022 7:31 am 
Dies in gote

Posts: 25
Liked others: 0
Was liked: 2
Rank: AGA 6D
I'm still in the process of figuring out what changes I need to make in order to get all pieces (self play, training, gtp etc) to work for Daoqi. It'll take some time. Any suggestions or help will be greatly appreciated.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

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