Critter 1.6 released!

rvida · Post by **rvida** » Sun Jun 17, 2012 1:51 pm

gaard wrote:I have an issue when I am using MultiPV where the PVs are sometimes identical.

Acknowledged. Murphy's law at its full strength - I use multiPV daily and haven't noticed this bug, but now it shows up almost in every other search

I will release a bug-fix update soon.

Richard

Jouni · Post by **Jouni** » Sun Jun 17, 2012 10:36 pm

Thanks for new version! There seems to be an "issue" in mate displaying. Example:

[D]1K1k2Nr/1P1ppPb1/2pp4/p4p2/3Pb3/1p2N1p1/3B3n/r5nq w - - 0 1

Analysis by Critter 1.6 64-bit 2CPU:

...
1.Ka7 Bxd4+ 2.Kb8 Bg7 3.Bc3 Bh6 4.Ka7 Bxe3+ 5.Kb8 Bh6 6.Bd2 Bd5 7.Bxh6 Rxg8 8.Ka7 e5 9.Bg5+ Rxg5 10.f8Q+ Kc7
+- (#11) Depth: 23/50 00:00:08 26749kN
1.Ka7 Bxd4+ 2.Kb8 Bg7 3.Bc3 Bh6 4.Ka7 Bxe3+ 5.Kb8 Bh6 6.Bd2 Bd5 7.Ka7 Be3+ 8.Bxe3 Bxf7 9.b8Q#
+- (#9) Depth: 24/50 00:00:13 47891kN
1.Ka7 Bxd4+ 2.Kb8 Bg7 3.Bc3 Bh6 4.Ka7 Bxe3+ 5.Ka8 c5 6.Ka7 c4+ 7.Kb8 Ba7+ 8.Kxa7 Kc7 9.b8Q+ Kc6 10.Nxe7+ Kc5 11.Qb6#
+- (#11) Depth: 25/57 00:00:20 76199kN
1.Ka7 Bxd4+ 2.Kb8 Bg7 3.Bc3 Bh6 4.Ka7 Bxe3+ 5.Ka8 c5 6.Ka7 c4+ 7.Kb8 Ba7+ 8.Kxa7 Kc7 9.b8Q+ Kc6 10.Nxe7+ Kc5 11.Qb6#
+- (#11) Depth: 26/57 00:00:35 140mN
1.Ka7 Bxd4+ 2.Kb8 Bg7 3.Bc3 Bh6 4.Ka7 Bxe3+ 5.Kb8 Bh6 6.Bd2 Bd5 7.Ka7 Be3+ 8.Bxe3 Bxf7 9.b8Q#
+- (#9) Depth: 27/57 00:00:45 182mN

Now Critter is leading CCRL FRC list

Why is Critter so good in that?

MM · Post by MM » Sun Jun 17, 2012 10:44 pm

[D]8/8/8/3k4/8/1r6/8/4K3 b - - 0 110

Ended in a draw.

It was Critter 1.4a vs Critter 1.6, both engines had less than 1 second remaining (sudden death).

Ponder was OFF.

[D]3K4/8/8/2q5/8/5k2/8/8 b - - 0 109

Ended again in a draw

Black is Critter 1.6, that had 0.9 seconds remaining (sudden death).

Ponder was OFF .

The time didn't finish. Simply, in both cases, the engine moved randomly for several moves and at the end it repeated three times the same position.

rvida · Post by **rvida** » Mon Jun 18, 2012 2:12 am

Jouni wrote:There seems to be an "issue" in mate displaying. Example:

This is not a bug, rather than a hashing related anomaly. Sometimes the engine discovers a particularly good move by pure luck. Due to hash-table overwrites it fails to remember what was the best move in the given position and on the next iteration it has to search again. At nodes close to the leaves it barely looks at moves other than captures and checks (on average only 1-3 quiet moves are considered). And since the move ordering depends on previous success/failures their order might change since last visiting this position.

You didn't specify which hash size you used. Try to use half of that, or double of that. Most probably this behavior will go away with a different hash size.

Here is a run with 1core & 128mb hash:

Code: Select all

17/46  00&#58;02    4444K   1769K  +0.00 Ka7 Bxd4+ Kb8 Bg7 Ka7 Bd4+
18/46+ 00&#58;03    5971K   1892K  +0.08 Ka7 Bxd4+ Kb8 Bg7 Ka7 Bd4+
18/46+ 00&#58;03    6082K   1891K  +0.21 Ka7 Bxd4+ Kb8 Bg7 Ka7 Bd4+
18/46+ 00&#58;03    6207K   1887K  +0.40 Ka7 Bxd4+ Kb8 Bg7 Ka7 Bd4+
18/46+ 00&#58;03    6358K   1883K  +0.69 Ka7 Bxd4+ Kb8 Bg7 Ka7 Bd4+
18/46+ 00&#58;03    6583K   1877K  +1.11 Ka7 Bxd4+ Kb8 Bg7 Ka7 Bd4+
18/46+ 00&#58;03    6858K   1877K  +1.75 Ka7 Bxd4+ Kb8 Bg7 Ka7 Bd4+
18/46+ 00&#58;03    7236K   1880K  +2.70 Ka7 Bxd4+ Kb8 Bg7 Ka7 Bd4+
18/46+ 00&#58;04    8028K   1901K  +4.13 Ka7 Bxd4+ Kb8 Bg7 Ka7 Bd4+
18/46+ 00&#58;04    8461K   1918K  +6.28 Ka7 Bxd4+ Kb8 Bg7 Ka7 Bd4+
18/46+ 00&#58;04    9178K   1956K  +9.49 Ka7 Bxd4+ Kb8 Bg7 Ka7 Bd4+
18/46+ 00&#58;04    9525K   1977K +14.31 Ka7 Bxd4+ Kb8 Bg7 Ka7 Bd4+
18/46+ 00&#58;04    9663K   1986K +21.54 Ka7 Bxd4+ Kb8 Bg7 Ka7 Bd4+
18/46  00&#58;04    9944K   2005K    +M9 Ka7 Bxd4+ Kb8 Bg7 Bc3 Bh6 Ka7 Bxe3+ Kb8 Bh6 Bd2 Bg7 Bg5 Bf8 Ka7 c5 b8=Q#
19/46  00&#58;05   10112K   2013K    +M9 Ka7 Bxd4+ Kb8 Bg7 Bc3 Bh6 Ka7 Bxe3+ Kb8 Bh6 Bd2 Bg7 Bg5 Bf8 Ka7 c5 b8=Q#
20/46  00&#58;05   11059K   2065K    +M9 Ka7 Bxd4+ Kb8 Bg7 Bc3 Bh6 Ka7 Bxe3+ Kb8 Bh6 Bd2 Bg7 Bg5 Bf8 Ka7 c5 b8=Q#
21/46  00&#58;05   12680K   2137K    +M9 Ka7 Bxd4+ Kb8 Bg7 Bc3 Bh6 Ka7 Bxe3+ Kb8 Bh6 Bd2 Bg7 Bg5 Bf8 Ka7 c5 b8=Q#
22/46  00&#58;07   17033K   2304K    +M9 Ka7 Bxd4+ Kb8 Bg7 Bc3 Bh6 Ka7 Bxe3+ Kb8 Bh6 Bd2 Bg7 Bg5 Bf8 Ka7 c5 b8=Q#
23/46  00&#58;08   21386K   2418K    +M9 Ka7 Bxd4+ Kb8 Bg7 Bc3 Bh6 Ka7 Bxe3+ Kb8 Bh6 Bd2 Bg7 Bg5 Bf8 Ka7 c5 b8=Q#
24/46  00&#58;12   32196K   2584K    +M9 Ka7 Bxd4+ Kb8 Bg7 Bc3 Bh6 Ka7 Bxe3+ Kb8 Bh6 Bd2 Bg7 Bg5 Bf8 Ka7 c5 b8=Q#

Jouni wrote: Now Critter is leading CCRL FRC list Why is Critter so good in that?

Maybe it just got a lucky day

Seriously, I don't know for sure, but it might be related to the fact that most of my test games are without books, and to avoid repeating games I use FRC starting positions. This could cause a side-effect of tuning for FRC (but I doubt the significance, I think of 5-10 points in best case)

rvida · Post by **rvida** » Mon Jun 18, 2012 2:18 am

MM wrote:...
Ended in a draw.

It was Critter 1.4a vs Critter 1.6, both engines had less than 1 second remaining (sudden death).

Ponder was OFF.

...

Ended again in a draw

Black is Critter 1.6, that had 0.9 seconds remaining (sudden death).

Ponder was OFF .

The time didn't finish. Simply, in both cases, the engine moved randomly for several moves and at the end it repeated three times the same position.

With or without tablebases?

MM · Post by MM » Mon Jun 18, 2012 10:48 am

rvida wrote:
MM wrote:...
Ended in a draw.

It was Critter 1.4a vs Critter 1.6, both engines had less than 1 second remaining (sudden death).

Ponder was OFF.

...

Ended again in a draw

Black is Critter 1.6, that had 0.9 seconds remaining (sudden death).

Ponder was OFF .

The time didn't finish. Simply, in both cases, the engine moved randomly for several moves and at the end it repeated three times the same position.
With or without tablebases?

Hi Mr Vida,

they happened without tablebases.

Best Regards

Jouni · Post by **Jouni** » Mon Jun 18, 2012 1:49 pm

Hi,

Yes I noticed that with 1 core no problem, but of course I use all available cores. And totally 1.6 solved less mates than 1.4 in my test run (difference can be noise). And in most other test suites 1.6 is BETTER.

Jouni · Post by **Jouni** » Mon Jun 18, 2012 7:35 pm

I did some testing. I can't see problem with version 1.4 as i remember only with 1.6. And it happens with 512 MB hash and 2 CPU at least (not with 256MB

). Another example:

[D]2k5/8/3KN3/2NNN3/8/8/3q4/8 w - - 0 1

Analysis by Critter 1.6 64-bit 2CPU 512MB:
...
1.Nc4 Qh2+ 2.Kc6 Kb8 3.Nd6 Qg1 4.Nb5 Qc1 5.Ne7 Qc4 6.Kb6 Qxb5+ 7.Kxb5 Ka8 8.Kb6 Kb8 9.Na6+ Ka8 10.Nec7#
+- (#10) Depth: 23/38 00:00:01 6795kN
1.Nc4 Qh2+ 2.Kc6 Kb8 3.Nd6 Qc2 4.Nb4 Qh7 5.Nd7+ Qxd7+ 6.Kxd7 Ka7 7.Kc6 Kb8 8.Kb6 Ka8 9.Nc7+ Kb8 10.Nba6#
+- (#10) Depth: 24/38 00:00:02 12702kN
1.Nc4 Qh2+ 2.Kc6 Kb8 3.Nd6 Qh7 4.Nd7+ Qxd7+ 5.Kxd7 Ka7 6.Kc6 Ka8 7.Nb6+ Ka7 8.Nc7 Kb8 9.Nd7+ Ka7 10.Ndb5#
+- (#9) Depth: 25/38 00:00:03 21392kN
1.Nc4 Qh2+ 2.Kc6 Kb8 3.Nd6 Qc2 4.Nb4 Qh7 5.Nd7+ Qxd7+ 6.Kxd7 Ka7 7.Kc6 Kb8 8.Kb6 Ka8 9.Nc7+ Kb8 10.Nba6#
+- (#10) Depth: 26/38 00:00:06 35607kN
1.Nc4 Qh2+ 2.Kc6 Kb8 3.Nd6 Qh7 4.Nd7+ Qxd7+ 5.Kxd7 Ka7 6.Kc6 Ka8 7.Nb6+ Ka7 8.Nc7 Kb8 9.Nd7+ Ka7 10.Ndb5#
+- (#10) Depth: 27/38 00:00:11 66315kN
1.Nc4 Qh2+ 2.Kc6 Kb8 3.Nd6 Qc2 4.Nb4 Qh7 5.Nd7+ Qxd7+ 6.Kxd7 Ka7 7.Kc6 Kb8 8.Kb6 Ka8 9.Nc7+ Kb8 10.Nba6#
+- (#10) Depth: 28/38 00:00:15 93175kN
1.Nc4 Qh2+ 2.Kc6 Kb8 3.Nd6 Qh7 4.Nd7+ Qxd7+ 5.Kxd7 Ka7 6.Kc6 Ka8 7.Nb6+ Ka7 8.Nc7 Kb8 9.Nd7+ Ka7 10.Ndb5#
+- (#9) Depth: 29/38 00:00:22 139mN

Now there are mate in 9 score but mate in 10 main lines..

Don · Post by **Don** » Mon Jun 18, 2012 9:49 pm

rvida wrote:
MM wrote:...
Ended in a draw.

It was Critter 1.4a vs Critter 1.6, both engines had less than 1 second remaining (sudden death).

Ponder was OFF.

...

Ended again in a draw

Black is Critter 1.6, that had 0.9 seconds remaining (sudden death).

Ponder was OFF .

The time didn't finish. Simply, in both cases, the engine moved randomly for several moves and at the end it repeated three times the same position.
With or without tablebases?

On Linux Critter does not run except on more recent Linux distributions - because it's dynamically liked. Larry is not able to run it because of that - and even though I can fix that for him it's going to be a pain for some users. Can you fix that?

Thanks,

Don

rvida · Post by **rvida** » Tue Jun 19, 2012 4:01 pm

Don wrote: On Linux Critter does not run except on more recent Linux distributions - because it's dynamically liked. Larry is not able to run it because of that - and even though I can fix that for him it's going to be a pain for some users. Can you fix that?

Thanks,

Don

Static linking of glibc is not officially supported. Some even consider static linking in general as harmful.

Easiest fix is upgrading the Linux distro. Most of them have very painless automatic update systems anyway.

Critter 1.6 released!

Re: Critter 1.6 released!

Re: Critter 1.6 released!

Re: Critter 1.6 released!

Re: Critter 1.6 released!

Re: Critter 1.6 released!

Re: Critter 1.6 released!

Re: Critter 1.6 released!

Re: Critter 1.6 released!

Re: Critter 1.6 released!

Re: Critter 1.6 released!