Opencv 3 for me

   Embarrassingly my python install, conda and all had caught fire and collapsed for unknown reasons (this not happening being the whole point of conda).

   So I have splashed out into Python 3.4.3 and opencv 3.0.0. I held off on Python 3.5.0 for now. I was looking at cv2.filter2D(...) (why is opencv 3 still being called cv2) which broadly does what it should (for large kernels it does the convolution with the discrete Fourier transform).

   Also I started using vim again, and discovered that it has tabs now! It is my favourite IDE again.

   A page from an odd cookbook, filtered arbitrarily by directionally maximising green channel contrast. It looks artistic. I have written so many pictureless words that any excuse for an image has to do.

Language choice

   At some point I entered a chrysalis then emerged a proper python programmer (at which point a lecturer called me on just being trendy).

   Now for my various (non-go) projects my current language choices are python/numpy etc, python/opencv3 and C/cuda. Obviously these three are somewhat interrelated with slightly differing emphases:

• Numpy (pronounced numpy to enrage other python programmers) is the natural evolution from Matlab (vis all the "numpy for Matlab users" cheatsheets)
• OpenCV 3 is a holistic and self contained (computer vision) package, where python is an incidental alternative to C++.
• Cuda says I moreso want to actually control (worry about) my utilisation of graphics processing. I count putting some more mileage into C++ a bonus.

   Numpy and cv3 both have robust gpu functions (probably cuda derived) and are highlevel and syntactically sweet. Conversely one can cobble code from existing cuda quite easily.

Go bot though?

   I have been mainly hacking away with Numpy and friends, so that's my goto for the go bot, who shall consist of :

1. Joseki dictionary bot
• Dictionary Joseki deviation punishment bot
2. Dictionary advised non-dictionary joseki deviation punishment bot
3. MCTS bot (hopefully the board has closed up lowering computation cost).

What about making another SGF editor?

   Seems like I could do it in python (python gui toolkits are a thing)

Addendum

   Before falling asleep I thought I would jot more thoughts.

   Some major behind-the-scenes problems are that I am storing joseki as 10-by-10 tiles, just because that is slightly more natural for me to think about. Which is a problem, because joseki are being played on a 19-by-19 board. Actually the joseki are one dimensional lines of numbers, but those are somewhat more confusing.

   I told it to pretend a same-color stone on some rotation or reflection of C7 : C10 was more or less one of the other stones. In the name of half-asleep ad hoc solutions being an approach to doing programming. It panics if it sees a wrong-color extension and is embarrassing for everyone involved.

Just joseki bot

   I just glued several simple joseki from The 21st Century Dictionary of Basic Joseki by Takao Shinji to a bot and asked it to play them. Which it does!

   You might notice that it refuses to deviate from its chosen joseki in a given corner, and once it has no choice but for one color to deviate from the script it just stops.

   But this is the idea I decided to start on : A bot that plays joseki if at all possible (so as to avoid expensive, original analysis), then once the board closes up plays single moves.

   Mid-game joseki would need to be included.

   The next step for the bot is to tell it that it is okay to have stones from other corners intrude on other corners' joseki. I think a rule of thumb saying "just; no contact moves" would be a good measure.

   Another issue is that not all moves are equally sente. While bots boldly tenuki-ing is somewhat infamous, not connecting a peep is a crime.

   I have been playing around with bots on KGS (Hirabot 1d, Ayabot 2d). They stick pretty rigidly to their opening patterns. I wonder if they are remembering games that they won to conserve time for their Monte-Carlo methods. Or just following some heuristics or an opening dictionary. My approach will be just joseki to begin.

Thinking about Monte Carlo playouts

   Finished my homework panic (for this particular half of this particular half of this particular week).

   Now I am reflecting on what a Monte Carlo play-out should consist of. At the moment, each empty spot on the board that isn't a living one space eye gets a number, and then those get played out until a capture happens, at which point everyone gets a new random number. Obviously there's some extraneous work being done there.

   One optimization would be instead of redoing the whole board after a capture, simply inserting new legal moves after a capture at random locations would avoid some work.

   Another would be playing known-to-be-non-capturing moves before a capture simultaneously.

   This is somewhat motivated by Hirabot 1d 19x19 repeatedly smashing me on KGS. Also, 15,000 play-outs in under thirty seconds?! In contrast, Ayabots 1k - 1d only do 1500 play-outs and are clearly over-ranked. So my bot needs to be doing 2-3 orders of magnitude more play-outs in only 30 seconds.

Otherwise, I am doing something (at school) with Geant4. I wonder if Geant4 has something to offer my Matlab go evaluation (because mex is so dependable).

Busy studying today

   I only did the first Google Code Jam problem, too. At some point I got fed up with remembering Java syntax, which in hindsight required more preparation. Next year, Python, surely.

   This weekend is dedicated to schoolwork.

   A scintillator like potassium iodide crystals will somewhat get you visible light from higher energy gamma rays, which is easier to find. My use of the term 'x-rays' might be erroneous.

Reading SGFs too

(I'm on holiday)

   Irritatingly, the move numbers I am using are MATLAB figure text. If I 'print the figure to a file', all the text becomes my current font color. If I write the board image as an image, I lose the text. I will argue that I wanted the gif to be small and in that case the numbers don't make sense. 

   The game is Rin Kaiho vs Fujisawa Hideyuki 1982.