https://www.hexwiki.net/api.php?action=feedcontributions&feedformat=atom&user=ArekKulczyckiHexWiki - User contributions [en]2026-05-13T07:00:27ZUser contributionsMediaWiki 1.23.15https://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T19:43:19Z<p>ArekKulczycki: /* Proposition */</p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''Problem 1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''Problem 2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''Problem 3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''Problem 3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional symbol to understand where the measurements is made from)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take to figure out what move this is? Probably even more challenging is to read a sequence (11x11):<br />
<br />
<code>2'3</code>, <code>45'</code>, <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>, <code>55</code><br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too :)) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. So the same "idea" does '''not''' mean the same "move" in terms of coordinates.)<br />
<br />
If this is how I "find" my moves, why not base the coordinates off the same idea? That seems sensible, when I read a coordinate I will just mentally do what I always do: count steps from the corner and stop at the given distance. Let's see if this approach can solve the problems listed in the earlier paragraph.<br />
<br />
'''Problem 1)''' Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
'''Problem 2)''' The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only, but a primary and secondary number, such that their order has no ambiguity. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
'''Problem 3)''' Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions: may "miss the target" (not be connected by a ladder/bridge) or may "fall into" the edge too centrish by a ladder/bridge. This feature I define as '''offset''' and elaborate on this in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
'''Problem 3')''' Relation between 2 moves.<br />
<br />
This is difficult in each of the systems I've seen. The benefit of the corner-related approach is that, in a sequence of moves, we should see from the annotations if they refer to the same corner and therefore produce a '''joseki''' structure. If a move annotation refers to a different corner than the previous one that indicates a '''tenuki'''.<br />
<br />
With a smart interpretation maybe it's possible to also get a correct intuition for reading '''joseki''' sequences, I will investigate that in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Joseki Joseki paragraph].<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on the earlier reasoning, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or, including color, <code>R<4+1</code><br />
* B:= <code>(4</code> or, including color, <code>B(4</code><br />
* C:= <code>)5</code> or, including color, <code>R)5</code><br />
* D:= <code>>5+1</code> or, including color, <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
And the same sequence as above (11x11):<br />
<br />
<code><2-1</code>, <code>>5+1</code>, <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-2</code>, <code>(5</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
1) for white player, from second coordinate (X) subtract the first (Y)<br />
<br />
2) for black player, from first coordinate (Y) subtract the second (X)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
The color of the stone naturally requires annotation in both systems, hence we had to assume one.<br />
<br />
== Offset ==<br />
The move offset has a strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the '''convex/concave''' moves for short.<br />
<br />
== Joseki ==<br />
How to read joseki sequences? To be investigated...</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T19:43:08Z<p>ArekKulczycki: /* Proposition */</p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''Problem 1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''Problem 2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''Problem 3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''Problem 3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional symbol to understand where the measurements is made from)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take to figure out what move this is? Probably even more challenging is to read a sequence (11x11):<br />
<br />
<code>2'3</code>, <code>45'</code>, <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>, <code>55</code><br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too :)) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. So the same "idea" does '''not''' mean the same "move" in terms of coordinates.)<br />
<br />
If this is how I "find" my moves, why not base the coordinates off the same idea? That seems sensible, when I read a coordinate I will just mentally do what I always do: count steps from the corner and stop at the given distance. Let's see if this approach can solve the problems listed in the earlier paragraph.<br />
<br />
'''Problem 1)''' Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
'''Problem 2)''' The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only, but a primary and secondary number, such that their order has no ambiguity. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
'''Problem 3)''' Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions: may "miss the target" (not be connected by a ladder/bridge) or may "fall into" the edge too centrish by a ladder/bridge. This feature I define as '''offset''' and elaborate on this in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
'''Problem 3')''' Relation between 2 moves.<br />
<br />
This is difficult in each of the systems I've seen. The benefit of the corner-related approach is that, in a sequence of moves, we should see from the annotations if they refer to the same corner and therefore produce a '''joseki''' structure. If a move annotation refers to a different corner than the previous one that indicates a '''tenuki'''.<br />
<br />
With a smart interpretation maybe it's possible to also get a correct intuition for reading '''joseki''' sequences, I will investigate that in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Joseki Joseki paragraph].<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on the reasoning above, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or, including color, <code>R<4+1</code><br />
* B:= <code>(4</code> or, including color, <code>B(4</code><br />
* C:= <code>)5</code> or, including color, <code>R)5</code><br />
* D:= <code>>5+1</code> or, including color, <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
And the same sequence as above (11x11):<br />
<br />
<code><2-1</code>, <code>>5+1</code>, <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-2</code>, <code>(5</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
1) for white player, from second coordinate (X) subtract the first (Y)<br />
<br />
2) for black player, from first coordinate (Y) subtract the second (X)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
The color of the stone naturally requires annotation in both systems, hence we had to assume one.<br />
<br />
== Offset ==<br />
The move offset has a strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the '''convex/concave''' moves for short.<br />
<br />
== Joseki ==<br />
How to read joseki sequences? To be investigated...</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T19:41:23Z<p>ArekKulczycki: /* Offset */</p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''Problem 1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''Problem 2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''Problem 3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''Problem 3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional symbol to understand where the measurements is made from)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take to figure out what move this is? Probably even more challenging is to read a sequence (11x11):<br />
<br />
<code>2'3</code>, <code>45'</code>, <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>, <code>55</code><br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too :)) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. So the same "idea" does '''not''' mean the same "move" in terms of coordinates.)<br />
<br />
If this is how I "find" my moves, why not base the coordinates off the same idea? That seems sensible, when I read a coordinate I will just mentally do what I always do: count steps from the corner and stop at the given distance. Let's see if this approach can solve the problems listed in the earlier paragraph.<br />
<br />
'''Problem 1)''' Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
'''Problem 2)''' The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only, but a primary and secondary number, such that their order has no ambiguity. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
'''Problem 3)''' Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions: may "miss the target" (not be connected by a ladder/bridge) or may "fall into" the edge too centrish by a ladder/bridge. This feature I define as '''offset''' and elaborate on this in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
'''Problem 3')''' Relation between 2 moves.<br />
<br />
This is difficult in each of the systems I've seen. The benefit of the corner-related approach is that, in a sequence of moves, we should see from the annotations if they refer to the same corner and therefore produce a '''joseki''' structure. If a move annotation refers to a different corner than the previous one that indicates a '''tenuki'''.<br />
<br />
With a smart interpretation maybe it's possible to also get a correct intuition for reading '''joseki''' sequences, I will investigate that in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Joseki Joseki paragraph].<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or, including color, <code>R<4+1</code><br />
* B:= <code>(4</code> or, including color, <code>B(4</code><br />
* C:= <code>)5</code> or, including color, <code>R)5</code><br />
* D:= <code>>5+1</code> or, including color, <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
And the same sequence as above (11x11):<br />
<br />
<code><2-1</code>, <code>>5+1</code>, <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-2</code>, <code>(5</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
1) for white player, from second coordinate (X) subtract the first (Y)<br />
<br />
2) for black player, from first coordinate (Y) subtract the second (X)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
The color of the stone naturally requires annotation in both systems, hence we had to assume one.<br />
<br />
== Offset ==<br />
The move offset has a strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the '''convex/concave''' moves for short.<br />
<br />
== Joseki ==<br />
How to read joseki sequences? To be investigated...</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T19:40:13Z<p>ArekKulczycki: /* Offset */</p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''Problem 1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''Problem 2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''Problem 3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''Problem 3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional symbol to understand where the measurements is made from)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take to figure out what move this is? Probably even more challenging is to read a sequence (11x11):<br />
<br />
<code>2'3</code>, <code>45'</code>, <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>, <code>55</code><br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too :)) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. So the same "idea" does '''not''' mean the same "move" in terms of coordinates.)<br />
<br />
If this is how I "find" my moves, why not base the coordinates off the same idea? That seems sensible, when I read a coordinate I will just mentally do what I always do: count steps from the corner and stop at the given distance. Let's see if this approach can solve the problems listed in the earlier paragraph.<br />
<br />
'''Problem 1)''' Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
'''Problem 2)''' The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only, but a primary and secondary number, such that their order has no ambiguity. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
'''Problem 3)''' Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions: may "miss the target" (not be connected by a ladder/bridge) or may "fall into" the edge too centrish by a ladder/bridge. This feature I define as '''offset''' and elaborate on this in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
'''Problem 3')''' Relation between 2 moves.<br />
<br />
This is difficult in each of the systems I've seen. The benefit of the corner-related approach is that, in a sequence of moves, we should see from the annotations if they refer to the same corner and therefore produce a '''joseki''' structure. If a move annotation refers to a different corner than the previous one that indicates a '''tenuki'''.<br />
<br />
With a smart interpretation maybe it's possible to also get a correct intuition for reading '''joseki''' sequences, I will investigate that in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Joseki Joseki paragraph].<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or, including color, <code>R<4+1</code><br />
* B:= <code>(4</code> or, including color, <code>B(4</code><br />
* C:= <code>)5</code> or, including color, <code>R)5</code><br />
* D:= <code>>5+1</code> or, including color, <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
And the same sequence as above (11x11):<br />
<br />
<code><2-1</code>, <code>>5+1</code>, <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-2</code>, <code>(5</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
1) for white player, from second coordinate (X) subtract the first (Y)<br />
<br />
2) for black player, from first coordinate (Y) subtract the second (X)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
The color of the stone naturally requires annotation in both systems, hence we had to assume one.<br />
<br />
== Offset ==<br />
The move offset has a strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
== Joseki ==<br />
How to read joseki sequences? To be investigated...</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T19:38:51Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''Problem 1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''Problem 2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''Problem 3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''Problem 3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional symbol to understand where the measurements is made from)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take to figure out what move this is? Probably even more challenging is to read a sequence (11x11):<br />
<br />
<code>2'3</code>, <code>45'</code>, <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>, <code>55</code><br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too :)) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. So the same "idea" does '''not''' mean the same "move" in terms of coordinates.)<br />
<br />
If this is how I "find" my moves, why not base the coordinates off the same idea? That seems sensible, when I read a coordinate I will just mentally do what I always do: count steps from the corner and stop at the given distance. Let's see if this approach can solve the problems listed in the earlier paragraph.<br />
<br />
'''Problem 1)''' Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
'''Problem 2)''' The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only, but a primary and secondary number, such that their order has no ambiguity. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
'''Problem 3)''' Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions: may "miss the target" (not be connected by a ladder/bridge) or may "fall into" the edge too centrish by a ladder/bridge. This feature I define as '''offset''' and elaborate on this in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
'''Problem 3')''' Relation between 2 moves.<br />
<br />
This is difficult in each of the systems I've seen. The benefit of the corner-related approach is that, in a sequence of moves, we should see from the annotations if they refer to the same corner and therefore produce a '''joseki''' structure. If a move annotation refers to a different corner than the previous one that indicates a '''tenuki'''.<br />
<br />
With a smart interpretation maybe it's possible to also get a correct intuition for reading '''joseki''' sequences, I will investigate that in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Joseki Joseki paragraph].<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or, including color, <code>R<4+1</code><br />
* B:= <code>(4</code> or, including color, <code>B(4</code><br />
* C:= <code>)5</code> or, including color, <code>R)5</code><br />
* D:= <code>>5+1</code> or, including color, <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
And the same sequence as above (11x11):<br />
<br />
<code><2-1</code>, <code>>5+1</code>, <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-2</code>, <code>(5</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
1) for white player, from second coordinate (X) subtract the first (Y)<br />
<br />
2) for black player, from first coordinate (Y) subtract the second (X)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
The color of the stone naturally requires annotation in both systems, hence we had to assume one.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
== Joseki ==<br />
How to read joseki sequences? To be investigated...</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T11:35:28Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''Problem 1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''Problem 2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''Problem 3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''Problem 3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional symbol to understand where the measurements is made from)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take to figure out what move this is? Probably even more challenging is to read a sequence (11x11):<br />
<br />
<code>2'3</code>, <code>45'</code>, <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>, <code>55</code><br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too :)) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. So the same "idea" does '''not''' mean the same "move" in terms of coordinates.)<br />
<br />
If this is how I "find" my moves, why not base the coordinates off the same idea? That seems sensible, when I read a coordinate I will just mentally do what I always do: count steps from the corner and stop at the given distance. Let's see if this approach can solve the problems listed in the earlier paragraph.<br />
<br />
'''Problem 1)''' Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
'''Problem 2)''' The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only, but a primary and secondary number, such that their order has no ambiguity. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
'''Problem 3)''' Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions: may "miss the target" (not be connected by a ladder/bridge) or may "fall into" the edge too centrish by a ladder/bridge. This feature I define as '''offset''' and elaborate on this in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
'''Problem 3')''' Relation between 2 moves.<br />
<br />
This is difficult in each of the systems I've seen. The benefit of the corner-related approach is that, in a sequence of moves, we should see from the annotations if they refer to the same corner and therefore produce a '''joseki''' structure. If a move annotation refers to a different corner than the previous one that indicates a '''tenuki'''.<br />
<br />
With a smart interpretation maybe it's possible to also get a correct intuition for reading '''joseki''' sequences, I will investigate that in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Joseki Joseki paragraph].<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or, including color, <code>R<4+1</code><br />
* B:= <code>(4</code> or, including color, <code>B(4</code><br />
* C:= <code>)5</code> or, including color, <code>R)5</code><br />
* D:= <code>>5+1</code> or, including color, <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
And the same sequence as above (11x11):<br />
<br />
<code><2-1</code>, <code>>5+1</code>, <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-2</code>, <code>(5</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
The color of the stone naturally requires annotation in both systems, hence we had to assume one.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
== Joseki ==<br />
How to read joseki sequences? To be investigated...</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T11:32:24Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''Problem 1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''Problem 2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''Problem 3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''Problem 3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take to figure out what move this is? Probably even more challenging is to read a sequence (11x11):<br />
<br />
<code>2'3</code>, <code>45'</code>, <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>, <code>55</code><br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too :)) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. So the same "idea" does '''not''' mean the same "move" in terms of coordinates.)<br />
<br />
If this is how I "find" my moves, why not base the coordinates off the same idea? That seems sensible, when I read a coordinate I will just mentally do what I always do: count steps from the corner and stop at the given distance. Let's see if this approach can solve the problems listed in the earlier paragraph.<br />
<br />
'''Problem 1)''' Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
'''Problem 2)''' The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only, but a primary and secondary number, such that their order has no ambiguity. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
'''Problem 3)''' Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions: may "miss the target" (not be connected by a ladder/bridge) or may "fall into" the edge too centrish by a ladder/bridge. This feature I define as '''offset''' and elaborate on this in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
'''Problem 3')''' Relation between 2 moves.<br />
<br />
This is difficult in each of the systems I've seen. The benefit of the corner-related approach is that, in a sequence of moves, we should see from the annotations if they refer to the same corner and therefore produce a '''joseki''' structure. If a move annotation refers to a different corner than the previous one that indicates a '''tenuki'''.<br />
<br />
With a smart interpretation maybe it's possible to also get a correct intuition for reading '''joseki''' sequences, I will investigate that in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Joseki Joseki paragraph].<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or, including color, <code>R<4+1</code><br />
* B:= <code>(4</code> or, including color, <code>B(4</code><br />
* C:= <code>)5</code> or, including color, <code>R)5</code><br />
* D:= <code>>5+1</code> or, including color, <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
And the same sequence as above (11x11):<br />
<br />
<code><2-1</code>, <code>>5+1</code>, <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-2</code>, <code>(5</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
The color of the stone naturally requires annotation in both systems, hence we had to assume one.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
== Joseki ==<br />
How to read joseki sequences? To be investigated...</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T11:24:18Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''Problem 1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''Problem 2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''Problem 3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''Problem 3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too :)) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. So the same "idea" does '''not''' mean the same "move" in terms of coordinates.)<br />
<br />
If this is how I "find" my moves, why not base the coordinates off the same idea? That seems sensible, when I read a coordinate I will just mentally do what I always do: count steps from the corner and stop at the given distance. Let's see if this approach can solve the problems listed in the earlier paragraph.<br />
<br />
'''Problem 1)''' Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
'''Problem 2)''' The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only, but a primary and secondary number, such that their order has no ambiguity. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
'''Problem 3)''' Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions: may "miss the target" (not be connected by a ladder/bridge) or may "fall into" the edge too centrish by a ladder/bridge. This feature I define as '''offset''' and elaborate on this in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
'''Problem 3')''' Relation between 2 moves.<br />
<br />
This is difficult in each of the systems I've seen. The benefit of the corner-related approach is that, in a sequence of moves, we should see from the annotations if they refer to the same corner and therefore produce a '''joseki''' structure. If a move annotation refers to a different corner than the previous one that indicates a '''tenuki'''.<br />
<br />
With a smart interpretation maybe it's possible to also get a correct intuition for reading '''joseki''' sequences, I will investigate that in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Joseki Joseki paragraph].<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or, including color, <code>R<4+1</code><br />
* B:= <code>(4</code> or, including color, <code>B(4</code><br />
* C:= <code>)5</code> or, including color, <code>R)5</code><br />
* D:= <code>>5+1</code> or, including color, <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
The color of the stone naturally requires annotation in both systems, hence we had to assume one.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
== Joseki ==<br />
How to read joseki sequences? To be investigated...</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T11:23:13Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''Problem 1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''Problem 2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''Problem 3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''Problem 3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too :)) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. So the same "idea" does '''not''' mean the same "move" in terms of coordinates.)<br />
<br />
If this is how I "find" my moves, why not base the coordinates off the same idea? That seems sensible, when I read a coordinate I will just mentally do what I always do: count steps from the corner and stop at the given distance. Let's see if this approach can solve the problems listed in the earlier paragraph.<br />
<br />
'''Problem 1)''' Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
'''Problem 2)''' The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only, but a primary and secondary number, such that their order has no ambiguity. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
'''Problem 3)''' Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions: may "miss the target" (not be connected by a ladder/bridge) or may "fall into" the edge too centrish by a ladder/bridge. This feature I define as '''offset''' and elaborate on this in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
'''Problem 3')''' Relation between 2 moves.<br />
<br />
This is difficult in each of the systems I've seen. The benefit of the corner-related approach is that, in a sequence of moves, we should see from the annotations if they refer to the same corner and therefore produce a '''joseki''' structure. If a move annotation refers to a different corner than the previous one that indicates a '''tenuki'''.<br />
<br />
With a smart interpretation maybe it's possible to also get a correct intuition for reading '''joseki''' sequences, I will investigate that in the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Joseki Joseki paragraph].<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or, including color, <code>R<4+1</code><br />
* B:= <code>(4</code> or, including color, <code>B(4</code><br />
* C:= <code>)5</code> or, including color, <code>R)5</code><br />
* D:= <code>>5+1</code> or, including color, <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
The color of the stone naturally requires annotation in both systems, hence we had to assume one.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
== Joseki ==<br />
How to read joseki sequences? To be investigated...</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T11:11:11Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''Problem 1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''Problem 2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''Problem 3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''Problem 3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too :)) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. So the same "idea" does '''not''' mean the same "move" in terms of coordinates.)<br />
<br />
If this is how I "find" my moves, why not base the coordinates off the same idea? That seems sensible, when I read a coordinate I will just mentally do what I always do: count steps from the corner and stop at the given distance. Let's see if this approach can solve the problems listed in the earlier paragraph.<br />
<br />
'''Problem 1)''' Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
'''Problem 2)''' The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
'''Problem 3)''' Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
'''Problem 3')''' Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or, including color, <code>R<4+1</code><br />
* B:= <code>(4</code> or, including color, <code>B(4</code><br />
* C:= <code>)5</code> or, including color, <code>R)5</code><br />
* D:= <code>>5+1</code> or, including color, <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
The color of the stone naturally requires annotation in both systems, hence we had to assume one.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T11:10:20Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too :)) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. So the same "idea" does '''not''' mean the same "move" in terms of coordinates.)<br />
<br />
If this is how I "find" my moves, why not base the coordinates off the same idea? That seems sensible, when I read a coordinate I will just mentally do what I always do: count steps from the corner and stop at the given distance. Let's see if this approach can solve the problems listed in the earlier paragraph.<br />
<br />
'''1)''' Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
'''2)''' The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
'''3)''' Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
'''3')''' Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or, including color, <code>R<4+1</code><br />
* B:= <code>(4</code> or, including color, <code>B(4</code><br />
* C:= <code>)5</code> or, including color, <code>R)5</code><br />
* D:= <code>>5+1</code> or, including color, <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
The color of the stone naturally requires annotation in both systems, hence we had to assume one.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T11:01:55Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or, including color, <code>R<4+1</code><br />
* B:= <code>(4</code> or, including color, <code>B(4</code><br />
* C:= <code>)5</code> or, including color, <code>R)5</code><br />
* D:= <code>>5+1</code> or, including color, <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
The color of the stone naturally requires annotation in both systems, hence we had to assume one.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T11:00:30Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or, including color, <code>R<4+1</code><br />
* B:= <code>(4</code> or, including color, <code>B(4</code><br />
* C:= <code>)5</code> or, including color, <code>R)5</code><br />
* D:= <code>>5+1</code> or, including color, <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T11:00:01Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code> or <code>R<4+1</code><br />
* B:= <code>(4</code> or <code>B(4</code><br />
* C:= <code>)5</code> or <code>R)5</code><br />
* D:= <code>>5+1</code> or <code>B>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:58:41Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But precisely what the coordinates are for is being able to talk about moves without seeing the board in front of us! So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:57:42Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
coords="none"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:57:05Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:56:43Z<p>ArekKulczycki: </p>
<hr />
<div>= Corner-Relative Coordinate System =<br />
<br />
== TL/DR ==<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
== Intro ==<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
== Reasoning ==<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
== Proposition ==<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
== Translations ==<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
== Offset ==<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:55:55Z<p>ArekKulczycki: </p>
<hr />
<div>== Corner-Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
==== Challenge ====<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
=== Offset ===<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:55:25Z<p>ArekKulczycki: </p>
<hr />
<div>== Corner-Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
'''1)''' We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
'''2)''' The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
'''3)''' The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
'''3')''' On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
'''a)''' replacing alphabet with numbers<br />
<br />
'''b)''' making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
=== Offset ===<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:54:49Z<p>ArekKulczycki: </p>
<hr />
<div>== Corner-Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
<br />
a) replacing alphabet with numbers<br />
<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
=== Offset ===<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:53:39Z<p>ArekKulczycki: </p>
<hr />
<div>== Corner-Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is. Nevertheless, to conform with various color standards let's use '''b''' for black and '''w''' for white, '''R''' for red and '''B''' for blue.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
'''Example:'''<br />
<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
=== Offset ===<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:51:00Z<p>ArekKulczycki: </p>
<hr />
<div>== Corner-Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to <br />
<br />
'''First''' identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
'''Secondly''', once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
'''And finally''' we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
Example:<br />
<code>4'7</code>, assuming black player,<br />
<br />
First number is prime, so we're talking about top-left corner <, distance is 4, offset is <code>4 - 7 = -3</code>. Annotation: <code><4-3</code>.<br />
<br />
=== Offset ===<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:44:34Z<p>ArekKulczycki: </p>
<hr />
<div>== Corner-Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the entire article. In a nutshell the point is:<br />
* We should talk about the board in '''reference to the corners''', not the edges, for more intuitive navigation. <br />
* Coordinates are easier handled as '''relative''', i.e. subjective to the player: the same cell is annotated differently for each of the 2 players.<br />
<br />
Now go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective. '''Moreover''', each move can be described in as much as in 4 ways, in a frame of reference of each of the corners. Naturally it only makes sense to use the closest one, but moves in center could be understood in multiple ways.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
<br />
1) No prime notation, it's <code>(</code><br />
<br />
2) Both coordinates are prime, it's <code>)</code><br />
<br />
3) First is prime, it's <code><</code><br />
<br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
<br />
1) for white player we take the value of the second coordinate (column)<br />
<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
<br />
0) take absolute coordinates, that is, <code>absolute_value:= board_size - prime_value</code><br />
<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
Example:<br />
<code>4'7</code><br />
<br />
<br />
=== Offset ===<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call '''convex''', maybe popularly known as '''indirect'''. Instead a more '''direct''' shape that pushes through the middle I would call '''concave'''. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:32:24Z<p>ArekKulczycki: </p>
<hr />
<div>== Corner-Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4 B 0:c8 -:c7 -:c6 +:c9 +:c10"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:31:16Z<p>ArekKulczycki: </p>
<hr />
<div>== Corner-Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="10x10"<br />
contents="R 0:c4 +:b4 +:a4 -:d4 -:e4"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:30:25Z<p>ArekKulczycki: </p>
<hr />
<div>== Corner-Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R 0:d5 +:c5 +:b5 -:e5 -:f5"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:30:06Z<p>ArekKulczycki: </p>
<hr />
<div>== Corner-Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R 0:d5 +:c5 +2:b5 1:e5 2:f5"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:29:39Z<p>ArekKulczycki: </p>
<hr />
<div>== Corner-Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R 0:d5 1:c5 2:b5 1:e5 2:f5"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:29:09Z<p>ArekKulczycki: </p>
<hr />
<div>== Corner-Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical strategical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, usually considered suboptimal, but strongly connected.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R 0:d5 1:c5 2:b5 1:e5 2f5"<br />
/><br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:23:50Z<p>ArekKulczycki: </p>
<hr />
<div>== Corner-Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Corner-Relative Coordinates'', if stone color is skipped, can occur twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:22:40Z<p>ArekKulczycki: </p>
<hr />
<div>== Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Relative Coordinates'', if stone color is skipped, can be played twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge. Note that in the context of the long diagonal the distance can equivalently be counted with bridges from the corner cell.<br />
<br />
* The corner. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:18:59Z<p>ArekKulczycki: </p>
<hr />
<div>== Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Relative Coordinates'', if stone color is skipped, can be played twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
I challenge you to imagine the stones based on the notation yet again, same as we did above for another system.<br />
<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try some single stones now:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:17:36Z<p>ArekKulczycki: </p>
<hr />
<div>== Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Exercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Relative Coordinates'', if stone color is skipped, can be played twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
Looking at a 11x11 board, the corners: a1 is <code><1</code>, a11 is <code>(1</code>, k1 is <code>)1</code>, k11 is <code>>1</code>.<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
* A:= <code><4+1</code><br />
* B:= <code>(4</code><br />
* C:= <code>)5</code><br />
* D:= <code>>5+1</code><br />
<br />
==== Exercise again ====<br />
So what we will look at is a symbol, a primary number and a secondary number which can be positive or negative.<br />
<code><4</code><br />
How to read it...<br />
<br />
Let's talk about a 13x13 board again.<br />
Our new a1 is <code><a1</code>, a13 is <code>(1</code>, m1 is <code>)1</code>, m13 is <code>>1</code>.<br />
Now, the acute corners is not exactly where players will aim with bridges, remember? Black wants a stone at a2 (<code><2+1</code>), while white wants it at b1 (<code><2+1</code>). Have you noticed? It is the same notation! Yes, the players put their stones on long diagonal with offset of +1.<br />
<br />
Let's perform the exercise again that we did with another coordinate system.<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try single stones now again:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:11:19Z<p>ArekKulczycki: </p>
<hr />
<div>== Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Excercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Relative Coordinates'', if stone color is skipped, can be played twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
A := <code><4+1</code><br />
<br />
B := <code>(4</code><br />
<br />
C := <code>)5</code><br />
<br />
D := <code>>5+1</code><br />
<br />
=== Decoding ===<br />
So what we will look at is a symbol, a primary number and a secondary number which can be positive or negative.<br />
<code><4</code><br />
How to read it...<br />
<br />
Let's talk about a 13x13 board again.<br />
Our new a1 is <code><a1</code>, a13 is <code>(1</code>, m1 is <code>)1</code>, m13 is <code>>1</code>.<br />
Now, the acute corners is not exactly where players will aim with bridges, remember? Black wants a stone at a2 (<code><2+1</code>), while white wants it at b1 (<code><2+1</code>). Have you noticed? It is the same notation! Yes, the players put their stones on long diagonal with offset of +1.<br />
<br />
Let's perform the exercise again that we did with another coordinate system.<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try single stones now again:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:10:43Z<p>ArekKulczycki: </p>
<hr />
<div>== Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Excercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Relative Coordinates'', if stone color is skipped, can be played twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol <code>)>(<</code>, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
A := <code><4+1</code><br />
<br />
B := <code>(4</code><br />
<br />
C := <code>)5</code><br />
<br />
D := <code>>5+1</code><br />
<br />
=== Decoding ===<br />
So what we will look at is a symbol, a primary number and a secondary number which can be positive or negative.<br />
<code><4</code><br />
How to read it...<br />
<br />
Let's talk about a 13x13 board again.<br />
Our new a1 is <code><a1</code>, a13 is <code>(1</code>, m1 is <code>)1</code>, m13 is <code>>1</code>.<br />
Now, the acute corners is not exactly where players will aim with bridges, remember? Black wants a stone at a2 (<code><2+1</code>), while white wants it at b1 (<code><2+1</code>). Have you noticed? It is the same notation! Yes, the players put their stones on long diagonal with offset of +1.<br />
<br />
Let's perform the exercise again that we did with another coordinate system.<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try single stones now again:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:10:26Z<p>ArekKulczycki: </p>
<hr />
<div>== Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Excercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Relative Coordinates'', if stone color is skipped, can be played twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol <code>)>(<</code>, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
A := <code><4+1</code><br />
B := <code>(4</code><br />
C := <code>)5</code><br />
D := <code>>5+1</code><br />
<br />
=== Decoding ===<br />
So what we will look at is a symbol, a primary number and a secondary number which can be positive or negative.<br />
<code><4</code><br />
How to read it...<br />
<br />
Let's talk about a 13x13 board again.<br />
Our new a1 is <code><a1</code>, a13 is <code>(1</code>, m1 is <code>)1</code>, m13 is <code>>1</code>.<br />
Now, the acute corners is not exactly where players will aim with bridges, remember? Black wants a stone at a2 (<code><2+1</code>), while white wants it at b1 (<code><2+1</code>). Have you noticed? It is the same notation! Yes, the players put their stones on long diagonal with offset of +1.<br />
<br />
Let's perform the exercise again that we did with another coordinate system.<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try single stones now again:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:08:19Z<p>ArekKulczycki: </p>
<hr />
<div>== Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Excercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Relative Coordinates'', if stone color is skipped, can be played twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol <code>)>(<</code>, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R '<4':c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
<br />
=== Decoding ===<br />
So what we will look at is a symbol, a primary number and a secondary number which can be positive or negative.<br />
<code><4</code><br />
How to read it...<br />
<br />
Let's talk about a 13x13 board again.<br />
Our new a1 is <code><a1</code>, a13 is <code>(1</code>, m1 is <code>)1</code>, m13 is <code>>1</code>.<br />
Now, the acute corners is not exactly where players will aim with bridges, remember? Black wants a stone at a2 (<code><2+1</code>), while white wants it at b1 (<code><2+1</code>). Have you noticed? It is the same notation! Yes, the players put their stones on long diagonal with offset of +1.<br />
<br />
Let's perform the exercise again that we did with another coordinate system.<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try single stones now again:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:07:16Z<p>ArekKulczycki: </p>
<hr />
<div>== Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Excercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Relative Coordinates'', if stone color is skipped, can be played twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol <code>)>(<</code>, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R <4:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
<br />
=== Decoding ===<br />
So what we will look at is a symbol, a primary number and a secondary number which can be positive or negative.<br />
<code><4</code><br />
How to read it...<br />
<br />
Let's talk about a 13x13 board again.<br />
Our new a1 is <code><a1</code>, a13 is <code>(1</code>, m1 is <code>)1</code>, m13 is <code>>1</code>.<br />
Now, the acute corners is not exactly where players will aim with bridges, remember? Black wants a stone at a2 (<code><2+1</code>), while white wants it at b1 (<code><2+1</code>). Have you noticed? It is the same notation! Yes, the players put their stones on long diagonal with offset of +1.<br />
<br />
Let's perform the exercise again that we did with another coordinate system.<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try single stones now again:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:06:55Z<p>ArekKulczycki: </p>
<hr />
<div>== Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Excercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Relative Coordinates'', if stone color is skipped, can be played twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol <code>)>(<</code>, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
<hexboard size="11x11"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
<br />
=== Decoding ===<br />
So what we will look at is a symbol, a primary number and a secondary number which can be positive or negative.<br />
<code><4</code><br />
How to read it...<br />
<br />
Let's talk about a 13x13 board again.<br />
Our new a1 is <code><a1</code>, a13 is <code>(1</code>, m1 is <code>)1</code>, m13 is <code>>1</code>.<br />
Now, the acute corners is not exactly where players will aim with bridges, remember? Black wants a stone at a2 (<code><2+1</code>), while white wants it at b1 (<code><2+1</code>). Have you noticed? It is the same notation! Yes, the players put their stones on long diagonal with offset of +1.<br />
<br />
Let's perform the exercise again that we did with another coordinate system.<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try single stones now again:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:06:01Z<p>ArekKulczycki: </p>
<hr />
<div>== Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
<br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
Now Go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Excercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Relative Coordinates'', if stone color is skipped, can be played twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol <code>)>(<</code>, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
<hexboard size="9x9"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
<br />
=== Decoding ===<br />
So what we will look at is a symbol, a primary number and a secondary number which can be positive or negative.<br />
<code><4</code><br />
How to read it...<br />
<br />
Let's talk about a 13x13 board again.<br />
Our new a1 is <code><a1</code>, a13 is <code>(1</code>, m1 is <code>)1</code>, m13 is <code>>1</code>.<br />
Now, the acute corners is not exactly where players will aim with bridges, remember? Black wants a stone at a2 (<code><2+1</code>), while white wants it at b1 (<code><2+1</code>). Have you noticed? It is the same notation! Yes, the players put their stones on long diagonal with offset of +1.<br />
<br />
Let's perform the exercise again that we did with another coordinate system.<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try single stones now again:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-30T10:05:39Z<p>ArekKulczycki: </p>
<hr />
<div>== Relative Coordinate System ==<br />
<br />
=== TL/DR ===<br />
To see my reasons read the article. In a nutshell:<br />
1) We should talk about the board in reference to the corners, not the edges, for more intuitive navigation. <br />
2) Coordinates are easier handled as relative, i.e. subjective to the player, the same board cell in traditional coordinates is expressed by different relative coordinates for each of the 2 players.<br />
3) Coordinate notation should be intuitive, clear, memorable and transferable to another system.<br />
<br />
go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Excercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Disclaimer:<br />
A move annotated with ''Relative Coordinates'', if stone color is skipped, can be played twice in a game, because it means something else for each of the players. Inclusion of stone color is optional, but makes the notation objective.<br />
<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. For simplification, let's count distance in just 1 dimension, such that we define the distance from the corner as the distance from our own edge.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from one positioned perfectly on the diagonal. I'll define it such that it is strategically meaningful. The offset is positive if it is towards the closest opponent edge (a "blocking" move) and negative if is towards the middle of own edge. The offset is parallel to own edge and its value is naturally the distance in that dimension.<br />
<br />
That's it! We're covered!<br />
The format is <code>$d+o</code>, where $ is a corner symbol <code>)>(<</code>, d is distance from the corner, o is the offset (positive or negative).<br />
<br />
<hexboard size="9x9"<br />
coords="none"<br />
contents="R A:c4 B B:d8 R C:g5 B D:g8"<br />
/><br />
<br />
=== Decoding ===<br />
So what we will look at is a symbol, a primary number and a secondary number which can be positive or negative.<br />
<code><4</code><br />
How to read it...<br />
<br />
Let's talk about a 13x13 board again.<br />
Our new a1 is <code><a1</code>, a13 is <code>(1</code>, m1 is <code>)1</code>, m13 is <code>>1</code>.<br />
Now, the acute corners is not exactly where players will aim with bridges, remember? Black wants a stone at a2 (<code><2+1</code>), while white wants it at b1 (<code><2+1</code>). Have you noticed? It is the same notation! Yes, the players put their stones on long diagonal with offset of +1.<br />
<br />
Let's perform the exercise again that we did with another coordinate system.<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try single stones now again:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-26T14:00:59Z<p>ArekKulczycki: </p>
<hr />
<div>== Coordinate System ==<br />
<br />
=== TL/DR ===<br />
IMO we should talk about the board in reference to the corners, not the edges, go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Excercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. There are 2 approaches to this problem: objective and subjective. <br />
Let's make this coordinate system subjective to a player. This allows for a simplification: to count distance from our own edge as equal to distance from the corner.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from the one positioned perfectly on the diagonal. There are again 2 approaches: objective and subjective.<br />
<br />
Let's define the offset subjectively to a player, i.e. as positive if it is towards the opponent edge and negative if towards the middle of the board. In this definition a move annotated the same can be played twice in a game, because it means something else for each of the players.<br />
Alternative definition could be objective and therefore have unique identifier for each cell of the board. Let's skip this for now.<br />
<br />
That's it! We're covered!<br />
<br />
=== Decoding ===<br />
So what we will look at is a symbol, a primary number and a secondary number which can be positive or negative.<br />
<code><4</code><br />
How to read it...<br />
<br />
Let's talk about a 13x13 board again.<br />
Our new a1 is <code><a1</code>, a13 is <code>(1</code>, m1 is <code>)1</code>, m13 is <code>>1</code>.<br />
Now, the acute corners is not exactly where players will aim with bridges, remember? Black wants a stone at a2 (<code><2+1</code>), while white wants it at b1 (<code><2+1</code>). Have you noticed? It is the same notation! Yes, the players put their stones on long diagonal with offset of +1.<br />
<br />
Let's perform the exercise again that we did with another coordinate system.<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try single stones now again:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-26T13:57:08Z<p>ArekKulczycki: </p>
<hr />
<div>== Coordinate System ==<br />
<br />
=== TL/DR ===<br />
IMO we should talk about the board in reference to the corners, not the edges, go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Excercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. There are 2 approaches to this problem: objective and subjective. <br />
Let's make this coordinate system subjective to a player. This allows for a simplification: to count distance from our own edge as equal to distance from the corner.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from the one positioned perfectly on the diagonal. There are again 2 approaches: objective and subjective.<br />
<br />
Let's define the offset subjectively to a player, i.e. as positive if it is towards the opponent edge and negative if towards the middle of the board. In this definition a move annotated the same can be played twice in a game, because it means something else for each of the players.<br />
Alternative definition could be objective and therefore have unique identifier for each cell of the board. Let's skip this for now.<br />
<br />
That's it! We're covered!<br />
<br />
Let's talk about a 13x13 board again.<br />
Our new a1 is <code><a1</code>, a13 is <code>(1</code>, m1 is <code>)1</code>, m13 is <code>>1</code>.<br />
Now, the acute corners is not exactly where players will aim with bridges, remember? Black wants a stone at a2 (<code><2+1</code>), while white wants it at b1 (<code><2+1</code>). Have you noticed? It is the same notation! Yes, the players put their stones on long diagonal with offset of +1.<br />
<br />
Let's perform the exercise again that we did with another coordinate system.<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try single stones now again:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-26T01:02:37Z<p>ArekKulczycki: </p>
<hr />
<div>== Coordinate System ==<br />
<br />
=== TL/DR ===<br />
If you don't care how and why, go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Excercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Offset Offset paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. There are 2 approaches to this problem: objective and subjective. <br />
Let's make this coordinate system subjective to a player. This allows for a simplification: to count distance from our own edge as equal to distance from the corner.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from the one positioned perfectly on the diagonal. There are again 2 approaches: objective and subjective.<br />
<br />
Let's define the offset subjectively to a player, i.e. as positive if it is towards the opponent edge and negative if towards the middle of the board. In this definition a move annotated the same can be played twice in a game, because it means something else for each of the players.<br />
Alternative definition could be objective and therefore have unique identifier for each cell of the board. Let's skip this for now.<br />
<br />
That's it! We're covered!<br />
<br />
Let's talk about a 13x13 board again.<br />
Our new a1 is <code><a1</code>, a13 is <code>(1</code>, m1 is <code>)1</code>, m13 is <code>>1</code>.<br />
Now, the acute corners is not exactly where players will aim with bridges, remember? Black wants a stone at a2 (<code><2+1</code>), while white wants it at b1 (<code><2+1</code>). Have you noticed? It is the same notation! Yes, the players put their stones on long diagonal with offset of +1.<br />
<br />
Let's perform the exercise again that we did with another coordinate system.<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try single stones now again:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Offset ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.<br />
<br />
=== Diagrams, finally ===<br />
<maybe...></div>ArekKulczyckihttps://www.hexwiki.net/index.php/User:ArekKulczyckiUser:ArekKulczycki2024-09-26T01:00:37Z<p>ArekKulczycki: Created page with "== Coordinate System == === TL/DR === If you don't care how and why, go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph]..."</p>
<hr />
<div>== Coordinate System ==<br />
<br />
=== TL/DR ===<br />
If you don't care how and why, go to the [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Proposition Proposition paragraph] directly.<br />
<br />
=== Intro ===<br />
Hex requires a coordinates system which makes it easy to talk about moves and positions.<br />
<br />
There have been attempts to create coordinate systems which are based on position of the stone in relation to both edges, which is logical and perfectly understandable approach. Obviously this is the way used in other board games and ourselves we annotate the boards this way, using letters for X coordinate and numbers for Y coordinate. This raises a question however... If we already have this notation, why do we still create new coordinate systems? Well, for a couple of reasons:<br />
<br />
1) We play on multiple board sizes, so a coordinate means a different thing on one or another board.<br />
2) The alphabet is confusing, as we don't know which in sequence is a letter, say, "k". However, having a pair of two numbers is confusing too, because if the coordinates are symmetrical then it's easy to confuse the order.<br />
3) The boards are really big... on a popular 19x19 board, it's hard to have even a slightest intuition what move we're describing when using YX coordinates.<br />
3') On top of the objective intuition, it would be useful having 2 moves annotated, to easily see if they are adjacent or in a bridge relation.<br />
<br />
So, back to my point, there have been attempts and they are still based on distances from edges. The values they introduce are the following:<br />
a) replacing alphabet with numbers<br />
b) making measurements from the closest edges, instead of the further ones (with a caveat that it requires an additional flag to understand if it's a stone or it's mirror)<br />
<br />
=== Challenge ===<br />
The values mentioned above are improvement over calling moves directly "o7" etc. But do they really make it *easy* to talk? Do they solve the issues 1-3?<br />
<br />
The general public got convinced by describing several commonly used moves with distances like 11 is meant to be the first cell from the obtuse corner of the board, 22 is the second, 33 third etc.<br />
I don't blame nobody, we didn't have anything else. But how many people use assymetrical coordinates like even 54, 45, let alone 37 or 96? The reason we don't do it is not that we forget which side to count from. The real reason is that the distance from edges in itself is not so meaningful in Hex after all!<br />
<br />
How about a test? Let's mark a move with a lone digit when counting from bottom/left and use [https://en.wikipedia.org/wiki/Prime_(symbol) Prime] notation if counting from top/right, similar to [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates - the best system to my knowledge]. We use YX, that is, the column comes first and then the row. You're following so far?<br />
<br />
Let's talk about a game played on 13x13 board, so <code>11</code> is a bottom-left corner, <code>1'1'</code> is the top-right corner, got it? <code>1'1</code> is the top-left and <code>11'</code> is the bottom-right. Still with me?<br />
<br />
"Draw the damn diagram already!" - that's what you're thinking right? But this is precisely what the coordinates are for - we want to be able to talk about moves without seeing the board in front of us. So bear with me for a little longer and resist the urge of seeing pictures.<br />
<br />
==== Excercise ====<br />
Alright, get ready, so black opens with <code>2'3</code>, white responds <code>45'</code> and they follow with <code>43'</code>, <code>33'</code>, <code>34'</code>, <code>53'</code>. You recognize it, right? No? Howcome, this is the most famous joseki! :)<br />
<br />
Sorry, that was unfair, we are not trained at this as Hex players. The realistic exercise is to just imagine a single move at a time, one by one:<br />
* <code>6'3</code><br />
* <code>75'</code><br />
* <code>7'5</code><br />
<br />
How long does it take you to figure out what move this is?<br />
<br />
=== Reasoning ===<br />
When I play a game of Hex, I don't care about the exact distances from edges. What I do care about (and you should too) is mostly 3 things: corners, ladders and bridges.<br />
<br />
When I make a move on an empty board, my reference points are corners. If I target the obtuse corner, my eyes will run a ladder along the short diagonal to find a move at a desired distance from this corner. Conversely, if I target the acute corner, my eyes will find the bridge connection to my side in that corner and follow bridge-by-bridge to a desired distance. (This last point comes with a caveat, the acute corner is not aimed at equivalently by black and white players because of how the bridge connection works. I will tackle this problem later.)<br />
<br />
If this is how I find my moves, why not base the coordinates off the same idea? That seems sensible, when I hear a coordinate I will just do what I always do, but will count steps and stop at the given distance. We're on to something, no? Let's also solve the problems listed in an earlier paragraph!<br />
<br />
1) Independence on the board size. <br />
<br />
We're focused solely on corners/diagonals, so we're good to go, every board has the same 4 corners.<br />
<br />
2) The alphabet or a pair of numbers confusion.<br />
<br />
Let's use numbers only and forget about symmetry. We want to primarily reflect the distance from the corner. We can use a secondary number to distinguish between all the moves within the same distance from the corner.<br />
<br />
3) Practical intuition on where the move is located.<br />
<br />
As stated before, our reference points to understand the moves are corners. Specifically, we're interested if a move fits into the obtuse corner by a ladder and if it fits to the acute corner by a bridge.<br />
If it isn't a perfect fit, then we would be interested "how far off" it is. The moves can be "off" in two directions, may miss the target (our edge) or may fall into the edge too centrish. I will elaborate on this in an [https://www.hexwiki.net/index.php?title=User:ArekKulczycki#Apppendix Apppendix paragraph].<br />
<br />
3') Relation between 2 moves.<br />
This might be the weakness of the corner-related approach, although with a smart interpretation (which I will do my best to provide) it's possible to also get a correct intuition.<br />
<br />
=== Proposition ===<br />
Based on what was said, we need to pack several values into each coordinate:<br />
<br />
* [Optionally] Color of the stone. It is optional, because usually we know what color the next move is.<br />
<br />
* Distance from the corner. There are 2 approaches to this problem: objective and subjective. <br />
Let's make this coordinate system subjective to a player. This allows for a simplification: to count distance from our own edge as equal to distance from the corner.<br />
<br />
* Which corner we're talking about. We have 2 acute and 2 obtuse corners. I'm tempted to use lower- and uppercase letters but that might be confused with the original column coordinate. We need 2 pairs of symbols then. It can make intuitive sense to use angle brackets for left <code><</code> and right <code>></code> acute corners, and parentheses for left <code>(</code> and right <code>)</code> obtuse corner.<br />
<br />
* Offset. We need a number that will describe the offset of the move from the one positioned perfectly on the diagonal. There are again 2 approaches: objective and subjective.<br />
<br />
Let's define the offset subjectively to a player, i.e. as positive if it is towards the opponent edge and negative if towards the middle of the board. In this definition a move annotated the same can be played twice in a game, because it means something else for each of the players.<br />
Alternative definition could be objective and therefore have unique identifier for each cell of the board. Let's skip this for now.<br />
<br />
That's it! We're covered!<br />
<br />
Let's talk about a 13x13 board again.<br />
Our new a1 is <code><a1</code>, a13 is <code>(1</code>, m1 is <code>)1</code>, m13 is <code>>1</code>.<br />
Now, the acute corners is not exactly where players will aim with bridges, remember? Black wants a stone at a2 (<code><2+1</code>), while white wants it at b1 (<code><2+1</code>). Have you noticed? It is the same notation! Yes, the players put their stones on long diagonal with offset of +1.<br />
<br />
Let's perform the exercise again that we did with another coordinate system.<br />
Black opens with <code><2-1</code>, white responds <code>>5+1</code> and they follow with <code>>4+1</code>, <code>>3</code>, <code>>3-1</code>, <code>>3-3</code>. This time I had easier time writing it down. How readable was it for you? Let's try single stones now again:<br />
* <code>)6+3</code><br />
* <code>(7-2</code><br />
* <code>)7-2</code><br />
<br />
=== Translations ===<br />
It is ofcourse possible to translate from [https://www.hexwiki.net/index.php/User:Mason#Relative_Coordinates Mason Coordinates] to mine.<br />
The way to do it is to first identify the corner, there are 4 cases:<br />
1) No prime notation, it's <code>(</code><br />
2) Both coordinates are prime, it's <code>)</code><br />
3) First is prime, it's <code><</code><br />
4) Second is prime, it's <code>></code><br />
<br />
Once we got the corner, we again have 2 cases:<br />
1) for white player we take the value of the second coordinate (column)<br />
2) for black player we take the value of the first coordinate (row)<br />
<br />
And finally we calculate the offset, player-based:<br />
0) take absolute coordinates, that is, absolute value := board size - prime value<br />
1) for white player, from second coordinate subtract the first (in absolutes)<br />
2) for black player, from first coordinate subtract the second (in absolutes)<br />
<br />
=== Appendix ===<br />
The move offset has a practical meaning for the game. A positive offset means the move is a "blocking" or "defensive" move next to the opponent side. A negative offset means the move is located around the middle of own edge, therefore considered suboptimal.<br />
<br />
Playing moves with an offset will determine the "shape" of your connection attempt. The shape that goes "around" the board I would call *convex*, maybe popularly known as *indirect*. Instead a more *direct* shape that pushes through the middle I would call *concave*. Therefore convex moves (with positive offset) indicate an indirect strategy, while concave moves (negative offset) are an indicator of direct strategy. It sounds reasonable to propose these new terms when referring to the offset, the *convex/concave* moves for short.</div>ArekKulczyckihttps://www.hexwiki.net/index.php/JosekiJoseki2017-05-07T13:02:56Z<p>ArekKulczycki: /* Case-specific */</p>
<hr />
<div>The word "joseki" is borrowed from the game of Go because of the strong analogy between Hex and Go corner play. There are certain sequences of moves played nearby corners of the board that repeat very often among different games. The corners are considered the key areas of the board (by the [[Advanced_(strategy_guide)#The_minimax_principle|mini-max rule]] ). Hence often playing joseki is [[Forcing moves|forcing]] for the opponent to keep playing locally. Knowing josekis narrows down the number of options to choose from. Nevertheless, that doesn't make player's life very easy - picking a correct joseki is as difficult as picking a correct global move. Therefore, this subject is addressed mostly to the advanced players.<br />
<br />
== Joseki's logic ==<br />
When player A makes a move in the corner he dominates the territory around this corner. Assuming that he picked his best strategy, he should stick to it and always defend his domination in the area. However, that doesn't mean that player B should give up that territory. Playing somewhere else will sometimes lead to losing the initiative around previously mentioned corner, but there is a direct counterplay for player B. A game progresses in that manner: player B counterplays, player A holds on to his domination, player B counterplays again etc... This usually lasts 2-10 moves by each player depending on how far from an edge was the first move by player A.<br />
When the final position is reached player A has a fixed escape on one side of the corner and player B has a fixed escape on the other side (second player's escape is always of shorter range).<br />
<br />
Playing a joseki can often be delayed. This is a good choice if one isn't sure which joseki is favourable for them. However, it's important to make sure if one gets initiative back to play joseki. If opponent can make [[Forcing moves|forcing]] moves in other areas of the board then a chance to delay joseki is gone.<br />
<br />
== Examples ==<br />
<br />
=== 4th line josekis ===<br />
'''A1)''' <br />
Red wants an escape on bottom and Blue wants an escape on top:<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 3:h6 B 1:f7 R 2:h7"<br />
/><br/><br />
<br />
'''A2)''' <br />
Red wants an escape on bottom, Blue wants an escape on top '''and Blue knows that Red wants an escape on bottom'''.<br/><br />
The move #3 is an improvement, because in some cases Blue might get an additional free escape on bottom.<br/><br />
There is risk involved. If Red made an error on move #2 and in truth he wanted an escape on top he can correct the error by playing a different move #4.<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 5:h6 B 1:f7 R 2:h7 B 3:g8 R 4:h8"<br />
/><br/><br />
<br />
'''B)'''<br />
Red wants an escape on top and Blue wants an escape on bottom:<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 5:g6 B 1:f7 R 2:g7 B 3:f8 R 4:g8"<br />
/><br/><br />
<br />
'''C)'''<br />
If both players want an escape on top this position might be reached.<br/><br />
Blue keeps a future option of playing in the cell marked with an asterisk.<br/><br />
This is a very risky plan by Blue, because Red has additionally got an escape on bottom. Blue should only play this joseki if he is certain that Red cannot use the escape on bottom. Otherwise a reasonable option is to give up the strong escape on top and go for position '''B)'''.<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 3:g6 B 1:f7 R 2:g7 E *:e8"<br />
/><br/><br />
<br />
'''D)'''<br />
If both players want an escape on bottom we get an unusual position where Red plays the last move of the joseki.<br/><br />
Blue's plan is to get a cell marked with an asterisk for free in future, so he shouldn't play there immediately. What he should do depends on the play in rest of the board.<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 1:f7 E *:g7 R 2:h7 B 3:g8 R 4:h8"<br />
/><br/><br />
<br />
<br/><br />
=== 5th line josekis ===<br />
<br />
==== Common ====<br />
<br />
'''A1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h8 B 3:h7"<br />
/><br/><br />
'''A2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h8 B 3:g9 R 4:h9 B 5:h7"<br />
/><br/><br />
'''A3)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :h8 B :g9 R :i9 B :h10 R :i10 B 1:h7 R 2:j6 B 3:h9 R 4:i8 B 5:i5 R 6:j3 B 7:k3 R 8:h6 B 9:i6"<br />
/><br/><br />
'''B1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:i9 R 4:j8 B 5:j9 E *:h8 E *:h9"<br />
/><br/><br />
'''B2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :i9 R :j8 B :j9 R 1:h9 B 2:f10 R 3:g10 B 4:i7 R 5:j5 B 6:k5 R 7:h7 B 8:h8"<br />
/><br/><br />
<br />
==== Case-specific ====<br />
<br />
'''B3)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :i9 R :j8 B :j9 R 1:h9 B 2:f10 R 3:g10"<br />
/><br/><br />
'''B4)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :i9 R :j8 B :j9 R 1:h9 B 2:f10 R 3:g10 B 4:i7 R 5:j5 B 6:k5 R 7:h7 E *:h8"<br />
/><br/><br />
'''C)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:i10 R 4:h10 B 5:i7"<br />
/><br/><br />
'''D1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:f10 E *:j7 E *:h8"<br />
/><br/><br />
'''D2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :f10 R 1:j7 B 2:h9 R 3:i10"<br />
/><br/><br />
'''D3)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :f10 R 1:h8 B 2:i10 R 3:h10"<br />
/><br/><br />
'''D4)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :f10 R 1:h8 B 2:i10 R 3:h10 B 4:h7"<br />
/><br/><br />
'''E)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:i9 R 4:h9 B 5:i7 E *:j7"<br />
/><br/><br />
'''F1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h7 B 3:h8 R 4:i7 B 5:i8"<br />
/><br/><br />
'''F2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h7 B 3:h9 R 4:i8 B 5:i9 R 6:j8 B 7:j9"<br />
/><br/></div>ArekKulczyckihttps://www.hexwiki.net/index.php/JosekiJoseki2017-05-07T12:38:10Z<p>ArekKulczycki: /* 5th line josekis */</p>
<hr />
<div>The word "joseki" is borrowed from the game of Go because of the strong analogy between Hex and Go corner play. There are certain sequences of moves played nearby corners of the board that repeat very often among different games. The corners are considered the key areas of the board (by the [[Advanced_(strategy_guide)#The_minimax_principle|mini-max rule]] ). Hence often playing joseki is [[Forcing moves|forcing]] for the opponent to keep playing locally. Knowing josekis narrows down the number of options to choose from. Nevertheless, that doesn't make player's life very easy - picking a correct joseki is as difficult as picking a correct global move. Therefore, this subject is addressed mostly to the advanced players.<br />
<br />
== Joseki's logic ==<br />
When player A makes a move in the corner he dominates the territory around this corner. Assuming that he picked his best strategy, he should stick to it and always defend his domination in the area. However, that doesn't mean that player B should give up that territory. Playing somewhere else will sometimes lead to losing the initiative around previously mentioned corner, but there is a direct counterplay for player B. A game progresses in that manner: player B counterplays, player A holds on to his domination, player B counterplays again etc... This usually lasts 2-10 moves by each player depending on how far from an edge was the first move by player A.<br />
When the final position is reached player A has a fixed escape on one side of the corner and player B has a fixed escape on the other side (second player's escape is always of shorter range).<br />
<br />
Playing a joseki can often be delayed. This is a good choice if one isn't sure which joseki is favourable for them. However, it's important to make sure if one gets initiative back to play joseki. If opponent can make [[Forcing moves|forcing]] moves in other areas of the board then a chance to delay joseki is gone.<br />
<br />
== Examples ==<br />
<br />
=== 4th line josekis ===<br />
'''A1)''' <br />
Red wants an escape on bottom and Blue wants an escape on top:<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 3:h6 B 1:f7 R 2:h7"<br />
/><br/><br />
<br />
'''A2)''' <br />
Red wants an escape on bottom, Blue wants an escape on top '''and Blue knows that Red wants an escape on bottom'''.<br/><br />
The move #3 is an improvement, because in some cases Blue might get an additional free escape on bottom.<br/><br />
There is risk involved. If Red made an error on move #2 and in truth he wanted an escape on top he can correct the error by playing a different move #4.<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 5:h6 B 1:f7 R 2:h7 B 3:g8 R 4:h8"<br />
/><br/><br />
<br />
'''B)'''<br />
Red wants an escape on top and Blue wants an escape on bottom:<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 5:g6 B 1:f7 R 2:g7 B 3:f8 R 4:g8"<br />
/><br/><br />
<br />
'''C)'''<br />
If both players want an escape on top this position might be reached.<br/><br />
Blue keeps a future option of playing in the cell marked with an asterisk.<br/><br />
This is a very risky plan by Blue, because Red has additionally got an escape on bottom. Blue should only play this joseki if he is certain that Red cannot use the escape on bottom. Otherwise a reasonable option is to give up the strong escape on top and go for position '''B)'''.<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 3:g6 B 1:f7 R 2:g7 E *:e8"<br />
/><br/><br />
<br />
'''D)'''<br />
If both players want an escape on bottom we get an unusual position where Red plays the last move of the joseki.<br/><br />
Blue's plan is to get a cell marked with an asterisk for free in future, so he shouldn't play there immediately. What he should do depends on the play in rest of the board.<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 1:f7 E *:g7 R 2:h7 B 3:g8 R 4:h8"<br />
/><br/><br />
<br />
<br/><br />
=== 5th line josekis ===<br />
<br />
==== Common ====<br />
<br />
'''A1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h8 B 3:h7"<br />
/><br/><br />
'''A2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h8 B 3:g9 R 4:h9 B 5:h7"<br />
/><br/><br />
'''A3)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :h8 B :g9 R :i9 B :h10 R :i10 B 1:h7 R 2:j6 B 3:h9 R 4:i8 B 5:i5 R 6:j3 B 7:k3 R 8:h6 B 9:i6"<br />
/><br/><br />
'''B1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:i9 R 4:j8 B 5:j9 E *:h8 E *:h9"<br />
/><br/><br />
'''B2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :i9 R :j8 B :j9 R 1:h9 B 2:f10 R 3:g10 B 4:i7 R 5:j5 B 6:k5 R 7:h7 B 8:h8"<br />
/><br/><br />
<br />
==== Case-specific ====<br />
<br />
'''B3)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :i9 R :j8 B :j9 R 1:h9 B 2:f10 R 3:g10"<br />
/><br/><br />
'''B4)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :i9 R :j8 B :j9 R 1:h9 B 2:f10 R 3:g10 B 4:i7 R 5:j5 B 6:k5 R 7:h7"<br />
/><br/><br />
'''C)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:i10 R 4:h10 B 5:i7"<br />
/><br/><br />
'''D1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:f10 E *:j7 E *:h8"<br />
/><br/><br />
'''D2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :f10 R 1:j7 B 2:h9 R 3:i10"<br />
/><br/><br />
'''D3)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :f10 R 1:h8 B 2:i10 R 3:h10"<br />
/><br/><br />
'''D4)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :f10 R 1:h8 B 2:i10 R 3:h10 B 4:h7"<br />
/><br/><br />
'''E)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:i9 R 4:h9 B 5:i7 E *:j7"<br />
/><br/><br />
'''F1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h7 B 3:h8 R 4:i7 B 5:i8"<br />
/><br/><br />
'''F2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h7 B 3:h9 R 4:i8 B 5:i9 R 6:j8 B 7:j9"<br />
/><br/></div>ArekKulczyckihttps://www.hexwiki.net/index.php/JosekiJoseki2017-05-07T12:36:34Z<p>ArekKulczycki: /* Experimental */</p>
<hr />
<div>The word "joseki" is borrowed from the game of Go because of the strong analogy between Hex and Go corner play. There are certain sequences of moves played nearby corners of the board that repeat very often among different games. The corners are considered the key areas of the board (by the [[Advanced_(strategy_guide)#The_minimax_principle|mini-max rule]] ). Hence often playing joseki is [[Forcing moves|forcing]] for the opponent to keep playing locally. Knowing josekis narrows down the number of options to choose from. Nevertheless, that doesn't make player's life very easy - picking a correct joseki is as difficult as picking a correct global move. Therefore, this subject is addressed mostly to the advanced players.<br />
<br />
== Joseki's logic ==<br />
When player A makes a move in the corner he dominates the territory around this corner. Assuming that he picked his best strategy, he should stick to it and always defend his domination in the area. However, that doesn't mean that player B should give up that territory. Playing somewhere else will sometimes lead to losing the initiative around previously mentioned corner, but there is a direct counterplay for player B. A game progresses in that manner: player B counterplays, player A holds on to his domination, player B counterplays again etc... This usually lasts 2-10 moves by each player depending on how far from an edge was the first move by player A.<br />
When the final position is reached player A has a fixed escape on one side of the corner and player B has a fixed escape on the other side (second player's escape is always of shorter range).<br />
<br />
Playing a joseki can often be delayed. This is a good choice if one isn't sure which joseki is favourable for them. However, it's important to make sure if one gets initiative back to play joseki. If opponent can make [[Forcing moves|forcing]] moves in other areas of the board then a chance to delay joseki is gone.<br />
<br />
== Examples ==<br />
<br />
=== 4th line josekis ===<br />
'''A1)''' <br />
Red wants an escape on bottom and Blue wants an escape on top:<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 3:h6 B 1:f7 R 2:h7"<br />
/><br/><br />
<br />
'''A2)''' <br />
Red wants an escape on bottom, Blue wants an escape on top '''and Blue knows that Red wants an escape on bottom'''.<br/><br />
The move #3 is an improvement, because in some cases Blue might get an additional free escape on bottom.<br/><br />
There is risk involved. If Red made an error on move #2 and in truth he wanted an escape on top he can correct the error by playing a different move #4.<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 5:h6 B 1:f7 R 2:h7 B 3:g8 R 4:h8"<br />
/><br/><br />
<br />
'''B)'''<br />
Red wants an escape on top and Blue wants an escape on bottom:<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 5:g6 B 1:f7 R 2:g7 B 3:f8 R 4:g8"<br />
/><br/><br />
<br />
'''C)'''<br />
If both players want an escape on top this position might be reached.<br/><br />
Blue keeps a future option of playing in the cell marked with an asterisk.<br/><br />
This is a very risky plan by Blue, because Red has additionally got an escape on bottom. Blue should only play this joseki if he is certain that Red cannot use the escape on bottom. Otherwise a reasonable option is to give up the strong escape on top and go for position '''B)'''.<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 3:g6 B 1:f7 R 2:g7 E *:e8"<br />
/><br/><br />
<br />
'''D)'''<br />
If both players want an escape on bottom we get an unusual position where Red plays the last move of the joseki.<br/><br />
Blue's plan is to get a cell marked with an asterisk for free in future, so he shouldn't play there immediately. What he should do depends on the play in rest of the board.<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 1:f7 E *:g7 R 2:h7 B 3:g8 R 4:h8"<br />
/><br/><br />
<br />
<br/><br />
=== 5th line josekis ===<br />
<br />
==== Common ====<br />
<br />
'''A1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h8 B 3:h7"<br />
/><br/><br />
'''A2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h8 B 3:g9 R 4:h9 B 5:h7"<br />
/><br/><br />
'''A3)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :h8 B :g9 R :i9 B :h10 R :i10 B 1:h7 R 2:j6 B 3:h9 R 4:i8 B 5:i5 R 6:j3 B 7:k3 R 8:h6 B 9:i6"<br />
/><br/><br />
'''B1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:i9 R 4:j8 B 5:j9 E *:h8 E *:h9"<br />
/><br/><br />
'''B2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :i9 R :j8 B :j9 R 1:h9 B 2:f10 R 3:g10"<br />
/><br/><br />
'''B3)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :i9 R :j8 B :j9 R 1:h9 B 2:f10 R 3:g10 B 4:i7 R 5:j5 B 6:k5 R 7:h7"<br />
/><br/><br />
'''B4)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :i9 R :j8 B :j9 R 1:h9 B 2:f10 R 3:g10 B 4:i7 R 5:j5 B 6:k5 R 7:h7 B 8:h8"<br />
/><br/><br />
<br />
==== Case-specific ====<br />
<br />
'''C)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:i10 R 4:h10 B 5:i7"<br />
/><br/><br />
'''D1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:f10 E *:j7 E *:h8"<br />
/><br/><br />
'''D2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :f10 R 1:j7 B 2:h9 R 3:i10"<br />
/><br/><br />
'''D3)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :f10 R 1:h8 B 2:i10 R 3:h10"<br />
/><br/><br />
'''D4)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :f10 R 1:h8 B 2:i10 R 3:h10 B 4:h7"<br />
/><br/><br />
'''E)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:i9 R 4:h9 B 5:i7 E *:j7"<br />
/><br/><br />
'''F1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h7 B 3:h8 R 4:i7 B 5:i8"<br />
/><br/><br />
'''F2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h7 B 3:h9 R 4:i8 B 5:i9 R 6:j8 B 7:j9"<br />
/><br/></div>ArekKulczyckihttps://www.hexwiki.net/index.php/JosekiJoseki2017-05-07T12:34:19Z<p>ArekKulczycki: /* Complete */</p>
<hr />
<div>The word "joseki" is borrowed from the game of Go because of the strong analogy between Hex and Go corner play. There are certain sequences of moves played nearby corners of the board that repeat very often among different games. The corners are considered the key areas of the board (by the [[Advanced_(strategy_guide)#The_minimax_principle|mini-max rule]] ). Hence often playing joseki is [[Forcing moves|forcing]] for the opponent to keep playing locally. Knowing josekis narrows down the number of options to choose from. Nevertheless, that doesn't make player's life very easy - picking a correct joseki is as difficult as picking a correct global move. Therefore, this subject is addressed mostly to the advanced players.<br />
<br />
== Joseki's logic ==<br />
When player A makes a move in the corner he dominates the territory around this corner. Assuming that he picked his best strategy, he should stick to it and always defend his domination in the area. However, that doesn't mean that player B should give up that territory. Playing somewhere else will sometimes lead to losing the initiative around previously mentioned corner, but there is a direct counterplay for player B. A game progresses in that manner: player B counterplays, player A holds on to his domination, player B counterplays again etc... This usually lasts 2-10 moves by each player depending on how far from an edge was the first move by player A.<br />
When the final position is reached player A has a fixed escape on one side of the corner and player B has a fixed escape on the other side (second player's escape is always of shorter range).<br />
<br />
Playing a joseki can often be delayed. This is a good choice if one isn't sure which joseki is favourable for them. However, it's important to make sure if one gets initiative back to play joseki. If opponent can make [[Forcing moves|forcing]] moves in other areas of the board then a chance to delay joseki is gone.<br />
<br />
== Examples ==<br />
<br />
=== 4th line josekis ===<br />
'''A1)''' <br />
Red wants an escape on bottom and Blue wants an escape on top:<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 3:h6 B 1:f7 R 2:h7"<br />
/><br/><br />
<br />
'''A2)''' <br />
Red wants an escape on bottom, Blue wants an escape on top '''and Blue knows that Red wants an escape on bottom'''.<br/><br />
The move #3 is an improvement, because in some cases Blue might get an additional free escape on bottom.<br/><br />
There is risk involved. If Red made an error on move #2 and in truth he wanted an escape on top he can correct the error by playing a different move #4.<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 5:h6 B 1:f7 R 2:h7 B 3:g8 R 4:h8"<br />
/><br/><br />
<br />
'''B)'''<br />
Red wants an escape on top and Blue wants an escape on bottom:<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 5:g6 B 1:f7 R 2:g7 B 3:f8 R 4:g8"<br />
/><br/><br />
<br />
'''C)'''<br />
If both players want an escape on top this position might be reached.<br/><br />
Blue keeps a future option of playing in the cell marked with an asterisk.<br/><br />
This is a very risky plan by Blue, because Red has additionally got an escape on bottom. Blue should only play this joseki if he is certain that Red cannot use the escape on bottom. Otherwise a reasonable option is to give up the strong escape on top and go for position '''B)'''.<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 3:g6 B 1:f7 R 2:g7 E *:e8"<br />
/><br/><br />
<br />
'''D)'''<br />
If both players want an escape on bottom we get an unusual position where Red plays the last move of the joseki.<br/><br />
Blue's plan is to get a cell marked with an asterisk for free in future, so he shouldn't play there immediately. What he should do depends on the play in rest of the board.<br />
<hexboard size="9x9"<br />
coords="hide"<br />
contents="B 1:f7 E *:g7 R 2:h7 B 3:g8 R 4:h8"<br />
/><br/><br />
<br />
<br/><br />
=== 5th line josekis ===<br />
<br />
==== Common ====<br />
<br />
'''A1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h8 B 3:h7"<br />
/><br/><br />
'''A2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h8 B 3:g9 R 4:h9 B 5:h7"<br />
/><br/><br />
'''A3)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :h8 B :g9 R :i9 B :h10 R :i10 B 1:h7 R 2:j6 B 3:h9 R 4:i8 B 5:i5 R 6:j3 B 7:k3 R 8:h6 B 9:i6"<br />
/><br/><br />
'''B1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:i9 R 4:j8 B 5:j9 E *:h8 E *:h9"<br />
/><br/><br />
'''B2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :i9 R :j8 B :j9 R 1:h9 B 2:f10 R 3:g10"<br />
/><br/><br />
'''B3)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :i9 R :j8 B :j9 R 1:h9 B 2:f10 R 3:g10 B 4:i7 R 5:j5 B 6:k5 R 7:h7"<br />
/><br/><br />
'''B4)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :i9 R :j8 B :j9 R 1:h9 B 2:f10 R 3:g10 B 4:i7 R 5:j5 B 6:k5 R 7:h7 B 8:h8"<br />
/><br/><br />
<br />
==== Experimental ====<br />
<br />
'''C)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:i10 R 4:h10 B 5:i7"<br />
/><br/><br />
'''D1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:f10 E *:j7 E *:h8"<br />
/><br/><br />
'''D2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :f10 R 1:j7 B 2:h9 R 3:i10"<br />
/><br/><br />
'''D3)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :f10 R 1:h8 B 2:i10 R 3:h10"<br />
/><br/><br />
'''D4)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B :g8 R :i8 B :f10 R 1:h8 B 2:i10 R 3:h10 B 4:h7"<br />
/><br/><br />
'''E)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:i8 B 3:i9 R 4:h9 B 5:i7 E *:j7"<br />
/><br/><br />
'''F1)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h7 B 3:h8 R 4:i7 B 5:i8"<br />
/><br/><br />
'''F2)'''<br />
<hexboard size="11x11"<br />
coords="hide"<br />
contents="B 1:g8 R 2:h7 B 3:h9 R 4:i8 B 5:i9 R 6:j8 B 7:j9"<br />
/><br/></div>ArekKulczycki