It doesn’t if you define the quadrants with:
Math.floor(3 + Math.random() * 7.5);
Math.floor(10.5 + Math.random() * 7.5);
Sharing the probability on the borders of the quadrants between them, and the probability of tengen between all four quadrants.
To paraphrase Boondocks, did you just say what I was trying to say, but smarter?
feature idea:
graphical output, something like:
. a b c d e f g h i
1 + + + + + + + + +
2 + + + + + + + + +
3 + + + 0 + + @ + +
4 + + + + + + + + +
5 + + + + + 0 + + +
6 + + + @ + + + + +
7 + 0 + + + + + + +
8 + + + + + + @ + +
9 + + + + + + + + +
i have seen the idea of gray (or dual, as refered in the video) pieces and i have a feeling it might work well with this randomization. For example, 3 stones for each player and 2 gray stones using the 2 quadrants left.
EDIT:
ordinary board can be thought of as 21 x 21 with edges occupied by gray stones.
I’m sure you can ask Math stack exchange and get a better answer, but pseudo-random number generator (such as you’ll find in your browser feeding the stone placements) is perfectly sound for this task. You’ll encounter problems with pseudo-random numbers only if someone will benefit from being able to predict the next one (such as to crack an encryption, or win a game of online poker).
If the stone placement used real random numbers you would find that stones would have even more tendency to cluster together, as the probability of no clusters of stones is less then the probability of getting at least one cluster.
i have a slight request/question, the file is saved as “Unknown” without extension. i had to add .sgf to be able to upload it on sgf library in OGS. i wonder if you could add the extension, or is the filename decided by the browser, or specific to devices?
I was reading the discussion about handicap vs reverse komi and i have a feature request. Could you add the option to give extra stones for black?
…
for reference, the following page links to 2 ways of calculating reverse komi, one is a table made from game data, the other a formula using ogs rating.
https://senseis.xmp.net/?ReverseKomi
I just updated. Added a bunch of game configuration features, including handicap and komi, but also board size, and adjustable margins.
Also the chrome bug where sgf file is save without default name has been fixed.
now wondering about the effect of a single neutral stone placed 5th line up, potentially balancing out the advantage (?) of having more stones closer to corners/sides.
EDIT:
i wonder if it is possible to estimate the optimal point or area for the neutral stone to be placed in order to balance the configuration of other stones?
found an OGS group with a similar idea:
tried to add this to the original post as an edit, but it could no longer be edited.
@Jirogo36 I’ve saved the generated starting position as URL now, so after you’ve generated the position, you can share the position with your opponent by copy-pasting the URL, you can then bet on komi, adjust the komi field on the winning bet, and then download the SGF.
Been playing handicapped games against kata-bot (black needs to pass first turn, for anyone wants to do the same). I’ve been tending to run generate several times until I get one that is spread apart enough.
I have a vague idea for an improved (?) version. Instead of quadrant shuffling, no-adjacent rule, and free-stone margins, we make a 2 dimensional probability distribution (table of probability?) over the board.
After each stone placement, we somehow update the distribution using 3 types of adjustable “repulsion coefficients”: same-color repulsion, opposite-color repulsion, and edge repulsion. Taxicab distance might be relevant for repulsion, making attachment less likely than shoulder hit. Having separate coefficients for same/opposite colors makes sense if shoulder hit (opposite color) is more severe than kosumi (same color), which i’m not sure of (i’m a kyu player.).
@Vsotvep I’d like to hear your opinion on this as well, as you seem to be much more knowledgeable in math than me.
EDIT:
It occurred to me it might be required to keep track of 2 separate distributions, one for each color.
EDIT2:
Actually, repulsion from edge might not make sense. Stone-free margin might be more reasonable.
I played it too. I just used RANDOM.ORG - List Randomizer
C3
C4
C5
C6
C7
C8
C9
C10
C11
C12
C13
C14
C15
C16
C17
D3
D4
D5
D6
D7
D8
D9
D10
D11
D12
D13
D14
D15
D16
D17
E3
E4
E5
E6
E7
E8
E9
E10
E11
E12
E13
E14
E15
E16
E17
F3
F4
F5
F6
F7
F8
F9
F10
F11
F12
F13
F14
F15
F16
F17
G3
G4
G5
G6
G7
G8
G9
G10
G11
G12
G13
G14
G15
G16
G17
H3
H4
H5
H6
H7
H8
H9
H10
H11
H12
H13
H14
H15
H16
H17
J3
J4
J5
J6
J7
J8
J9
J10
J11
J12
J13
J14
J15
J16
J17
K3
K4
K5
K6
K7
K8
K9
K10
K11
K12
K13
K14
K15
K16
K17
L3
L4
L5
L6
L7
L8
L9
L10
L11
L12
L13
L14
L15
L16
L17
M3
M4
M5
M6
M7
M8
M9
M10
M11
M12
M13
M14
M15
M16
M17
N3
N4
N5
N6
N7
N8
N9
N10
N11
N12
N13
N14
N15
N16
N17
O3
O4
O5
O6
O7
O8
O9
O10
O11
O12
O13
O14
O15
O16
O17
P3
P4
P5
P6
P7
P8
P9
P10
P11
P12
P13
P14
P15
P16
P17
Q3
Q4
Q5
Q6
Q7
Q8
Q9
Q10
Q11
Q12
Q13
Q14
Q15
Q16
Q17
R3
R4
R5
R6
R7
R8
R9
R10
R11
R12
R13
R14
R15
R16
R17
KataGo is strong, even 9 stones is not easy for 9k, so no need for random white stones
There are some lovely ways to increase the probability of an even distribution of stones on the board, some more sophisticated then others.
I’m sore we can (for example) assign probabilities of each intersection based on the distance to the nearest stone so that an intersection next to a stone has less probability of being drawn then an intersection 10 rows and 10 columns from the nearest stone. We can take this further and weight the probability based on the weighted mean distance to each stone on the board.
Alternatively we can assign probability based on how many stones are in a given radius from the intersection. Say an intersection with only one stone in a 5 intersection radius circle around it has a greater probability of being drawn then an intersection with 4 stones there.
These are just two possibilities but I’m sure there are some lovelier distributions out there, and I would love to try implement them. I’m a big fan of statistics and probability—even though I’m not very skilled in the craft.
By the way. If we implement any of these fancy distributions, the starting position is still fully (pseudo) random. We just say that it is not uniformly distributed, or that the randomness is not independent ¹.
Does anyone want a game with random starting positions?
Starting to have slightly more concrete idea:
Let’s say we start with a 19 x 19 table. There’s an option to normalize the cells (make them add up to 1, specifically 1 / 19 x 19) but here we start them initialized to 1s. (Ignoring stone-free margin in this example.)
Let’s go to the update phase after a stone is placed. In neighbor-counting (counting stones within certain radius), cells within the radius is incremented by 1. In weighted mean distance, we increment cells within distance 1, then within distance 2, then within distance 3, … (The cells near the placed stone are incremented more often.)
When we place a new stone, we make each point inverse as likely as the cell in the table.
These numbers could lead to overblown results and probably need to be adjusted, but it’s a start.
More refined method might be to make a update/scaling table after each stone placement and do a cell-wise multiplication. I wonder if it can be formulated in terms of matrix multiplications, even though I don’t know if there’s any advantage to it. Normalizing would also make the numbers easier to interpret.
EDIT:
When I wrote “weighted mean distance”, I actually only took into acount the distance, so I guess they are not the same.
EDIT2:
If we could make something that works well, I have an idea of a separate randomized (and handicapped) ladder analogous to randbats in pokemon showdown. It’s a junky idea and might offend some players, but sounds fun for me.
Alternative idea is to modify a generated configuration to decrease crowdedness.
One idea is random walk that takes into account repulsion between stones.
Another is to accept or reject a candidate move according to relative crowdedness of current and candidate locations (Metropolis-Hastings algorithm).
Crowdedness could be neighbor-counting or some other way to take into account the relative positions (inverse distance, inverse square distance, etc).
