NGplay 9.87 64-bit released

[Graham Banks]

NGplay 9.87 64-bit released.

Hello dear chess friends,

After a long time interval, I finally managed to have some free time to update my engine ... NGplay... new vesrion 9.87

The version exists here : http://users.otenet.gr/~yggeorgo/NGplay_9.87_64bit.zip
sources : http://users.otenet.gr/~yggeorgo/NGplay_9.87.c

I had a match of 100 games (blitz time control) against version 9.85 ... result was 39-22-39 (wins losses draws).
This indicates an improvement of about 50 ELo points.

More tests will show exact result also in other time controls...

thanks
George Georgopoulos

[MikeB]

NGplay 9.87 64-bit released.

Hello dear chess friends,

After a long time interval, I finally managed to have some free time to update my engine ... NGplay... new vesrion 9.87

The version exists here : http://users.otenet.gr/~yggeorgo/NGplay_9.87_64bit.zip
sources : http://users.otenet.gr/~yggeorgo/NGplay_9.87.c

I had a match of 100 games (blitz time control) against version 9.85 ... result was 39-22-39 (wins losses draws).
This indicates an improvement of about 50 ELo points.

More tests will show exact result also in other time controls...

thanks
George Georgopoulos

apparently for me, the macOS version likes to resign early

[pgn][Event "Computer Chess Game"]
[Site "Mac-Pro.local"]
[Date "2017.02.25"]
[Round "-"]
[White "NGplay_9.87"]
[Black "Stockfish 8 64 POPCNT"]
[Result "0-1"]
[TimeControl "2+2"]
[Annotator "1... -0.45"]

1. e4 e5 {-0.45/20 2.0} 2. Nf3 Nc6 {-0.29/20 2.0} 3. Bc4 Nf6 {-0.21/20 0.9}
{White resigns} 0-1[/pgn]

[carldaman]

NGplay 9.87 64-bit released.

Hello dear chess friends,

After a long time interval, I finally managed to have some free time to update my engine ... NGplay... new vesrion 9.87

The version exists here : http://users.otenet.gr/~yggeorgo/NGplay_9.87_64bit.zip
sources : http://users.otenet.gr/~yggeorgo/NGplay_9.87.c

I had a match of 100 games (blitz time control) against version 9.85 ... result was 39-22-39 (wins losses draws).
This indicates an improvement of about 50 ELo points.

More tests will show exact result also in other time controls...

thanks
George Georgopoulos

apparently for me, the macOS version likes to resign early

[pgn][Event "Computer Chess Game"]
[Site "Mac-Pro.local"]
[Date "2017.02.25"]
[Round "-"]
[White "NGplay_9.87"]
[Black "Stockfish 8 64 POPCNT"]
[Result "0-1"]
[TimeControl "2+2"]
[Annotator "1... -0.45"]

1. e4 e5 {-0.45/20 2.0} 2. Nf3 Nc6 {-0.29/20 2.0} 3. Bc4 Nf6 {-0.21/20 0.9}
{White resigns} 0-1[/pgn]

Hi Michael,

try a weaker opponent, as against SF I would resign, too

CL

[MikeB]

NGplay 9.87 64-bit released.

Hello dear chess friends,

After a long time interval, I finally managed to have some free time to update my engine ... NGplay... new vesrion 9.87

The version exists here : http://users.otenet.gr/~yggeorgo/NGplay_9.87_64bit.zip
sources : http://users.otenet.gr/~yggeorgo/NGplay_9.87.c

I had a match of 100 games (blitz time control) against version 9.85 ... result was 39-22-39 (wins losses draws).
This indicates an improvement of about 50 ELo points.

More tests will show exact result also in other time controls...

thanks
George Georgopoulos

apparently for me, the macOS version likes to resign early

[pgn][Event "Computer Chess Game"]
[Site "Mac-Pro.local"]
[Date "2017.02.25"]
[Round "-"]
[White "NGplay_9.87"]
[Black "Stockfish 8 64 POPCNT"]
[Result "0-1"]
[TimeControl "2+2"]
[Annotator "1... -0.45"]

1. e4 e5 {-0.45/20 2.0} 2. Nf3 Nc6 {-0.29/20 2.0} 3. Bc4 Nf6 {-0.21/20 0.9}
{White resigns} 0-1[/pgn]

Hi Michael,

try a weaker opponent, as against SF I would resign, too

CL

LOL +1

[tmokonen]

9.86 is still there. Just change the 7 to a 6 in the links for 9.87.

[Graham Banks]

.....apparently for me, the macOS version likes to resign early

That's odd. No issues here.

[Ras]

I have been reviewing the changes for deciding which of them would be useful for the CT800, so maybe some people are interested what exactly has changed. Some of the improvements over v9.86 were already included in the CT800, and some of the others will be backported to the CT800.

NG-Play changes from v9.86 to v9.87:

- back rank safety is part of the king safety evaluation.
- trapped pieces recognised: e.g. "white bishop on a7 with black pawn on b6".
- blocked pieces recognised: e.g. "rook in the corner blocked by own king", "white bishop on the original square blocked by central pawn on e2/d2 with e3/d3 blocked by something else".
- knight piece square table modified.
- bishop/rook piece square tables removed.
- hash tables store the 64 bit value, not only the upper 32 bit.
- hash table cluster size reduced from 3 to 2, code simplification.
- hash table handling includes search tree distance from root position for mating scores.
- reverse futility depth reduced to 4, matching the forward futility depth.
- insufficient material draw recognised in search nodes, i.e. before the leaves.
- move generation for null move search deferred to late move generation in the next depth level.
- threat moves pushed up further in MVV-LVA during IID.
- no IID from root position because that is already handled in the pre-search.
- late move reduction: reduced depth if too many moves.
- important bugfix: pruned moves also count as legal moves. This avoids erroneous stalemate detection in the search, which lead to some lost games in v9.86.

- issue still in v9.87: main hash tables have one entry too few which might result in rare buffer overruns on the heap, potentially leading to segmentation faults. The risk is lower than with v9.86 which had two entries too few.

[Ras]

apparently for me, the macOS version likes to resign early

Does that also happen when you give a bit more time?

I faintly remember that v9.86 had that issue under very strict time controls when being forced to move more or less immediately, and that part of the code has not been changed.

[Ras]

After digging a bit deeper, that might well be a program issue even with correct time.

What's happening here: if the engine "somehow" believes it has nearly 0 thinking time on the first move, it will stop the iteration and break directly out of the IID loop. The score it still initialised to below -MATE, and that leads the engine to resign.

Now this "somehow" might well be a platform dependent issue when taking a look at how the time management is done. The central point here is:

Code: Select all

int GetMillisecs(void)
{
  struct timeb timebuffer;
  ftime(&timebuffer);
  return (timebuffer.time * 1000) + timebuffer.millitm;
}

This is trying to stuff the milliseconds since 01-01-1970 into an int. int is specified to have at least 16 bits, but probably, it is 32 bits on PC platforms. How many milliseconds does that give us? 2^31-1 because it is signed. That would be enough for 24 DAYS since 01-01-1970.

Now it depends on when it actually overflows, how the compiler implements that and what compiler optimisation exploits the undefined behaviour that signed integer overflow constitutes. Basically, anything would be allowed to happen.

[Ras]

You could try this version v9.87a where the time issue is fixed by changing the data type to "long long int", that is enough milliseconds from 01-01-1970 to cover 292 years.

Note that NG-Play subtracts 100ms from the configured move time as to always be "on time". If you use the interactive terminal mode to configure "0 seconds" in v9.87, you will see that it resigns as soon as it is out of book.

v9.87a will use the move from the 3 ply pre-search instead of resigning, using it as "fail-safe move".

Besides, the hash table allocation size is also fixed as to prevent stability issues.

Windows binary build is with GCC 4.8.3 under MingW-64 using g++ and -O03. The compiler version is old, but it matches the one that has been used for v9.87. No idea how to generate a binary for Mac, but the C source is included.

http://www.ct800.net/download/NGplay_9.87a_64bit.zip