dkappe wrote: ↑Sat Nov 09, 2019 7:11 pmThanks for this. Will see if I can provide comments and something interesting.
Thank you for your interest! I don't think I would have published this had not several people repeatedly asked me to. The interest in Winter has generally been very motivating and makes me very happy.
Daniel Shawul wrote: ↑Sat Nov 09, 2019 7:15 pmWhere can i download your network?
https://github.com/rosenthj/Winter/blob ... _weights.h
Daniel Shawul wrote: ↑Sat Nov 09, 2019 7:15 pmIf it just weights that you have, could you produce a frozen tensorflow protobuf graph (pb), or
since you are using keras the HDF5 graph works too.
Unfortunately I don't have the weights in a clean format. This is a side effect from a rather rapid internal development. I don't really expect to need old nets as when I change the input features, old nets become obsolete. Furthermore I have all the old nets in a format that Winter understands, as the net is hardcoded...
Rather high up on my list of priorities is to add saving the netweights in an open format in my training script. If the nets get much larger then I think it makes sense to have the nets be loaded externally. Especially as I would eventually like to support networks from other engines in the long run.
Daniel Shawul wrote: ↑Sat Nov 09, 2019 7:15 pmI should be able to use it in Scorpio after that once I figure out your input and outputs. I want to see how it does against my 2x32 net.
I am also quite curious, unfortunately it isn't that simple for now. Winter's NN is a set of handcrafted features fed into a regular fully connected NN and not a CNN. This is a design choice as I don't have access to a GPU so I am trying to keep things very small. Winters net is currently #inputs x 16 x 16 x 2. #inputs is roughly 500 for the purpose of the training dataset, but in practise it is much smaller as most features are sparse. I think in practise it is more like 30x16x16x2.
I will likely add support for CNNs soon, as I have some ideas in that regard. Support for GPUs on the other hand is not really on the horizon, as I don't have access to a GPU and I am unsure if GPU makes sense without a codebase that supports batching. Perhaps I will make a zombified experimental Winter, taking GPU based code from Leela and seeing if I can run it on google colab or something of the sort, but I am skeptical about that being anything more than a very experimental branch until I have a GPU and time. So maybe 5 years from now? (*cries in PhD student).
Daniel Shawul wrote: ↑Sat Nov 09, 2019 7:15 pmI started out with a no-policy net too but figured later most of the knowledge is packed in the policy network. The implicit policy was a qsearch() over all the moves.
I very much agree that policy is an extremely important strength of NN based engines. I would go as far as to argue NN engines greatest strengths are policy and pawn structure evaluation. Unfortunately policy is also something which is inherently heavyweight. I am hoping that by having my network be very lightweight I can fully utilize classical heuristics such as history heuristics. Since I am doing a pure AB search I only need the ordering of moves and not the actual move priors. I want to try using NN for move ordering and at higher depth nodes I want to try a policy network.
Something that I think could be very good is having heuristics such as move history be an input for a policy network. Due to the fact that NN based engines are mostly MCTS based, I don't think anyone has tried this yet, but I believe such dynamic heuristics are very powerful. I think having a NN interpret them and be able to put moves in context to one another is potentially an extremely powerful mechanic.