on “flood in all directions simultaneously” estimator its b+52,5
it fails because high stones grow faster each iteration than stones that are close to corners
stones that are close to corners grow slower because it grows in 2 directions only, while stones in center grows in 4 directions
How to fix it?
the law of conservation of mass is needed
only 1 point should be painted each iteration
black, white, black, white, …
(it paints same shape as in pure flood estimator, just slower and few asymmetry is possible) w+6,5
much closer to actual score
and with simulation like above, if we just unpaint points one by one that are surrounded(and count these unpainted points), then we will get correct Japanese rules score.
You may be approaching the Bouzy map algorithm, which is a kind of influence/territory estimator.
It looks nice, but I don’t think one can generate reasonable score estimations from fairly simple algorithms like that, nor should OGS players expect that this early in the game.
And if you somehow succeed to make it as accurate as 5k level positional judgement, nobody would be allowed to use it in their games, because it would amount to outside assistence.
it basically answers question “how game will look like if it continues peacefully, without any dead stones and invasions?”
while AI estimators predict crazy AI fight
my estimator is almost pure geometry, no Go knowledge
It’s an interesting balance (dare I say paradox)… you want to make a good score estimator, otherwise what’s the point? But you also don’t want to make a good estimator because then it’s just the computer playing, and then what’s the point
But memes aside, I think people kind of know what they want, a tool to help them count when they’re feeling lazy, just a rough guide to if they’re winning losing, or if they were considering resigning just something to help decide although it might be wrong.
More or less only counting something surrounded or from their stones to the edge of the board more or less, probably ignoring the centre.
Then some people might want a completely manual system, draw border marks stones dead automatically, and some people will just always turn off the estimator anyway.
I guess it’s just not clear how to make a bad estimator that people don’t hate using, just like I imagine that it’s hard to make a bad go ai, that people enjoy playing against.
and add ability to easily repaint what it draws
then it will be faster than drawing from zero, while surely no assistance
(it counts all stones as alive until you choose which are dead. May be crazy in beginning, but quality is good in endgame)
Did you publish the source(s) for these algorithms? I’ve put some effort towards cleaning up the current score estimator recently, and might be able to inject experimental algorithms soon.
