Sybil's perfect mistake

I found this amusing.

<br/>  Diamante vs Sybil (gameid = 1347756, move 37)
<br/><br/>  5:  a b c d e
<br/>    +-----------+
<br/>  1 | . . . . . |
<br/>  2 | . . 5 . . |
<br/>  3 | . . 1 . . |
<br/>  4 | . 6 . b . |
<br/>  5 | . . . . . |
<br/>    +-----------+
<br/>

In the diagram, "b" is Sybil's Red 2 piece, heading toward the lower right corner, and it is Sybil's turn to move.

Sybil isn't happy enough with merely crushing humans. Instead of just winning instantly with 2-e5, the program elects to make the crueler knife-twisting move 2-d5. Sybil does not play nice! :-)

It does this because both moves have exactly the same probability of winning (1.0), and the author (Westley Turner) hasn't bothered to ensure the shortest path to victory. Of course, technically it is a very slight error, since it is conceivable that Sybil loses connection with the server indefinitely, and loses the game on time instead of winning. We might call it a "perfect mistake". :)

The program actually does this kind of thing quite often when it is in the endgame database. For example, moving a piece sideways instead of toward the goal when it is too far away to possibly change the outcome in any way (such as when all moves are going to lose anyway). Not a mistake, per se, but a telltale hint that it isn't human...

Sorry that the diagram comes out so ugly -- the [pre] tag doesn't work very well.

Here's a direct link to the position:

http://www.littlegolem.net/jsp/game/game.jsp?gid=1347756&nmove=37

The child is also playing a bit strange in some situations but in the case if it is assuming that the winning chance is (close to) zero. It is moving always in horizontal direction in that case and not directly towards the goal. That seems a bit illogical but other moves would not lead to a significant better position. Unfortunately, sometimes is there still a very low chance to win which was perhaps not found ramdomly by the MC algorithm.

Of course, such an error can easily be avoided by changing the order of the code but currently I can't be bothered to fix that since I have (sometimes very complex) rules for all pads on the board and in addition for red and blue. That's just too much work ;)

but it does seem pretty easy (and should be implemented for any bot imo) that if any move wins you the game instantly, you do that move.

or ... as I did in Gambler: On same probabilities, prefer a diagonal move ...

My program Mona actually won a game because I put in the shortest win / longest loss code. In a lost position she made the move with the longest loss, and the opponent program didn't see the win, blundered, and lost.

Yes, for Ewn it is enough to just. prefer the diagonal move in the case of a tie.

The child is alsways doing the winning move directly but gambler's rule is absolutely right, however, it's just a lot of (stupid) copy work for me. ;)

darse's method sounds pretty intelligent, that's an option about which I was thinking in the case of two equal moves in general - but I did not know if (or in which case) I should prefer the longest or the shortest win/loss because the child's thinking depths is very limited in comparison to other bots. I thought about to do the fastest win against other bots and the longest against human - but which method would be better against whom in general can most likely not be predicted in advance, this is probably more situational but definitely an option.

naive_child beat me today after taking the long way around: 6-a3-a4-b5-c5-d5-e5 -- and it had its 5 piece for the entire game! In fact, the 5 ended up in the opposite corner at d1!

I had an overwhelming position, but as usual the child rolled perfect-perfect with its 1/6 piece while i flunked on a 4/6 chance to win.

I have a plus record against both RoRoRo and OneStone over the last 20+ games, but the child has been kicking me in the teeth mercilessly so far (3-0 and 3-1).

The child... grrr.

YHW: i think it would be okay to give a slight EV preference for diagonal moves, in order to combat the random noise factor.

For example, if you're doing a million MC roll-outs (with, say, +/- 0.1% noise), and the move a5-a4 comes out to be 0.05% better than a5-b4, then prefer the forward move instead (i.e. give all forward moves a small bonus). [Note that the variance is different when you're near the 0.0 or 1.0 outcomes, so you might want to use a better estimating formula (or compute the variance exactly with a binomial expansion).]

I was thinking of maybe doing a quick MC implementation myself. I might try just ignoring sideways moves in the random roll-outs, and see if it improves performance (because it is guessing the best moves more often). This is kind of similar to Castro, where Timo ignored ring wins in Havannah roll-outs, and it improved the program's performance on large boards significantly.

Jepp, crasy child. I would never do a move like 6e3-e4. Except one time...

http://www.littlegolem.net/jsp/game/game.jsp?gid=1239567&nmove=50

:---)))

Yes, unusual move, but that was a link to your championship game against kitaktus :)

darse: I already have those rules in my code but based on my own playing experience not on MIN/MAX results. Those rules makes the calculation time shorter - it comes closer to an evaluation function that's always only calculating the distance to the goal but that makes not always sense. For example, if you would be able to capture an opponent's stone that is directly in front of the goal it would be better to capture it horizonatally/vertically if your own stones are too far away from your goal. The child would always capture it depending on own stone positions.

Those rules are also leading to a totally different strategy from the beginning of the match - it is less trying to move through the center with attacking stones because there is too much trouble but no opponent's stone is attacking on the flanks. The fact that you are interceptable gets more lost. For the last pads (goal distance up to two) it's a good solution but not for stones which are still in starting area.

The funny thing is that the child with MIN/MAX calculation depth of 3 is playing better (in 209 single games) than that version with a depth of 4 against RoRoRo (in 357 single games). That seems so that my own rules are better than the MIN/MAX calculation against RoRo but not against OneStone. However, it might be statistical waste only...

:-) I feel bad for Sybil's opponents whenever I see moves like that (though I guess not bad enough to write any code to prevent it from happening). I remember one game (though I don't recall which) where Sybil made two consecutive useless moves in a still-won position. Hopefully the folks on the other side choose to be entertained by it.

View these moves as trademarks of Sybil.

Similar to young people who run around with their shoe senkles open.

Ingo.

Sybil charges forward in the early moves of the game (e.g. c1-d2 or a3-b4), but slides sideways when the game is all but over.

Clearly some kind of split personality...

\*\*\* On bot trademarks more generally ***

\* In Monte-Carlo go one of the bot specialities

is to win almost always by half a point when

winning against humans. Clever humans take this

to see when a game is "practically" over: When the

bot starts to make useless moves...

Perhaps Sybil (which comes without Monte Carlo elements)

tries to simulate the 0.5-MC-bots ?!

\* The classical game Nine Men's Morris was solved

by Ralph Gasser in 1994. The game is a draw, a dead draw

so to say: In many positions there are many moves that

keep the draw.

After the solution Gasser's bot played an exhibition match

against one of the Morris grandmasters (there are only a few

of them, all with Swiss nationality). It was scheduled for

10 games, but the human had won the match after nine games by

5.5 - 3.5 (+2, =7). How can such a thing happen? The bot, based

on a database, played perfectly (in theory).

BUT: For the bot all draws were the same. So, it did not try to

build up pressure against the human, but played randomly any of

the draw moves. This led to long games - and for the human it

was easy to stay in the draw range. Now hardware came into play:

In some positions there were tablebase collisions. In two times

during the match this led either to a losing move or to a crash.

These gave the two human wins.

Ingo.

> Clearly some kind of split personality...

Ha! I'd more or less considered this my own private joke. As its evaluator Sybil uses a different neural network for every different combination of pieces.

> View these moves as trademarks of Sybil.

> Similar to young people who run around with their shoe senkles open.

I like it. A computer wearing shoes with untied laces would make a good logo for Sybil should I ever decide to make one.

[game;id:1347756;move:37]

hahahaha, little beast sybil_c....

> I like it. A computer wearing shoes with untied laces would make a good logo for Sybil should I ever decide to make one.

http://www.imdb.com/title/tt0065566/

As opposed to:

http://www.imdb.com/title/tt0075296/

[game;id:1396207;move:39;title:Sybil is one sick puppy]

[ http://www.littlegolem.net/jsp/game/game.jsp?gid=1396207&nmove=39 ]

A mathematician and a physicist were asked the following question:

Suppose you walked by a burning house and saw a hydrant and

a hose not connected to the hydrant. What would you do?

P: I would attach the hose to the hydrant, turn on the water, and put out

the fire.

M: I would attach the hose to the hydrant, turn on the water, and put out

the fire.

Then they were asked this question:

Suppose you walked by a house and saw a hose connected to

a hydrant. What would you do?

P: I would keep walking, as there is no problem to solve.

M: I would disconnect the hose from the hydrant and set the house on fire,

reducing the problem to a previously solved form.