Diagram Symbols -- A Nitpick

[mw42]

Something that has bothered me for a while is why the symbols used for go diagrams are what they are. For me, at least, they are not easy to remember, and I will usually have to check to make sure I used the correct character. I understand that L19x19 may have had no choice in the symbols used and might be unable, unwilling or deem it unwise to change them. However, I still thought I'd give my suggestion on how the symbols should be selected.

First, for a black or white stone just use B or W. Then reserve the next 4 consecutive upper-case letters for marked stones (easy to remember). That would be C, D, E and F for marked black stones and X, Y, Z and A for marked white stones. The order for the markups should be circle, cross, triangle and square which is ordered by the number of strokes needed to draw them (again, easy to remember). Last, reserve S for a square on an empty intersection and T for a triangle on an empty intersection. Unfortunately C and X are already reserved and cannot be used for circle and cross, but, hey, O looks a lot like a circle and P follows O just like cross follows circle, so use O for circle and P for cross (easy to remember, too!).

So, to restate the proposed scheme:

B - W -
C - X - O -
D - Y - P -
E - Z - T -
F - A - S -

Thanks for reading.

[jts]

One problem is that even if our beloved admins implemented this change, it would beak all the existing diagrams, no?

[Kirby]

I could make this change if enough people agree with it. As jts said, it might be a hassle to replace all of the existing diagrams, but it can be done.

However, it stands to note that, if we do make such a change, we will no longer be compatible with the senseis library diagrams, since those diagrams use the same symbols that are currently being used.

Alternatively, I could make new tags in addition to the go tags that are the same as go tags, but take the proposed symbols as input.

What do people think about this?

[Joaz Banbeck]

Due to the legacy issue, I vote for leaving it as is. Besides, I'm just getting used to it.

[hyperpape]

I don't care what there is, but I'd benefit from a link from the reply page to diagram instructions. Whatever you implement, I'll just keep looking up the codes.

[xed_over]

'X' and 'O' are standard ASCII representation for playing go on the console -- like playing GnuGo on the commandline, or IGS via telnet

Please do not change the way forum diagrams are represented. These are already standard.

[HermanHiddema]

Changing this would be a ridiculously bad idea.

[ez4u]

Basically we would all like to think that our 'improvements' will seem just as logical and "really cool" to everyone else, as they do to us. Needless to say the average run-of-the-mill idiot that populates the world at large never seems to agree. In this case, I am afraid that I am classed with the idiots. After ten years of diagram building on SL, I am pretty used to the existing codes and too lazy to want to change. Also breaking the ability to cut and paste from my beloved kombilo would break my old heart. Hence, no thumbs up for this puppy.

[tj86430]

I see no reason to change the current symbols.

However, would it be a big task to create another tag which used the proposed new set of symbols?

[mw42]

The response is what I expected -- I don't disagree with the sentiments expressed, either. I don't really think a new tag should be added because (a) it won't be used or (b) it'll frustrate users wanting to copy/paste diagrams to other places.

I'm just glad I finally vented this because every time I go to make a diagram I think "why..."

Thanks, Kirby, for offering to make a change.

[Li Kao]

IMO your suggestion doesn't even address the main problems of the diagram format: They only support a small subset of labels. In particular only lower case letters and 10 different numbers. I considered adding a diagram export to my go program, but this lack of generality was very off-putting.

[Dusk Eagle]

I agree with mw42 that the symbols used for Go diagrams are rather confusing - if I'm using anything other than X, O, B, or W, I have to look it up. However, I think changing things now would have too many negative effects. It would be nice if there was an easy way to access a diagram legend, but that seems like a lot of work. Maybe what you can do if you really want is create a legend to place on your desk or a nearby wall, which you can then reference as needed. It would be convenient and double as a Go decoration.

[HermanHiddema]

I agree with mw42 that the symbols used for Go diagrams are rather confusing - if I'm using anything other than X, O, B, or W, I have to look it up. However, I think changing things now would have too many negative effects. It would be nice if there was an easy way to access a diagram legend, but that seems like a lot of work. Maybe what you can do if you really want is create a legend to place on your desk or a nearby wall, which you can then reference as needed. It would be convenient and double as a Go decoration.

http://senseis.xmp.net/?HowDiagramsWork

As a quick guide:

B and W, short for Black and White, are stones with circles on them. @ and # are stones with squares.

O is an empty white stone, so the next two letters, P and Q, are white stones with markers. Similarly, X is a black stone, so the next two letters, Y and Z, are black stones with markers.

Empty markers are mostly logical: C = Circle, S = Square, T = Triangle, M = Mulitplication sign (cross).

[gaius]

I agree with most of the posters here. But I just thought up one change that COULD be made without losing backwards compatibility: enable move numbering up to 99! This would be useful in diagrammes, no? All that has to be done is replace the space to the right of the move number. For example, a random opening could look like this:

Code: Select all

$$ ---------------------------------------
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . 10. . . |
$$ | . . . . . . . . . . 12. . 8 . . 11. . |
$$ | . . . 2 . . . . . , . . . . . 1 . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . 9 . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . , . . . . . , . . . . . , . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . 13. . . |
$$ | . . . 6 . . . . 17. . . . . . . . . . |
$$ | . . 4 , 15. . . . , . . . . . 3 . . . |
$$ | . . . 145 . . . 7 . . . . . . . . . . |
$$ | . . . 16. . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ ---------------------------------------

Granted, it will look a bit messy for contact fights, but those who don't like it need not use it. Sensei's library diagrammes can still be converted to here, and existing diagrammes are not broken.

I, for one, would like this

[HermanHiddema]

I agree with most of the posters here. But I just thought up one change that COULD be made without losing backwards compatibility: enable move numbering up to 99! This would be useful in diagrammes, no? All that has to be done is replace the space to the right of the move number. For example, a random opening could look like this:

Code: Select all

$$ ---------------------------------------
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . 10. . . |
$$ | . . . . . . . . . . 12. . 8 . . 11. . |
$$ | . . . 2 . . . . . , . . . . . 1 . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . 9 . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . , . . . . . , . . . . . , . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . 13. . . |
$$ | . . . 6 . . . . 17. . . . . . . . . . |
$$ | . . 4 , 15. . . . , . . . . . 3 . . . |
$$ | . . . 145 . . . 7 . . . . . . . . . . |
$$ | . . . 16. . . . . . . . . . . . . . . |
$$ | . . . . . . . . . . . . . . . . . . . |
$$ ---------------------------------------

Granted, it will look a bit messy for contact fights, but those who don't like it need not use it. Sensei's library diagrammes can still be converted to here, and existing diagrammes are not broken.

I, for one, would like this

The basic premise of SLTXT2PNG, which both Sensei's Library and L19 use, is one character per intersection. Spaces are optional. So this works fine:

Code: Select all

$$W
$$+------
$$|......
$$|...90.
$$|..12..
$$|..3X..
$$|.54...
$$|.76...
$$|..8...

to make this:

$$W
$$+------
$$|......
$$|...90.
$$|..12..
$$|..3X..
$$|.54...
$$|.76...
$$|..8...

Click Here To Show Diagram Code

[go]$$W
$$+------
$$|......
$$|...90.
$$|..12..
$$|..3X..
$$|.54...
$$|.76...
$$|..8...[/go]

So yes, you are breaking backwards compatibility.

Letting go of this convention is asking for trouble, IMO, because it can become confusing which space belongs to which intersection and which numbers belong together. And if someone does it wrong it will often not be obvious from the result why.

If you want to allow higher numbers, other labels, etc. then at the very least you should make sure that everything is space separated, e.g:

Code: Select all

$$ .  .  .  .
$$ . 13  .  .
$$ .  .  .  .
$$ .  . 14  .
$$ .  .  .  .

But really, at some point, if you want more power, why not just plug some SGF between sgf tags? I don't think diagrams with 100 moves in them are clear anymore. At some point around maybe 15-20 moves at most, a single diagram loses its communicative ability.

What I would really like is if L19 allowed tables, the way SL does. Having the option to put a series of diagrams next to each other, instead of under each other, is quite powerful. It is much more compact, and allows the reader to see all the diagrams in one screen.

For an example, see: http://senseis.xmp.net/?HermanHiddema%2 ... arAnalysis