TalkChess.com

Well hello again everybody. Martin Bryant here... author of the White Knight and Colossus programs back in the infancy days of micro computer chess. The last version of my UCI engine was 2008b! Where did the last 11 years go?! Anyway... as I'm now approaching retirement I've been giving some thought as to how to fill my time and inevitably dusting of the Colossus code was an option. I have been working on it for about a month now and 'engine fever' has certainly taken hold again! With 64-bit processors being ubiquitous these days the first thing I have done is to recode Colossus to use bitboards. Aren't they elegant?! The new version is now producing correct Perft counts and playing whole games without error. It's much simplified compared to 2008b as I stripped out a mountain of extensions/reductions/EGTB/immediate-mates/etc code just so that I could see the wood for the trees during the bitboard reconstruction. It's playing at a level marginally below 2008b at the moment but hopeful that when I start putting stuff back in it will eventually be an improvement. Fingers crossed!

Anyway... to the subject of the post... I recall seeing years ago a contrived mate-in-1 which gave some engines trouble as it blew up the quiescence search. It's not that important but I just wanted to find it again to see how Colossus fared, but sadly I can't find it anywhere
From what I can remember it had 3 (or maybe 4?) rows of pieces (lots of promoted queens) across the middle of the board with the victim King on h3 I think and an attacking queen (probably on a1?) waiting to deliver Qh1 mate.

Does anyone else remember this position (or one similar) and could provide a link to an earlier post or the FEN? Hope I've given enough info... sorry I can't remember anything more specific.
Many thanks!

Maybe the position in the following discussion:
viewtopic.php?f=7&t=20727&hilit=mate+qu ... 10#p190985

Sadly not that one but thank you anyway. It had like a thick stripe of opposing pieces across the centre ranks of the board all of which could take and re-take each other with reckless abandon.

Sorry but not that one either
I'd seen that one when I was looking the other day... it's cute but doesn't really test Colossus as it just happens to search the mating capture first at the root. Thanks anyway.

[d]8/8/pppppppK/NBBR1NRp/nbbrqnrP/PPPPPPPk/8/Q7 w - - 0 1

Indeed, I still remember this position well for some reason too even though it was posted almost 20 years ago now. It's good to see your return to computer chess.

Welcome back! I'm looking forward to testing Colossus 2019.

That's the one!
Thank you so much... I knew I could rely on you guys.

These are all very interesting positions.

Clearly, Q-search needs to be limited, or else cases like this may cause an explosion in Q-search positions. Having "check" as the #1 priority in QSearch seems to work in THIS case, but the general problem still exists. That is: Q-search can "explode" in some obscure cases.

Coming up with a sane and reasonable QSearch bounds seems important for engine developers.

This is a corner case. I am not sure it is worth optimizing for.

Arasan solved this in 21 seconds (1 core, Xeon 2690v3), 18.7M nodes.

--Jon