Working with SGFs (as a rote beginner programmer)

[Loons]

I recently did Introduction to Computer Science 1 at my local university, which left me both phenomenally bored and very cursorily able to program (read: google stack overflow pages) in C#.

So I thought without any real context I would write a program that reads and manipulates SGFs as a fun (personal) exercise. I have no real context for doing that, or experience.

Thus far I am reading and splitting SGFs with an eye to extracting coordinates. You would burst into tears if you saw my code that turns letters into numbers (I have an array of letters and some wierd tangle of linq).

The real question: Can anyone divine a mistake I am probably making, missing, or going to make?

(I found http://www.red-bean.com/sgf/user_guide/index.html as a reference but have yet to really look at it)

[EdLee]

Can anyone divine a mistake I am probably making, missing, or going to make?

Loons, Congrats! A very good idea and a fun exercise!
I'm sure you'll enjoy the process a lot. What environment are you using ? Which compiler and debugger ?

[Loons]

Microsoft Visual C# 2010, that answers all the questions right? It's the one my uni used, I should probably update to 2012 but I'm not under the impression that's urgent.

I mean, what's my other option? Mono?

[EdLee]

What's Mono ?

[Loons]

Not something I was taught about, we stuck strictly to using MS Visual C# 2010. Mono is a C# compiler? http://www.mono-project.com/

Edit: Not, as you may have thought American shorthand for glandular fever

[EdLee]

Thanks. Found these under the mono link.

Reversi.png (11.62 KiB) Viewed 10230 times

702px-Screenshot-SharpChess.png (118.26 KiB) Viewed 10230 times

[moyoaji]

The questions you run in to will depend on what the program is going to do. If you simply want to edit SGF files by entering coordinates and whatnot the program could be pretty simple. If you want to make something like CGoBan it will be very complex. Thankfully, the SGF format is pretty simple.

As for your ugly arrays, a trick in most programming languages is to write something like this:

Code: Select all

int number = (int) (letter - 'a');

This would covert 'a' into 0, 'b' into 1, etc. I believe this is how it works in C#, but my exposure to that language is minimal. My main experience is with Java, C, and Python.

In ASCII, lowercase a is assigned the value of 97. It may be different depending on the language you are working with, but 9 times out of 10 the characters use ASCII values and you can do mathematical operations with characters like you would integers because, behind the scenes, they really are integers.

Do you have anything specific you are trying to accomplish?

[Loons]

I'd really like to implement some pattern searching. One of my goals is mostly to keep my hand in the game - in January I'm doing Introduction to Computer Science II (where they will reveal to us that classes exist).

[moyoaji]

Pattern searching, eh?

Very interesting idea. So you would look for, say, empty triangles? Or specific joseki? That seems like it would be a fun project for C#. Without using object oriented programming, though, this will be quite hard.

My thought would be that you would want to create a Board class that defines the board and rules of game states (you really just need to make sure it deal with captures). Populate the board with the moves as the game is played and then you can either scan the board with each move or fully play the game out and then look for patterns afterwards.

If you do this the OO (object oriented) way then you would want a "Pattern" interface of some type. Something that defines what makes up a pattern. Making the pattern visible from all 4 angles could be solved the easy way (by scanning the board 4 times for the 4 different angles) but I'm sure you can come up with something more creative and efficient than that.

Without classes and objects, though, that would be challenging. This is really a job for OO programming, and C# can be OO, but if you don't use classes this may be a challenge. Even so, this can be done procedurally.

An empty triangle, for example, is two stones horizontally adjacent that has one allied stone directly adjacent vertically. So you could find two stones next to each other and check the 4 positions above and below to see if you find a friendly stone. Then, you check the position next to the found friendly stone to see if the triangle is empty or if the player was simply bending around a stone. Easy enough, but then you have to do that for every kind of pattern.

With OO, however, you could have an EmptyTriangle class that has this definition built in specific pattern. And you'd have a BambooJoint class and a TableShape class and all of these would just be definitions. But then you write one function that can take a Pattern object and it will search for it no matter how complex the pattern is. That is the power of object oriented programming.

[leichtloeslich]

A large part of good programming isn't actually programming, it's good planning.

I'd really like to implement some pattern searching.

Well, you don't need a full fledged sgf-parser for that. You can discard anything but the move-tree, basically. Anyway, you should still have a look at the "For developers" section in http://www.red-bean.com/sgf/.

My idea for the project would be
* create a class/program that reads the game-positions occurring in sgf-files into a database.

Two game-positions should be considered equal if they result from one another by rotational or reflection-symmetry or by switching colors. Also I would disregard prisoners and ko bans.
Each game-position in the database should have associated to it a list of references to the sgf-files it occurs in (also at what move, although that may not be completely well-defined if you're dealing with variations in sgf-files).

And then as a second step
* create a pattern matcher for game-positions

Again, patterns should be considered equal up to rotational/reflectional symmetry and color switching.

In particular, you can do these two parts of your project independent from one another. As a last step, you could create a nifty GUI so users can create patterns in a graphical manner, as opposed to supplying them as a text-file or something like that.

edit: actually, since there's an obvious overlap between the two steps (the symmetry thing) you could first do the pattern matcher and then use that in the database creation to identify "equal" game-positions by comparing the game-position against itself interpreted as a pattern.
I hope I'm making sense here. The main point: you don't want to duplicate that symmetry code.

[Mike Novack]

A large part of good programming isn't actually programming, it's good planning.

If you want some advice from somebody now retired from decades in the cypher mines.

a) Forget about what language you are using to make the program real. Design your program at the abstract level.

b) A large part of "good" will be learning how to divide up the problem (the abstract problem) at the right places. If you pick the right places to "divide and conquer" the problem you will discover:
1) You can devise testing to make sure the pieces all work more easily and any bugs will be more isolated.
2) You will discover over time that there are fewer (different) problems than you thought and so "done that before, know how, even have bits and pieces in my personal library I can reuse.

c) For practical (once on the floor) defer decisions as long as possible and keep flexible (easy to change) anything that the clients might possibly change. Constant data need not be "compiled" in but read in by the program once it starts (I don't mean "constants of Nature" which can't change but constants of user definition).

d) Always visualize how you will test any bit of code as you design it. If one way of writing the code is easier to test than another, do it that way (becomes automatic with experience). Designing/writing test drivers that can verify parts of your program are correct are not a waste of time. They usually save time.

[RBerenguel]

[...]
Without using object oriented programming, though, this will be quite hard.
[...]

I don't really get this comment. Object oriented programming is just a paradigm that makes some things easier, usually for some largish-scale codebases, not for all. People have been programming without OO for a lot of time, and some languages don't even have the concept of object and work perfectly fine for many projects and many lines of code.

If I were to write this in a language without OO (which are the languages I usually use, let's say C to pick the barest thing) I'd write functions which act on a struct which will be the board (what OO would probably call methods) and work from there.

[HermanHiddema]

When parsing properties, it can be tricky to find the closing bracket when considering escape characters.

According to the spec (http://www.red-bean.com/sgf/sgf4.html#text):
Any char following "\" is inserted verbatim

Does your code handle the following C (comment) tags correctly?

C[hi]

C[herman\[4d\]: hi]

C[herman\[4d\]: hi \\]

The first is straightforward.

The second has escaped brackets. Some incorrect parsers will thick the comment was "herman\[4d\" and stop at the closing bracket after the rank. This happens if you do not consider escaping and just go looking for the next "]" from the opening "["

The third is tricky, because some parsers solve the second issue by skipping any closing bracket that is preceded by a backslash, thinking that that means it was escaped. But in this comment, the escaped character is a backslash, and the closing bracket is directly after that, so it is not escaped.

I've written a basic SGF parser myself (in Python, but most of it is quite readable) which you can find at: https://github.com/HermanHiddema/sgfpar ... 0.1/SGF.py

[hyperpape]

You should certainly plan, but since you have just finished your first course, bear in mind that your plan is going to be the equivalent of a 20 kyu making plans in the opening--they won't have much relation to reality. No amount of upfront work is going to make your plans correspond to the actual issues your program will have to solve when you're as inexperienced as you are.

That's ok! Planning is still worthwhile, because it'll let you think about the problem without getting hung up on the implementation details and any issues with the programming language. It's just that you'll find holes in your plan and have to go back to the drawing board. Then you'll figure out which parts of your code are still useful, and which get thrown out.

[RBerenguel]

C[herman\[4d\]: hi \\]
The third is tricky, because some parsers solve the second issue by skipping any closing bracket that is preceded by a backslash, thinking that that means it was escaped. But in this comment, the escaped character is a backslash, and the closing bracket is directly after that, so it is not escaped.

A similar kind of problem I think appears in the life of every programmer: semi-parsing stuff worrying about closing tags. So, detecting everything inside a <p> until the "equivalent" instance of </p> appears for example. The first time I coded something for this (it was a funky C parser I wrote partially in C and partially in Lex and I used it to generate "visual code patterns" I could visually scan to detect code cheating in an assignment) I just used addition: every time you see a <p> after the first one, add 1. Every time you see </p> substract 1. Once you get to 0 you are done. There are better ways to do it if you are interested in the real structure of the document, but if you just want to know the content this is as easy as it gets.

In this comment parsing it's (somewhat) easier: each \ escapes the next character (UTF8 may hurt here, but anyway) so the idea would be to pick (in "regular expression syntax") \\(.) and write instead &1, i.e. whatever is after the slash when parsing the comment. Once there are no slashes left, any closing bracket closes the comment. Now should come the plan to implement this (and worse, in an efficient way if it has to run with many files.)