New release: chess22k v1.1

[sandermvdb]

I've just released the 2nd version of my engine: chess22k v1.1.
It is build in Java and the elo score is about 2400 (64 bit JRE).
On to the 2500!

For source and binary, see:
https://github.com/sandermvdb/chess22k

[tmokonen]

Thank you for your engine. It works well here in Arena. It is competitive with the 2400-2500 range engines that I tried it against.

[cdani]

Congratulations!!

[SzG]

Thanks for your engine. I'm looking forward to testing it.

[sandermvdb]

Thanks for your engine. I'm looking forward to testing it.

I'm looking forward to your test results

[Guenther]

Thanks for your engine. I'm looking forward to testing it.

I'm looking forward to your test results :)

Thanks for the release.

Here is just a quick and dirty test game to check if it runs smoothly here.
Note that it was handicapped by playing w/o any book when Abrok was out of its own small book after move W2.
This was under Winboard 4.9.170105 via Polyglot.

We can see that the time usage is not optimal yet at least for mps tcs.
The tc was 40 moves in 3 minutes and it only used around 65% of the available time until move 40.
(I enabled a special time display mode, which always shows the total rest time)
The plain pgn can be seen and copied by e.g. clicking on 'c8' on the board.

I also noticed that it does not send the used time info (yet?)
BTW does it use hashtables? The usual java flag doesn't work at least.
(sth like -Xmx256M)

Guenther

[pgn][Event "RWBC"]
[Site "CAPPUCCINO"]
[Date "2017.02.10"]
[Round "-"]
[White "Chess22k_11"]
[Black "Abrok 5.0"]
[Result "1-0"]
[TimeControl "40/180"]
[Annotator "1. +0.24 2... -0.64"]

1. e4 {+0.24/10 +176} g6 {+0.02/99 +179} 2. Nc3 {+0.82/10 +174} Bg7
{-0.64/12 +176} 3. d4 {+0.94/11 +169} d6 {+0.02/99 +176} 4. Nf3
{+0.88/10 +166} Nf6 {+0.02/99 +176} 5. Be2 {+0.88/9 +164} O-O
{+0.02/99 +176} 6. Bf4 {+0.71/10 +161} c5 {-0.46/11 +170} 7. dxc5
{+0.69/10 +158} dxc5 {-0.44/11 +164} 8. e5 {+0.66/10 +155} Nh5
{-0.44/11 +159} 9. Be3 {+0.35/11 +150} Nc6 {-0.44/11 +154} 10. Qd5
{+0.35/10 +148} Nb4 {+0.30/11 +149} 11. Qb3 {+0.31/10 +145} Be6
{+0.16/11 +143} 12. Qa4 {+0.13/10 +142} Bd7 {+0.16/11 +138} 13. Bb5
{+0.21/11 +136} Bf5 {+0.34/10 +133} 14. Rd1 {+0.21/10 +134} Qb6
{+0.58/10 +129} 15. Rd2 {+0.10/9 +131} Rfd8 {+0.68/10 +124} 16. O-O
{+0.02/9 +128} Rxd2 {+0.92/11 +119} 17. Bxd2 {-0.16/11 +125} Rd8
{+0.88/11 +114} 18. Bc4 {+0.01/9 +123} Nc6 {+0.90/10 +110} 19. e6
{-0.05/9 +119} Bxe6 {+1.14/10 +106} 20. Bxe6 {-0.38/10 +117} fxe6
{+0.84/11 +100} 21. Qc4 {-0.28/10 +115} Nd4 {+1.14/11 +96} 22. Nxd4
{-0.36/11 +111} Rxd4 {+1.42/12 +91} 23. Qe2 {-0.25/11 +110} Nf4
{+1.26/12 +86} 24. Qe1 {-0.30/11 +105} Qc6 {+1.16/10 +81} 25. Bxf4
{-0.34/11 +102} Rxf4 {+1.40/12 +76} 26. Qe3 {-0.33/11 +99} Rg4
{+1.28/12 +72} 27. g3 {-0.43/11 +96} Bd4 {+1.40/12 +67} 28. Qd2
{-0.41/11 +89} h5 {+1.18/12 +62} 29. Ne2 {-0.01/9 +87} Bxb2 {+1.12/11 +56}
30. c3 {+0.32/10 +85} Ba3 {+0.40/12 +51} 31. h3 {-0.13/10 +83} Ra4
{+0.60/11 +46} 32. Rd1 {+0.00/10 +81} e5 {+1.12/10 +43} 33. Qh6
{-0.22/10 +79} Qb6 {+0.80/12 +34} 34. Qe3 {-0.24/10 +78} Qc7 {+1.14/11 +30}
35. Rd5 {+0.31/11 +76} c4 {+0.52/11 +25} 36. Qe4 {+0.75/10 +74} Ra6
{+0.68/11 +22} 37. Rxe5 {+0.25/11 +73} Qc6 {+0.62/12 +17} 38. Rd5
{+0.00/11 +71} Rb6 {+0.14/11 +9} 39. Nd4 {+0.63/11 +67} Qf6 {+0.30/11 +6}
40. Re5 {+0.44/10 +243} Kh8 {+0.42/9 +183} 41. Nb5 {+0.55/12 +232} Bc1
{+0.24/11 +177} 42. a4 {+0.47/12 +217} a6 {+0.14/12 +167} 43. Nd4
{+0.43/12 +211} Ba3 {-0.08/12 +160} 44. a5 {+0.35/12 +189} Rb2
{-0.14/12 +154} 45. Qe3 {+0.59/12 +183} Kg8 {+0.96/11 +149} 46. Re6
{+0.26/12 +178} Qf7 {+0.58/12 +144} 47. f3 {+0.06/12 +173} Qg7
{+0.64/10 +140} 48. Qe4 {+0.41/11 +169} Kh7 {+0.00/11 +136} 49. f4
{+0.48/12 +163} Qf7 {+0.00/10 +131} 50. Re5 {+0.74/12 +157} Kh6
{-0.10/10 +127} 51. f5 {+1.09/12 +153} Kg7 {+0.00/10 +123} 52. Ne6+
{+1.36/11 +149} Kh8 {-0.02/11 +119} 53. Nf4 {+1.38/12 +141} g5
{-0.32/10 +114} 54. Ng6+ {+1.77/12 +137} Kh7 {-0.46/10 +111} 55. Nxe7
{+2.17/12 +131} Kh8 {-0.98/10 +104} 56. Re6 {+3.21/12 +125} Bc5+
{-1.32/10 +99} 57. Kf1 {+4.24/11 +121} Qg7 {+0.34/10 +91} 58. Ng6+
{+6.38/12 +118} Kh7 {-5.28/10 +84} 59. Ne5 {+8.18/12 +115} Kg8
{-5.22/9 +77} 60. Rg6 {+9.83/11 +111} Rf2+ {-7.58/7 +74} 61. Ke1
{+12.15/11 +108} Qxg6 {-9.70/8 +71} 62. Qd5+ {+18.47/12 +99} Kg7
{-9.96/8 +68} 63. Qd7+ {+22.79/12 +95} Kg8 {-11.08/9 +65}
{Xboard adjudication} 1-0
[/pgn]

[SzG]

BTW does it use hashtables? The usual java flag doesn't work at least.
(sth like -Xmx256M)

As far as I know Xmx256M has nothing to do with hash size, it's a memory allocation for java.exe.

However, it seems to me that chess22k does not have any parameters so you can probably not set the size of the hash table.

[sandermvdb]

We can see that the time usage is not optimal yet at least for mps tcs.
The tc was 40 moves in 3 minutes and it only used around 65% of the available time until move 40.

I also noticed that it does not send the used time info (yet?)

BTW does it use hashtables? The usual java flag doesn't work at least.
(sth like -Xmx256M)

I know that time usage is not optimal at the moment. This is something for the near future. With 40 moves in 3 minutes you mean that the game will always end when 40 moves have been played? I did not implement this scenario.

Is sending the used time part of UCI protocol? I will look into that.

It does use hashtables (transposition table, eval-cache and pawn-eval-cache). Should these be configurable?

[Guenther]

We can see that the time usage is not optimal yet at least for mps tcs.
The tc was 40 moves in 3 minutes and it only used around 65% of the available time until move 40.

I also noticed that it does not send the used time info (yet?)

BTW does it use hashtables? The usual java flag doesn't work at least.
(sth like -Xmx256M)

I know that time usage is not optimal at the moment. This is something for the near future. With 40 moves in 3 minutes you mean that the game will always end when 40 moves have been played? I did not implement this scenario.

It is called moves per session (mps), the session will be repeated e.g. 3 min/40 moves then again additional 3min/moves 41-80 and so on...
If it is not implemented yet that would explain it, because it probably thinks the time is for _all moves_ and I noticed it played already a bit slower in session 2 after the next time was added.

Is sending the used time part of UCI protocol? I will look into that.

yes.

It does use hashtables (transposition table, eval-cache and pawn-eval-cache). Should these be configurable?

yes, it would be better if those would be configurable, at least in the long run. (best via uci options)

Guenther

Edit: I have just another question, is Sander your first name?
I am asking this for filling in the data for my WB/UCI chronology ;-)

http://rwbc-chess.de/chronology.htm

[sandermvdb]

Yes