unclear Turo ply count while mate #2
Comments
|
NOTE: i just discovered at ply 7 the Turo version DOES play Qh5+ and mates .. so it's my misunderstanding of plies ? |
|
Thanks for reporting this issue. I would also expect it to find the mate at 6 ply (unless it ran out of time and cut it short or some such). Let me take a closer look -- do you have the PGN for the game? Or just the FEN? |
|
the first diagram is after 10...e5 the second diagram is after 11. Nxg5 fxg5 |
|
btw. while trying to reproduce this game, i let the Black engine (my own script) play against your Morlock Turo depth 6 again, and it seems Turo does not always play the same moves .. eg. its first move may be 1.d4 or 1.Nc3 .. also in the above game, move 15 (Rg2) can be Kd2 .. why does Morlock Turo does not play the same moves all the time? It's a simple engine .. |
|
btw. i did set a starting FEN, which is the normal starting position without castling rights, because "ARBE" v0.1 can not castle yet and it doesn't recognise such move made by the opponent .. |
|
Re different moves: I added a bit of randomness to Turochamp (and Sargon) evaluation to prevent them being deterministic and thus more fun for repeated play imo. You can remove that by modifying the setup here: https://github.com/herohde/morlock/blob/main/cmd/turochamp/main.go#L45. The problem seems to be with the mate-in-X computation with the quiescence search and transposition tables. If I disable the transposition tables, I get the correct move. The console mode makes it easier to try: Turochamp searches captures as a "considerable move", so it finds the mate at depth 4. A deeper search can't improve on a mate in 5 ply (M5). I can repro the poor move, if I do a prior search from I'll look closer into that bug. Thanks for reporting it. |
|
Thanks for your time to investigate this, i thought you could be curious to find the cause of this Issue, because you're the creator of this script. Indeed randomness is more fun for repeated play, but I have no objection when your TuroChamp version strictly implements the original evaluation rule and thus plays the same moves all the time. Users might even expect that, eg. for evaluation of those original rules in certain positions. Therefor i suggest you create an UCI option for a parameter like "add some randomness" ? I know such UCI (checkbox, selectbox, etc) options are easy to code, and CuteChess nicely displays them in its settings pane. Other UCI options might be Depth, logging On/Off, and even selecting a different set of evaluation values ? |
|
Appreciate it. Thanks for the suggestion. Depth and Noise (= evaluation randomness) are now UCI options for convenience. |
i really like your newest v0.89.2.0 : those UCI options for then i did some tests in CuteChess, using 13 min + 10 sec bonus, setting about the these are just some questions and remarks. |
|
Glad that it was helpful! Re noise: The engine uses an evaluation score in "pawns" as a nominal value. The noise adds a randomness in milli-pawns. So 1,000 noise means +/- 0.5 pawns. The UCI option unfortunately does not allows an inline description to these options. However, as you can tell from reading the original paper, Turochamp does not use "pawns" as a scoring value, but rather the tuple of (material ratio, position play). The implementation here combines them into a "pawns" score but it is in reality not in pawns: see https://github.com/herohde/morlock/blob/main/cmd/turochamp/turochamp/eval.go#L20. The scoring is also made more symmetrical to make it more stable and work with odd search depths. The (arbitrary) UCI maximum of 10k is indeed small compared to the material ratio. But larger noise will drown out position play. Re depth: The time control assumes that there are 40 moves left in the game to manage time, see https://github.com/herohde/morlock/blob/main/pkg/search/searchctl/timectrl.go#L26. This simple heuristic makes it hard to run out of time, but is overly conservative later in the game. The search implementation is indeed not very sophisticated. I found it more enjoyable to to focus on the low depths, where search does not hide the engines' quirks. At low ply, search efficiency does not matter. Also, Sargon has some score factors that are relative to the root position, which makes transposition table scores unreliable to reuse from past moves. In other words, these old engines have some features that do not fit easily into modern search optimizations. Turochamp specifically uses an unbounded quiescence search of "considerable moves", which may be expensive. Sargon similarly has a non-standard quiescence search heuristic. Not sure I understand your last question. Can you elaborate? |
|
thanks for the extensive reply and insights, it's also valuable info for other users, reading about this (i could have created a seperate Issue for it?). my last question .. you mean tell us your ideas to implement these Morlock engines, esp. the Turochamp version ? well, i guess Turin didn't use recursion upto depth 6 or so, while calculating on paper .. so did you add some own ideas into this, eg. handling odd plies ? (i see the node counts in CuteChess sometimes show very low -30 or so- at some odd depth ? while normally the node count always goes up while reaching higher depths. i also have my own ideas .. i could tweak the evaluation (not the search) with some own factors, like PSTs .. i'm not familiar with GO though .. maybe i should use the Nim version, a language i learned lately .. btw. i must yet read those linked docs. |
|
Gotcha. My goal with Turochamp (and Sargon) was to implement it as faithfully as possible to the paper, but in a more standard engine framework. The only tweak I really made was to make the position-play evaluation symmetrical and fit the heuristics into a signed "pawns" score. The symmetry tweak was to counter some overly dubious moves at ply 1 that made it less fun, if I recall correctly, not improve the evaluation per se. |
|
overall your explanation is clear to me, and valuable ! Sounds like you did a lot of experiments and tests to get proper results. Btw. for now i only focus on the Turochamp engine, i understand those Rules Turin described in his paper and i think i agree .. i'm rather surprised how well your version plays with higher depth setting - myself i can hardly win .. after my tests i tend to conclude its rating is about 1300 - me 1800 !? about the "pawns" score : it seems (when using by threshold i mean : when this is my idea in a nutshell .. are you willing to discuss such further ? i can open an Issue for it. |
|
I realized that I broke the noise functionality when I moved it around for UCI. The noise option had no effect. That's now fixed. Sorry about causing confusion. The score values for Turochamp don't fit the usual pawn interpretation. For example, black to move with the white queen en prise: The scores are from blacks point of view in pawns, where positive is ahead. Taking the queen is vastly better than any other move, but obviously not worth more than 1000 pawns (most engines would score it as ~9 pawns ahead). That is just an artifact of combining "material ratio" and "position play" difference into a single score, where the ratio always dominates. The ratio of 1.32 is encoded as 1320 pawns and the position play score of 3.4 is encoded as 0.34. Even losing a single pawn with g7-g5, for example, bring a losing -1.02 ration -- expressed as -1020 "pawns". This is where the modern emphasis on scoring everything in "pawns" clash with Turing's design. Back to noise: the values are quite close -- they are often just a few centi-pawn apart the way the score is combined. The noise random element just aims vary the play. It's not contempt or anything clever. If noise is high enough, any move can be the best move and the play is random. The starting position: Using noise of 100 (= +/- 5 centipawns), for example, either e2-e3 or e2-e4 could be the initial best move. (Note that the console mode breakdown does not use noise or transposition tables, even if the actual search does.) |
|
regarding Turochamp : in main.go line 24 i see :
how can we see this output in console ? |
|
You can see the command line options by passing You can set the noise and ply defaults via the command line. The other are logging settings. You can use the console mode by passing In a previous comment, I indicated some commands in that mode with |
|
nice ! this is exactly what i hoped for .. so "a" is "analyse" .. that explains your output, thanks! [ i decided to close this Issue now, our info tends to go beyond the subject ] |
hi,
using your Morlock Turo version, i just encountered a strange move by the engine, considering i set ply 6 in this game :
here White (Turo ply 6) played Nf3xg5! which is a good move, making the white squares free for the Queen to give check and attack the opponent King .. Black took the kNight and we have this position :
now i expected Turo to play Qh5!, justifying the kNight sacrifice, but it didn't : it played dxe5? .. and after Kf7 Qh5+ Kg7, Black survived the attack ..
but Qh5+ is mate-in-3, isn't it ? : Qh5+ Kd7 {the only move} Bh3+ g4 {again the only move} Bxg4#
i count 6 plies, so why doesn't Morlock Turo find the mate ?
The text was updated successfully, but these errors were encountered: