v0.5.2 remarks and questions

[tissatussa]

hi !

Congrats with the new v0.5.2, it runs fine in CuteChess, the v0.5.1 didn't ..

i see the engine uses a config file .. its options are poorly documented but i find more info about them in the README .. you could also add those info comments to the config file itself. although i set debug true, i see no PV lines in CuteChess (which i expected) .. i think these info lines are convenient, they show what the engine is thinking and how it decides best move at each depth. Also the values of time (spent), score (evaluation value in cp), nodes and the depth are missing - these are standard UCI data and CuteChess (our main reference) displays them - i guess these values are known by the process during calculation, so you could output them by a UCI info string .. you'll find them convenient yourself too :-)

searchDepth is low, i guess your pruning algorithm is simple and calculates a lot of nodes - value 5 often leads to a loss by time when playing a game - i know the engine is simple ..

you could implement those config settings into UCI options with default values, CuteChess will display them nicely in the concerning pane .. i did it myself when trying to build a simple engine :

those UCI options are simple to implement and they're convenient : the user can set custom values and CuteChess will save them.

what does "Search extensions config" mean ? Should it always be 1 ?

i'm trying to win against searchDepth 4 .. when i succeed i will update this post !

[tissatussa]

Replay this game here

[Event "human vs engine"]
[Site "Holland"]
[Date "2024.07.17"]
[Round "?"]
[White "Catto v0.5.2 dp4"]
[Black "Roelof Berkepeis"]
[Result "0-1"]
[ECO "A45"]
[GameDuration "01:10:57"]
[Opening "Queen's pawn game"]
[PlyCount "122"]
[TimeControl "1500+3"]

1. d4 {3.0s} Nf6 {3.2s} 2. Nc3 {6.5s} d5 {9.2s} 3. Bf4 {13s} a6 {9.6s}
4. Nf3 {12s} e6 {17s} 5. Ne5 {24s} b6 {75s} 6. e3 {47s} Bb7 {30s} 7. Bd3 {138s}
c5 {2614s} 8. O-O {131s} Nc6 {8.0s} 9. Nxc6 {25s} Bxc6 {4.4s} 10. Rc1 {52s}
Bd6 {55s} 11. Bxd6 {9.0s} Qxd6 {4.6s} 12. dxc5 {6.5s} bxc5 {15s} 13. a4 {31s}
O-O {35s} 14. Re1 {26s} Nd7 {23s} 15. a5 {25s} f5 {24s} 16. Qh5 {28s} Nf6 {7.8s}
17. Qh3 {38s} Rab8 {62s} 18. b3 {26s} Be8 {80s} 19. Qg3 {16s} Qxg3 {46s}
20. hxg3 {3.0s} Bb5 {14s} 21. Nxb5 {1.2s} axb5 {1.8s} 22. a6 {1.3s} Rf7 {7.2s}
23. Ra1 {8.4s} Ra7 {1.9s} 24. Ra5 {10s} c4 {3.2s} 25. Be2 {4.1s} Ne4 {60s}
26. Rd1 {22s} Nc3 {13s} 27. Rd2 {3.8s} Nxe2+ {2.0s} 28. Rxe2 {2.4s} Rb6 {2.0s}
29. g4 {2.6s} Raxa6 {8.9s} 30. Rxa6 Rxa6 {1.5s} 31. gxf5 {0.62s} exf5 {2.0s}
32. Rd2 {1.1s} Rd6 {4.0s} 33. bxc4 bxc4 {1.5s} 34. c3 Kf7 {3.6s} 35. Kh2 {1.0s}
g5 {4.7s} 36. Kg3 {1.2s} Ke6 {3.0s} 37. Rb2 {0.96s} Ke5 {7.6s} 38. Rb7 {1.2s}
h5 {1.8s} 39. f4+ {0.98s} gxf4+ {17s} 40. exf4+ Ke4 {6.6s} 41. Re7+ {1.6s}
Kd3 {2.0s} 42. Rf7 {1.9s} Kxc3 {14s} 43. Rxf5 {0.82s} d4 {7.6s} 44. Rxh5
d3 {1.5s} 45. Rh8 {2.5s} d2 {2.2s} 46. Rh1 {4.5s} d1=Q {4.0s} 47. Rxd1 {0.66s}
Rxd1 {1.2s} 48. f5 {0.71s} Kd4 {4.8s} 49. Kf4 {0.78s} c3 {2.7s} 50. f6 {0.86s}
c2 {2.3s} 51. Kf5 {4.1s} c1=Q {3.9s} 52. g4 {16s} Rf1+ {4.7s} 53. Kg6 {15s}
Qc2+ {8.6s} 54. Kg7 {27s} Qg2 {8.9s} 55. Kf7 {8.8s} Qxg4 {1.9s} 56. Ke7 {8.3s}
Qc8 {20s} 57. Kf7 {6.0s} Ke5 {9.7s} 58. Ke7 {8.4s} Qe6+ {8.4s} 59. Kf8 {7.1s}
Rxf6+ {3.1s} 60. Kg7 {2.5s} Rf7+ {2.5s} 61. Kg8 {5.6s} Qe8# {1.6s, Black mates}
0-1

[nguyenphuminh]

Thanks for the very detailed suggestions, I will soon add more useful configurations and logs into the uci client. The comments will be added to the config file as well, but currently I'm working mostly on improving the performance.

As for the performance issue, I think the main problem is not really the search algorithm, but rather the board implementation which is an external lib not implemented by me. A few months ago I logged out the amount of searched nodes and the number is not high at all, so it must have been the board that is slowing things down. I will probably implement bitboards soon.

what does "Search extensions config" mean ? Should it always be 1 ?

Oh it just meant that the engine will not extend pass that limit.

Thanks again!

[tissatussa]

About bitboards and move generation. I guess you will create new code for that yourself because Catto is written in Typescript and no / few modules will exist. However, it's an interesting topic and you can learn a lot.

At https://github.com/spamdrew128/Apotheosis i read :

Analog Hors ( https://github.com/analog-hors/tantabus ) Hors helped me so much early on in the development process, especially with move generation. Her amazing article on magic bitboards ( https://analog-hors.github.io/site/magic-bitboards/ ) is the reason I understand them as well as I do, and her webperft program ( https://analog-hors.github.io/webperft/ ) was immensely helpful for debugging my movegen code.

Also see https://github.com/nkarve/surge A fast bitboard-based legal chess move generator, written in C++

And take a look at this page: https://www.chessprogramming.org/Titboards

HTH

[tissatussa]

i see you created v0.6.0 .. i'm closing this Issue now.