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)

_________________
Revisiting Go - Study Journal
My Programming Blog - About the evolution of my go bot.

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 ?

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?

_________________
Revisiting Go - Study Journal
My Programming Blog - About the evolution of my go bot.

What's Mono ?

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

_________________
Revisiting Go - Study Journal
My Programming Blog - About the evolution of my go bot.

Thanks. Found these under the mono link.

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:



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?

_________________
"You have to walk before you can run. Black 1 was a walking move.
I blushed inwardly to recall the ignorant thoughts that had gone through
my mind before, when I had not realized the true worth of Black 1."
-Kageyama Toshiro on proper moves

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).

_________________
Revisiting Go - Study Journal
My Programming Blog - About the evolution of my go bot.

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.

_________________
"You have to walk before you can run. Black 1 was a walking move.
I blushed inwardly to recall the ignorant thoughts that had gone through
my mind before, when I had not realized the true worth of Black 1."
-Kageyama Toshiro on proper moves

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


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.

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.

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.

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

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

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.

_________________
Occupy Babel!

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.)

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

Yes, in temporary code this kind of quick and dirty solution is good enough. The "proper" alternative in your example would entail a full-fledged HTML parser.

Quick and dirty for the escaping issue I mentioned would probably be to count the number of contiguous backslashes preceding the "]" character. If it is odd, the bracket is escaped.

The regular expression I use in my code for this is: (?:\\.|[^\\\]])+\]

UTF8, or more to the point, character encodings in general, can be a huge pita. SGF allows you to define the character encoding with the CA tag. My parser makes the assumption (I know, I know) that property values cannot contain a "]" equivalent byte as part of some funky unicode codepoint, which is true for UTF8 and common latin/windows encodings (but might be false for e.g. UTF-16 or BIG5).

But anyway, at Loons' level we're just talking gibberish now

It's the best way to learn: what's this gibberish they are talking about? Let's see... (never, ever try to read the UTF8 or any other encoding reference, unless forced to do so.)

Also, I don't get the (? part: what's the conditional about? The parenthesis? Lately my regex abilities (which have never been that much) have been severely crippled by writing more or less concurrently emacs lisp style regex, Go regexes and PHP regexes (the three have different rules for some sets of extended operators!) so anything ever so slightly fancy doesn't ring any bell any more...

_________________
Geek of all trades, master of none: the motto for my blog mostlymaths.net

(?: starts a non-capturing group. You can leave out the ?: and it'll work just as well, except afterwards you would be able to reference the part between the parenthesis separately. Since I only need the full match, I used a non-capturing group.

So the expression is:

(...)+\] Match at least one occurrence, and as many as possible, of the sub-expression between the parentheses, followed by a closing bracket.

And the sub-expression has two options:

[^\\\]] any single character that is not backslash or closing bracket
\\. any pair of characters where the first is a backslash

Planning is good, and so is research. I would find what other sgf parsers are out there, and also what kind of data structures people have divined for storing the moves, and see if any of those help you out conceptually, if not with actual code. I also suspect that C# may not be the best language for this particular application, since I haven't seen many Go programs in C#, which is more commercially oriented, so you may not have much help from the open source community, though you should be able to read the code without much problem. I have seen python(Kombillo) and C/C++ (Gnu go, Kombillo query engine) and I know there are java programs out there like KGS.

I know you can do this without OO. I even said that later in my post. However, creating a collection of patterns for the program to search could be more tedious without using objects. The problem is not working with the board, the problem is adding new patterns to your collection that can be searched.

It would take more time to write a function that takes a pattern object and figures out how to use that pattern than it would to just tell the program how to scan for one particular pattern. This is true. But once the function is written you can add new patterns in a fraction of the time it would take. Without having the luxury of creating a pattern object that conforms to an interface that can be understood by your function you'll need to program how to search for each pattern.

I learned to code in Java, which tries to force you to do things with object orientation. When I work in C I do sometimes miss the ability to create objects to work with. A struct can do some of what I would want an object to do in this case, but it would be easier (in my mind) to use objects. I'm not saying I couldn't figure out a way to define patterns with a struct, but I can't see how it would be faster than setting up a pattern interface and then making objects that conform to it.

There is nothing wrong with procedural programming, but for a project like this I think an object oriented approach would be easier. There are times when being object oriented just slows you down, but, depending on how many patterns, and different types of patterns, are going to be searched, I think OO would be nicer.

_________________
"You have to walk before you can run. Black 1 was a walking move.
I blushed inwardly to recall the ignorant thoughts that had gone through
my mind before, when I had not realized the true worth of Black 1."
-Kageyama Toshiro on proper moves