hgm wrote:CThinker wrote:And btw, Harm, I'm surprised that you used the 'easy' command as an example:
Code: Select all
C:\Temp\umax>umax.exe
tellics say micro-Max 1.6w
tellics say by H.G. Muller
easy
Error (unknown command): easy
hard
Error (unknown command): hard
quit
C:\Temp\umax>
Well, that I am a lazy SOB does not imply others should be forgiven for acting the same way!
Micro-Max cannot ponder at all, and I guess replying "unkown command" to "hard" is a good way to let the GUI know about it. (Not that any existing GUI does anything with that info...). But I agree that it is not logical to give the same to "easy". Note that uMax 1.6w has not been worked on from the time I first released it as a WB engine, which was at a time when I did not work on WB at all, and hardly knew the protocol. My current policy is to let my engines recognize all WB commands that are sent by default, even if only for the purpose to ignore them (like "computer", "ratings", "otim" etc.).
You have point about existing protocols being tailored for a specific implemetation of a chess engine (tree search with iterative deepening). But I am pretty sure Thinker does get its moves that way. So this in itself is no excuse for violating the protocol. In the end you get a PV somehow, don't you? It would already be a great improvement if you print that PV before printing the move (so it is not discarded as ponder output, and ends up in the PGN file).
For me looking at the depth/score and PV info is all the fun. Without it, computer Chess is quite meaningless. This was rubbed in again recently, when I converted some XQ engines from another protocol to WB, through an adapter. That other protocol does not give thinking output, so there is nothing I could do about that. But it is just no fun seeing thoe engines play, knowing not even if they thinnk they are winning or losing.
hgm wrote:CThinker wrote:And btw, Harm, I'm surprised that you used the 'easy' command as an example:
Code: Select all
C:\Temp\umax>umax.exe
tellics say micro-Max 1.6w
tellics say by H.G. Muller
easy
Error (unknown command): easy
hard
Error (unknown command): hard
quit
C:\Temp\umax>
Well, that I am a lazy SOB does not imply others should be forgiven for acting the same way!
Micro-Max cannot ponder at all, and I guess replying "unkown command" to "hard" is a good way to let the GUI know about it. (Not that any existing GUI does anything with that info...). But I agree that it is not logical to give the same to "easy". Note that uMax 1.6w has not been worked on from the time I first released it as a WB engine, which was at a time when I did not work on WB at all, and hardly knew the protocol. My current policy is to let my engines recognize all WB commands that are sent by default, even if only for the purpose to ignore them (like "computer", "ratings", "otim" etc.).
You have point about existing protocols being tailored for a specific implemetation of a chess engine (tree search with iterative deepening). But I am pretty sure Thinker does get its moves that way. So this in itself is no excuse for violating the protocol. In the end you get a PV somehow, don't you? It would already be a great improvement if you print that PV before printing the move (so it is not discarded as ponder output, and ends up in the PGN file).
For me looking at the depth/score and PV info is all the fun. Without it, computer Chess is quite meaningless. This was rubbed in again recently, when I converted some XQ engines from another protocol to WB, through an adapter. That other protocol does not give thinking output, so there is nothing I could do about that. But it is just no fun seeing thoe engines play, knowing not even if they thinnk they are winning or losing.
I think you have made a clear example there Harm - your engine does not ponder. That means it cannot support a set of xboard commands.
Micromax also does not support the 'move now' ("?") command. I use micromax to play, and I would rather have the 'move now' command than the PV display. It is very common for me to get bored, and I just need the engine to make the move.
But I understand all these, because I have the same set of limitations with Thinker.
As for PV, Thinker does not have one. It does not collect PV arrays. Again, just like MicroMax. Thinker is actually patterned after the Amy engine. The PV display that you get from Thinker is nothing more than a walk of the hash table (just like... Amy).
The ways that other engines collect PV arrays look very hacky to me. They either allocate a square array, but use only half of it, or, allocates PV arrays on the stack on each call to a search function. Neither is acceptable to me. So, until I device a really clean solution, I am not inclined on polluting the Thinker code.
The current code is really clean, very compartmentalized, and only contains the necessary code to find a good-enough root move and relay that to the user.
I could chose to make a giant monolithic engine (just like the others out there) and support the fancy protocol items, or, I can chose to make a small, cleanly structured engine that I can easily understand. I chose the latter. But that's just me.
Remember, when Thinker fist came out, the book engine (BookThinker) is separate from the search engine. BookThinker was actually the first of its kind at that time. Later, there was a huge struggle on whether the book code should go with the search code, because really, they do two very disjoint operations (file operations vs in-memory tree search). Many programmers here probably don't struggle with such design and architecture decisions, but I do.
We eventually found a clean way of having both to co-exist in the same architecture ("strategy" pattern, from 'design patterns'). I value that elegance of design and implementation. But again, that's just me.