move in the pv at starting position

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Post Reply
adieguez

move in the pv at starting position

Post by adieguez » Thu Nov 05, 2009 12:13 am

Hi, several engines shows strange looking moves at the starting position. Like: playing e3/e6 instead of e4/e5 in the very first iterations (I mean iteration 1 or 2. For iteration more far away it is not that bad right?). Also moving the queen early. Why not fix that? even if it doesn't make the program stronger(just maybe, I doubt), it looks ugly.

This comes from an engine which is slighty stronger than amyan: (it moves the queen)

1 75 0 20 e2e4
2 45 0 34 e2e4
2 0 0 79 e2e4 e7e5
2 0 0 150 e2e4 e7e5
3 30 1 325 e2e4
3 49 1 487 e2e4 d7d5 b1c3 d5e4 c3e4
3 50 1 574 e2e3
3 59 1 677 e2e3 d7d5 d1h5
3 59 1 692 e2e3 d7d5 d1h5
4 29 1 959 e2e3
4 -5 1 1315 e2e3 e7e5 d1h5 d8f6
4 -4 1 1427 e2e4
4 5 1 2107 e2e4 e7e5 d1h5 d8f6
4 5 3 2989 e2e4 e7e5 d1h5 d8f6
5 24 3 4122 e2e4 d7d5 d1h5 d5e4 f1c4
5 25 4 4787 e2e3
5 38 6 5828 e2e3 d7d5 b1c3 g8f6 f1d3
5 39 6 6501 b1c3
5 48 7 7705 b1c3 e7e6 e2e4 d8h4 d1f3
5 48 7 8085 b1c3 e7e6 e2e4 d8h4 d1f3
6 18 9 9546 b1c3
6 4 10 13040 b1c3 b8c6 e2e3 e7e5 d1h5 d8f6

you are welcome to provide any weird ouput from amyan at the openning.

plattyaj

Re: move in the pv at starting position

Post by plattyaj » Thu Nov 05, 2009 1:10 am

adieguez wrote:Hi, several engines shows strange looking moves at the starting position. Like: playing e3/e6 instead of e4/e5 in the very first iterations (I mean iteration 1 or 2. For iteration more far away it is not that bad right?). Also moving the queen early. Why not fix that? even if it doesn't make the program stronger(just maybe, I doubt), it looks ugly.
Does it really matter? The point of iterative deepening is to quickly get to a good move, not worry about what the first couple of plies give. Since bringing out the Queen early can show a quick win until a deeper search shows it isn't, that's hardly a bug.

Having said that, Schola's choices through the first two plies are either Nc3 or d4 so nothing to feel "embarrassed" about for me ... that comes later in the game ;)

Andy.

User avatar
JVMerlino
Posts: 929
Joined: Wed Mar 08, 2006 9:15 pm
Location: San Francisco, California

Re: move in the pv at starting position

Post by JVMerlino » Thu Nov 05, 2009 1:49 am

In my opinion, bad moves showing up in depth 1 PVs at the beginning of a game (or in an engine that doesn't use hash tables) just can't be considered a bug. All of that will depend on the order in which moves were generated.

In the case of the opening position, there are no captures or checks, so only engines that would generate the knight moves before pawn moves would be likely to get good PVs during the depth 1 search.

For example, here's Myrddin's output through depth 4:

Code: Select all

 1/ 1     2      7         5  a2a3
 1/ 1     3      7         7  a2a4
 1/ 1     7      7        13  c2c3
 1/ 1    10      7        15  c2c4
 1/ 1    14      7        37  b1c3
 2/ 2     0      7        85  b1c3 b8c6
 3/ 4    14      7       351  b1c3 b8c6 g1f3
 4/ 7     0      7       643  b1c3 b8c6 g1f3 g8f6
 4/ 7     6      7      1313  g1f3 c7c5 f3e5 g8h6
See what I mean? :)

But just as long as a reasonable move is chosen at the END of depth 1, that's fine.

Or am I missing a deeper point?

Many thanks,
jm

adieguez

Re: move in the pv at starting position

Post by adieguez » Thu Nov 05, 2009 2:24 am

Hi, I mean moves in the final pv of the iteration. In your case at iteration 1 was:

1/ 1 14 7 37 b1c3

maybe the only questionable moves are on this:

4/ 7 6 7 1313 g1f3 c7c5 f3e5 g8h6

that's the final real pv? am a really really weak player but it looks odd, specially Nh6.
JVMerlino wrote:In my opinion, bad moves showing up in depth 1 PVs at the beginning of a game (or in an engine that doesn't use hash tables) just can't be considered a bug. All of that will depend on the order in which moves were generated.

In the case of the opening position, there are no captures or checks, so only engines that would generate the knight moves before pawn moves would be likely to get good PVs during the depth 1 search.

For example, here's Myrddin's output through depth 4:

Code: Select all

 1/ 1     2      7         5  a2a3
 1/ 1     3      7         7  a2a4
 1/ 1     7      7        13  c2c3
 1/ 1    10      7        15  c2c4
 1/ 1    14      7        37  b1c3
 2/ 2     0      7        85  b1c3 b8c6
 3/ 4    14      7       351  b1c3 b8c6 g1f3
 4/ 7     0      7       643  b1c3 b8c6 g1f3 g8f6
 4/ 7     6      7      1313  g1f3 c7c5 f3e5 g8h6
See what I mean? :)

But just as long as a reasonable move is chosen at the END of depth 1, that's fine.

Or am I missing a deeper point?

Many thanks,
jm

User avatar
michiguel
Posts: 6246
Joined: Thu Mar 09, 2006 7:30 pm
Location: Chicago, Illinois, USA
Contact:

Re: move in the pv at starting position

Post by michiguel » Thu Nov 05, 2009 3:27 am

plattyaj wrote:
adieguez wrote:Hi, several engines shows strange looking moves at the starting position. Like: playing e3/e6 instead of e4/e5 in the very first iterations (I mean iteration 1 or 2. For iteration more far away it is not that bad right?). Also moving the queen early. Why not fix that? even if it doesn't make the program stronger(just maybe, I doubt), it looks ugly.
Does it really matter? The point of iterative deepening is to quickly get to a good move, not worry about what the first couple of plies give. Since bringing out the Queen early can show a quick win until a deeper search shows it isn't, that's hardly a bug.
It matters because it shows the weak side of the engine. It is not a bug, it is just the tip of the iceberg. An iceberg of lack of opening understanding. Gaviota is guilty of that and bothers me. For instance, historically many strong engines shows in the PV e4 d5 2. exd5 Qxd5 3. Nc3 Qe6+? or any variation of d4 and blocking the c pawn with Nc3. Not really up to par with the strength they show in the middlegame.

Miguel
Having said that, Schola's choices through the first two plies are either Nc3 or d4 so nothing to feel "embarrassed" about for me ... that comes later in the game ;)

Andy.

User avatar
JVMerlino
Posts: 929
Joined: Wed Mar 08, 2006 9:15 pm
Location: San Francisco, California

Re: move in the pv at starting position

Post by JVMerlino » Thu Nov 05, 2009 6:19 am

adieguez wrote:Hi, I mean moves in the final pv of the iteration. In your case at iteration 1 was:

1/ 1 14 7 37 b1c3

maybe the only questionable moves are on this:

4/ 7 6 7 1313 g1f3 c7c5 f3e5 g8h6

that's the final real pv? am a really really weak player but it looks odd, specially Nh6.
It's more than odd, it's terrible. :) That's why we have opening books. But to defend my engine just a bit, I did use a version in progress in which I think there's a new search bug. Here's what my last public release does:

Code: Select all

 1     2     15         5 a2a3
 1     3     15         7 a2a4
 1     7     15        13 c2c3
 1    10     15        15 c2c4
 1    14     15        37 b1c3
 2     0     15        85 b1c3 b8c6
 3    14     15       316 b1c3 b8c6 g1f3
 4     0     15       616 b1c3 b8c6 g1f3 g8f6
Then again, some other engines in Myrddin's ELO range definitely play not-exactly-GM openings either. For example, Faile, which does almost the exact same thing.

Code: Select all

  1        51        4            23    1. Nf3
  2         1        4            83    1. Nf3?
  2         0        4           143    1. Nf3 Nf6
  3        50        4           201    1. Nf3!
  3        51        4           302    1. Nf3 Nf6 2. Nc3
  4         1        4           795    1. Nf3? Nf6 2. Nc3
  4         0        4          1322    1. Nf3 Nf6 2. Nc3 Nc6
jm

pijl

Re: move in the pv at starting position

Post by pijl » Thu Nov 05, 2009 7:00 am

Not really strange things in the Baron, other than that it chooses 1.c4 with white at some point and a Sicilian with black in the later plies ...
The first ply is generally move generation order as the rootnode has no sorting in the first iteration (needs search data before it starts sorting).
Don't look at the time as I need a special debug version to get the first plies in the output and I ran it on a slow machine.
Richard.

Code: Select all

ply   score   time           nodes pv
 1&  -0.192   0:00.00            3 a2a3
 1&  -0.096   0:00.00            7 a2a4
 1&  -0.016   0:00.00           11 b2b3
 1&   0.080   0:00.00           19 c2c4
 1&   0.208   0:00.00           23 d2d3
 1&   0.288   0:00.00           27 d2d4
 1&   0.304   0:00.00           33 e2e4
 1.   0.304   0:00.00           53 e2e4
 2&   0.096   0:00.00          109 e2e4 e7e5
 2.   0.096   0:00.00          216 e2e4 e7e5
 3&   0.128   0:00.03          559 e2e4 d7d5 d2d3
 3&   0.144   0:00.03          713 d2d4 d7d5 g1f3
 3.   0.144   0:00.03         1321 d2d4 d7d5 g1f3
 4&   0.096   0:00.04         1804 d2d4 d7d5 g1f3 g8f6
 4.   0.096   0:00.04         3383 d2d4 d7d5 g1f3 g8f6
 5&   0.096   0:00.06         6111 d2d4 d7d5 e2e3 g8f6 g1f3
 5&   0.160   0:00.06        10001 e2e4 d7d5 e4d5 d8d5 d2d4
 5.   0.160   0:00.07        12889 e2e4 d7d5 e4d5 d8d5 d2d4
 6&   0.064   0:00.12        27143 e2e4 d7d5 e4e5 c7c5 d2d4 c5d4 d1d4
 6&   0.096   0:00.14        34139 d2d4 d7d5 e2e3 g8f6 g1f3 e7e6
 6.   0.096   0:00.18        45955 d2d4 d7d5 e2e3 g8f6 g1f3 e7e6
 7&   0.080   0:00.26        74904 d2d4 d7d5 e2e3 g8f6 g1f3 e7e6 f1b5 b8c6
 7&   0.096   0:00.48       139542 c2c4 e7e6 b1c3 d7d5 c4d5 e6d5 e2e3
 7.   0.096   0:00.53       157816 c2c4 e7e6 b1c3 d7d5 c4d5 e6d5 e2e3
 8&   0.096   0:00.85       296095 c2c4 c7c5 e2e3 b8c6 b1c3 e7e6 g1f3
 8.   0.096   0:01.35       453699 c2c4 c7c5 e2e3 b8c6 b1c3 e7e6 g1f3
 9&   0.096   0:02.07       713902 c2c4 c7c5 e2e4 b8c6 g1f3 g8f6 b1c3 e7e5 d2d3
 9&   0.112   0:03.10      1071325 d2d4 d7d5 e2e3 g8f6 c2c4 c8f5 d1b3 b7b6 b1c3
 9.   0.112   0:06.07      2136702 d2d4 d7d5 e2e3 g8f6 c2c4 c8f5 d1b3 b7b6 b1c3
10&   0.128   0:10.43      3693133 d2d4 e7e6 e2e4 c7c5 g1f3 c5d4 f3d4 g8f6 b1c3 b8c6
10.   0.128   0:13.65      4816298 d2d4 e7e6 e2e4 c7c5 g1f3 c5d4 f3d4 g8f6 b1c3 b8c6
11&   0.096   0:28.40     10109832 d2d4 g8f6 c2c4 c7c5 e2e3 c5d4 e3d4 d7d6 b1c3 b8c6 g1f3
11&   0.128   0:38.82     13794308 e2e4 e7e6 d2d4 c7c5
11.   0.128   0:41.57     14816741 e2e4 e7e6 d2d4 c7c5
12&   0.096   1:17.23     27624805 e2e4 c7c5 g1f3 b8c6 d2d4 c5d4 f3d4 g8f6 b1c3 e7e5 d4c6 b7c6
12.   0.096   1:53.57     40313762 e2e4 c7c5 g1f3 b8c6 d2d4 c5d4 f3d4 g8f6 b1c3 e7e5 d4c6 b7c6
13&   0.112   2:47.57     59314632 e2e4 c7c5 g1f3 e7e6 d2d4 c5d4 f3d4 g8f6 b1c3 f8b4 c1g5 d8a5 g5d2
13.   0.112   3:42.92     78332957 e2e4 c7c5 g1f3 e7e6 d2d4 c5d4 f3d4 g8f6 b1c3 f8b4 c1g5 d8a5 g5d2

User avatar
hgm
Posts: 22210
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Contact:

Re: move in the pv at starting position

Post by hgm » Thu Nov 05, 2009 7:20 am

This is just total nonsense. e3 is not a bad opening move at all, and in many openings play e3 at some point. So you cannot blame and engine preferring it at low depth.

adieguez

Re: move in the pv at starting position

Post by adieguez » Thu Nov 05, 2009 12:56 pm

I don't think it is total nonsense, it was just the worst example. Play e3 with white at iteration 1 or 2 is not bad if the engine is actually more clever than it looks like.
hgm wrote:This is just total nonsense. e3 is not a bad opening move at all, and in many openings play e3 at some point. So you cannot blame and engine preferring it at low depth.

Post Reply