Corners are not used Einstein forum
34 replies. Last post: 20141118
Reply to this topic Return to forum
Richard Malaschitz โ at 20140910
There is statistic of moves based on 4.500.000 moves on Little Golem.

Ingo Althofer at 20140916
Hi Richard,
your observation fits well with those by Ingo Schwab
and Wesley Turner who did experiments with their
Ewn bots. In particular, Ingo Schwab even computed
endgame table bases (for positions with up to 8 stones)
where the 3+3 corner squares did not belong to
the board.
I myself wrote in an article (on automated game
design) also about Ewn and called the 3+3 squares
“desert squares” and the two corner squares "total
desert".
Cheers, Ingo. 
Jonny at 20140917
Look here:
http://www.littlegolem.net/jsp/game/game.jsp?gid=1239567&nmove=50
a interesting game with using the 3+3 corner and won the game. I think it was the only time i did it. The “total desert” i never use, all the time.
BTW: a real great game anyway
Jonny 
Ingo Althofer at 20140917
Hi Jonny,
you mean move no.56 in t hat game, right?
In that position I would not have played to the desert square ...
Just now I ran a little test with bots MonteCarlo(500) vs MonteCarlo(500).
In 18 games three moves to desert squares were done. Two of them
were in positions where the opponent was winning anyhow. In the
third one it was a “regular” move.
Unfortunately “my” Montecarlo bot can not play fully automatic, taking such
statistics. Perhaps, YHW could let his bots do such a job over night?!
Cheers, Ingo. 
naive_child_c at 20140917
YHW (personally) thinks that move 56: “3/c1c2” is the worst of all six possible moves. That’s not a good example for ‘When should I move to a desert square!?’ That was rather a lucky shot ! :D
My analysis are coming... 
Ingo Althofer at 20140917
Hi, naive child.
Thanks for the feedback and for announcing your experiment.
As a reward you will get a free copy of the book by A. and Voigt.
Cheers, Ingo.
PS. Greetings also from Ma Waldorf! 
Ingo Althofer at 20140917
Question to Richard on his statistic:
The values for the tow target squares are rather different:
2.78 % vs 2.78 %
Did always the player in the top left corner start the game?
Ingo. 
naive_child_c at 20140917
Analyse: game #1239567, next move: 56, roll: 3  stone/move '  min [] '  max [] '  mean [] '  worst move '  best move ' 2/c1xb2 {color:blue}44,3% %{color:blue}49,0% %{color:blue}46,0% %{color:black}0% %{color:black}2% 2/c1c2 %{color:blue}36,1% %{color:blue}42,4% %{color:blue}41,0% %{color:black}1% %{color:black}0% 2/c1b1 %{color:blue}32,8% %{color:blue}39,2% %{color:blue}36,4% %{color:black}4% %{color:black}0% 4/e2d3 %{color:blue}41,9% %{color:blue}46,4% %{color:blue}44,7% %{color:black}0% %{color:black}1% 4/e2d2 %{color:blue}43,2% %{color:blue}45,7% %{color:blue}44,9% %{color:black}0% %{color:black}0% 4/e2xe3 %{color:blue}45,2% %{color:blue}48,5% %{color:blue}47,1% %{color:black}0% %{color:black}2% 
naive_child_c at 20140917
hmm...Why looks this table proper after copying it into my profile but not in forum?
Analyse: game #1239567, next move: 56, roll: 3  stone/move ' min [] ' max [] ' mean [] ‘ worst move ’ best move ' 2/c1xb2{color:blue}44,3% %{color:blue}49,0% %{color:blue}46,0% %{color:black}0% %{color:black}2% 2/c1c2%{color:blue}36,1% %{color:blue}42,4% %{color:blue}41,0% %{color:black}1% %{color:black}0% 2/c1b1%{color:blue}32,8% %{color:blue}39,2% %{color:blue}36,4% %{color:black}4% %{color:black}0% 4/e2d3%{color:blue}41,9% %{color:blue}46,4% %{color:blue}44,7% %{color:black}0% %{color:black}1% 4/e2d2%{color:blue}43,2% %{color:blue}45,7% %{color:blue}44,9% %{color:black}0% %{color:black}0% 4/e2xe3%{color:blue}45,2% %{color:blue}48,5% %{color:blue}47,1% %{color:black}0% %{color:black}2% 
naive_child_c at 20140917
Ingo, that’s the confusing thing and difficult to implement.Player blue always starts. The moving direction depends of the fact if the game is yours (and you are also logged in) or if it is a forgeign game. You are always moving from down right to up left in your own games – independent which color you have. If you take a look at other games, red always moves from down right to up left – blue vice versa. If you are logged out, it’s the same in your own games...

Ingo Althofer at 20140917
Hi naive_child,
perhaps you can mail me your data in proper format.
My address is
ingo.althoeferballaballaunijena.de
You know that you have to substitute ballaballa.
Thanks inadvance, Ingo. 
naive_child_c at 20140917
I do not understand why the table is not displayed correctly. I tried this table on two different textilepages as well as in a textile sandbox and it always looks properly... hm,

naive_child_c at 20140918
I’ve just copied the table into my profile. Looks like the table(code) does not work in this forum although I have tested the code at TxStyle ยท Textile Documentation... I did five different trials with a calculation time of up to 5 minutes. I used 2 different calculations depths for the heuristics (2 and 3, where counting starts at 0). The maximum calculation depth (node where the MC starts) was 3 (counting starts also at 0). The minimum number of tests (MC) per node was varied from 56 – 150. Results: I probably would have never done the chosen move ‘2/c1b1’. In five trials, I tended twice to move 2/c1xb2 as well as 4/e2xe3 and once to 4/e2d3. The worst move was 4 times 2/c1b1 and once 2/c1c2.

Jonny at 20140918
Ok, ok, you and your Bots are right :
)) but...)) without knowing but with feeeeeeeeling :))))))
if i choose c1xb2 i lost my 2 probably in the next 7 moves and lost the game. With move c1c2 i would won the game too.
In the situation of the game i thought, it is was the best dont take a stone of my opponent.
So i doing the right ; 
Ingo Althofer at 20140918
Hi naive child,
somehow I did not explain well, what I wanted.
I was not (so much) interested in Jonny’s special position, but in
the general question, how often desert squares are used.
So, please play thousands of bot games (from random starting
positions) and take statistics how often which squares are moved to.
So, produce a statistic like that by Richard M in the
original posting.
Thanks in advance, ingo. 
naive_child_c at 20140918
I think the result would depend on the chosen heuristic – on the calculation depths of the heuristic. I do not know if that would be representative.
I would have another suggestion. I have alle EWN game results from LG on my pc. Anytime I started even to read out all move lists. (I was thinking about to create an opening book). I could evaluate such a statistic from these games...
Could anyone explain why my wordwraps as well as my inserted paragraphs are always lost after sending a message to forum? I know, this is an xhtml issue but I don’t know how I can fix this? Do I have to paste the paragraphs/wordwraps via buttons above the editor? Or must I inset xhtmlphrases by hand? My ENTER inputs by hand or from copied text are never accepted... 
Ingo Althofer at 20140919
Hi, naive child,
> I think the result would depend on the chosen heuristic โ on the calculation depths of the heuristic.
of course, but that is not a problem but a chance.
You can do one “run” with paramter set P_1, and perhaps
another run with parameter set P_2,
Then we would be able to compare all threee results:
(A) the statistics by Richard
(B) the P_1 results
© the P_2 results.
My Conjecture: Independent of your implementation details
the results of (B) and © have good chances to be more similar
to each other than to (A).
Cheers, Ingo.
I do not know if that would be representative. 
naive_child_c at 20140919
I’ve uploaded similar statistics on this page. The name of the file is ‘Feldverteilungen.xlsx’. Instead of counting the movesquares only I logged all stone positions before each move to estimate in how many cases/moves are desert squares occupied in general.
A short description is given on the sheet ‘Summary’. More than 35 Mio. moves/positions with random starting positions were analyzed.I did it because those positions are also not included in my endgame tablebase – at least I have no access to those positions during a typical calculation on LG. I could repeat these runs with another calculation depth quickly.
I started to read out the move lists from LG, but I stopped analyzing these moves because nearly a fourth (!) of the last 5000 (approx.) finished EWN games have less than 2 moves.
So, at least one of both players was/is inactive or resigned the game promptly. One move would be counted if the 2nd player resigned. So, normally I should forget the whole game/match because the statistics would be falsified. I do not know if Richard has counted moves of unfinished matches (or if moves from backward capture and/or blackhole are also included)?
From my side, I can’t detect timeouts in later phases of a game directly from move list without analyzing the situation on board or taking the score into account. The phrase ‘RESIGN’ is shown in this list but not if a match is ‘WON’ by moving or by a ‘TIMEOUT’ and thus not accomplished. To take the score into account is a bit too extensive at the moment...

Ingo Althofer at 20140921
Hi naive child,
I am back from a 4day trip. Thanks for the interesting data.
Interestingly the first player is using extreme desert squares
more frequently than the second player (150 percent).
Could you “repeat” the experiment with n_cheuristic of depth 2?
Cheers, Ingo. 
naive_child_c at 20140923
I’ve tried to start the higher depth but unfortunately it’s not running. I’ve forgotten that my MC algorithm stops when a game is a 100% win. Those games are not played to the end. My owner has to change the code first. I’ll let you know when these experiments are accomplished.

Jonny at 20140923
Hello, often i have a situation like this:
http://www.littlegolem.net/jsp/game/game.jsp?gid=1494655&nmove=30
Look to move 33 and 35. I can choose what corner i want to use. Just for the statistic...
Jonny 
Ingo Althofer at 20140923
Hi Jonny,
I do not see your point in this example:
Moving to a desert square would only slow you down 
diminishing your winning chances.
Ingo. 
Jonny at 20140924
yes, my point was the statistic of the three corners round the finish field. Nothing to to with the desert corners.

Rex Moore โ at 20140924
Also interesting would be a table like Richard’s that shows only where the winning stone moved. Though I’m sure it would be quite similar.

naive_child_c at 20140928
My experiment for calculation depth 2 is finished. The depth 3 has already accomplished more than 8 Mio. positions but it’s still running.
I’ve uploaded an updated version with a snapshot of already determined results. The filename is: Feldverteilungen_SUMMARY.xlsx
The results are sorted by calculation depths. All results are summarized on ‘Overview’ datasheet.
In first moment I thought that a specific strategy or a move preference would be observable in statistics but I think that was a false conclusion.The ‘duration’ on a certain square is counted (applied to all position)  that’s relevant for me because of my endgame database – however, a lower value does not mean that a certain square is visited rarely. It can be visited as often but with ‘quicker’ stones.
I know that the heuristic depth 2 is always doing some different moves – especially at the first 2 rolls. For example, the depth 2 prefers to capture the own stones on the corner (C1, E3 or A3, C5) of starting position in first moves by moving them in front of own stones instead of moving diagonal. Those moves are not always better but lead to the fact that desert squares are in practice not reachable anymore for these stones. So, the ‘desert squares’ are occupied rarely at depth 2 – especially with stones starting at these ‘desert corners’.
There are also many human players who prefer more often the diagonal move (I think me too) others rather the move in front of own stones. These moves are leading into different games with different speed of stones at the end. (I’m wondering why nobody ever created a name for these ‘openings’ ;))
My calculation depth 3 is doing strange things. In nearly 2% of all positions/moves is at least one stone located on these desert square but I don’t know why! I don’t know if stones are simply ‘parked’ on desert squares (to avoid a ‘Zugzwang’situation e.g.) or if those squares are used on way to the goal or to force opponent to capture own stones or...?!I thought it could be a bug but this depth plays stronger than/against the lower ones – as it should be...I’ve tested it again...however, it played against itself, the moves could be very different against another player. I think the strategy depends to much of individual opponent. I’ll check the depth 3 again against another (lower) depth to see what happens. 
Ingo Althofer at 20140929
Hello, naive child,
thanks for your new experiments.
One direct hint: when you run simulation series and get (very)
strange results, look (by hand) at some of the games generated.
Often you will find simple explanations for the phenomena,
for instance some unexpected bug.
In general:
99.9 percent automatic + 0.1 percent human interaction
is better than
100 percent automatic.
Ingo. 
Carroll at 20140929
I was trying to find back in my games positions where I played to desert corners but couldn’t.
Here is a position where I think it is better for White to play to a1 corner (bold going NW):

 
 
 6 
642 
 1 


YHW at 20140930
I logged the situations in which the heuristics moved to a desert square in the last test run. I’ve taken a look on approx. 100 positions, and as a player, I would say I would do the same moves mostly in similar situations.The most positions were endgame positions with less than 45 stones or situations where one of both players had one or two stones only – similar to Carroll’s position.
A few moves are wrong but not if the calculation depth is three only. The heuristic tried to protect their last stone or avoided to capture an opponent’s stone where another one is directly located in front of the goal.Some moves are wrong in general but it would be a wonder to get perfect moves only at an calculation depth of < 4. What should I do? I know that the playing strength increases with higher calculation depths, it’s no bug detectable, It looks rather so that the heuristic depth 3 prefers to decrease its own stone numbers stronger than the other ones.
Those positions with less than 6 stones are not calculated by heuristics if the child plays anyway. The program uses its perfect results from endgame database instead and stops playing the match to end.
I did a mistake in the past that lead to the situation that the child played one night with it’s heuristic (depth 3) only against RoRoRo without MonteCarlo. The calculation time was some milliseconds only and both played some thousand of matches.And as I remember right, the child ‘won’ 35% of all matches against RoRo. That’s weak but in the same dimension like the most human players do against RoRo. So, my experiment could be representive but not for the best players...
I’ve updated the results (Feldverteilungen_SUMMARY.xlsx) again. It’s interesting to see which moves/squares depend the most of player strategy (‘B2’ as well as ‘D4’), but I’ll stop here. I think It’s not so interesting for human players. 
YHW at 20140930
Interesting to see that some blank lines in my last post were inserted but some not. If there’s a certain rule for that? Yes, if last word in sentence ends on ‘s’. No, if last line ended with a point ? ;)

The_Burglar at 20141003
Easy way to remove rarely used corners is to invent Hex Einstein played on a hex board consisting of two triangles joined together

Ingo Althofer at 20141014
Hello,
> Easy way to remove rarely used corners is to invent Hex Einstein...
I tried that back in 2005 (soon after the invention of Ewn). It does not
work well. One main problem is that there are no quick and slow
moves on that board. (On normal board diagonal moves are quick,
and rectangular moves are slow.)
Ingo. 
The_Burglar at 20141118
Black hole Einstein, where the rare corners make you disappear
Yes hex Einstein not good, was pretexting