unserializable wrote: ↑
Thu Nov 05, 2020 6:21 pm
Hey Marcel, congrats on the effective underpromotion and thanks for the kind words!
Wish you a persistence with Rustic -- writing chess engine from scratch is no simple feat and you seem to be doing excellently. Currently I can fairly say that my basic chess engine is much more basic than yours
These alpha-beta & threading & PSQs & ... even MVV-LVA are powerful features & Monchester will probably fall between 800-1000 on CCRL 404, whereas Rustic in 1500-1700 range, as I understand from your latest posts on Rustic.
There are two ways to get the engine to keep receiving information while the search is running:
1. Peek into the keyboard buffer from the search (many programs in C use this).
2. Run the UCI/XBoard communication in a different thread, and send the information to the search thread.
Without some stunts and fancy flying using so-called "unsafe code", option 1 isn't possible in the Rust programming language. Therefore I use threads... and they're not your grandpa's threads. In Rust, threading is built right into the language and standard library, and once you 'get' the concept, it's very easy and logical.
You're right: I estimate Rustic to be somewhere around 1600-1650 on CCRL's Blitz list at this point. As said, it has no features but basic move ordering and PSQT's. It overperforms against some engines because it is very fast compared to many other 1500-1800 engines... but it sometimes also underperforms, because it's still stupid. It can sometimes tactically crush a CCRL 1800 engine like an egg because it outcalculates it by 3 ply in the middle game, and then be steamrollered by a CCRL 1500 engine because it doesn't know what king safety or a passed pawn is.
Alpha-Beta and MVV-LVA are basic features to get right in your engine to stand a chance of it ever having a decent search; and PSQT's aren't that hard either. Do you need assistance with this? I (and others) could easily explain this and/or show you some code.
Monchester recognizes repetitions, 50-move draws and insufficient material positions, counts material, gives piece placemet bonus to knights
only, values knights
higher than bishops and considers one bishop to be worth ... 8 pawns
-- I have tried to keep the logic and illogic for 1.0 release same as it would have been, had I managed to solve memory usage errors 18 years ago, while making code stable, faster, clearer and dependable. The constant search depth should give Monchester 1.0 also some reference quality, as it will play the same as it does today in 10 or 50 years from now.
That is true; but you could implement a "go depth" (or the xboard equivalent), so your engine will then search to that depth and stop. In UCI, this is one of the standard commands an engine is expected to have. I assume it is in XBoard as well. (I still have to implement this interface.)
The thing that I have found interesting is just how much hopeful struggle inexperienced human players have, beating or trying to beat blundering Monchester (as they do blunder too). I intend to check out Rustic one day, as I have neither compiled or written or really read any Rust code and would like to have basic familiarity with Rust toolchain and then try to beat your engine, before it becomes a monster. Hope you play a game or two with Monchester one day too
One of the things I noticed is that even a basic chess engine is a tactical monster (compared to an average club player) if it can see 7-10 moves deep. It plays one innocuous move, which makes you think: "Why did it do that?" You can't find the reason, shrug your shoulders, and make your perfectly normal and natural move... and then the engine starts tearing you apart.
And you think: "But it doesn't work, because I'm now going to.... Aaargggh." And THEN you see, that this quiet move you couldn't figure out 10 moves ago, just HAPPENS to have put that bishop in JUST THAT position which blocks you from making precisely THAT move you just reached for, which makes the engine's combination work.
-- 1.0 release is coming along nicely, but so far I have not gotten any comments on Mac binaries -- I would really appreciate them, as neither myself nor my friend who compiled them was not exactly familiar with the process of distributing software for Mac. We discovered together that Mac does not really have quite the same static binary concept as in Linux, so we were forced to compile dynamic one -- confirmation or disconfirmation of Mac binary functionality would give some desired clarity
Sorry... can't help you there. I don't have a Mac, and I don't plan to get one. I might supply Mac binaries at some point, but they will be untested... or someone else has to compile Rustic for Mac.