Well stopping the search early is optional of course but it really speeds up testing.
For engines that implement "?" (move now) stopping early is not a problem.
There is no reason for using "?" command.
In my opinion the interface should put the engine in analysis mode, and use the analysis command "exit" to stop analysis and "setboard" or "edit" to load a new position. This is the way Arena manages epd suites.
EDIT @Michel:
I wrote this post before I saw your own edit
Yes indeed, but I am not sure how many do implement that. If I would set a searchTime of 10 sec for micro-Max, for example, it would think on the average 1.5 sec, because it always finishes an iteration, and the inpredictability of the duration is such that when it would start a new one after 1.5 sec, it would lose almost every game within 10 moves in -st mode. Engines that can stop after any root move already needs less margin, but unless they can really abort the search they would still need a factor 3 or so. It would be very inconvenient to run micro-Max at 10 times the nominal time in -st mode to make sure it always thinks at least the nominal time, as there is no way to cut it short either. (No move-now.)
I can imagne many engines behave similarly, and when you tell them they need to do 40 moves in 600 sec, they are much more likely to think at least 10 sec, because there is no need to build in such a large safety margin.
But perhaps I shold simply leave this to the user to decide, and add a separate EPD dialog to the menu where one can set all the mentioned parameters independently of TC. In EPD mode WinBoard would then simply run the engine as if it was starting game at that TC, send it the move-now command at the timeout, or when the solution condition is satisfied, and then wait for the engine to move, no matter how long it takes. (For buggy engines you could run them with /xreuse, and have them killed when they 'lose on time' according to the rules of the set TC.)
hgm wrote:Someone suggested to me that it would be useful to have WinBoard handle EPD suites. Now I have never done any EPD suites, so I only have a vague idea of what that entails. My question therefor is: what should WinBoard actually do.
Currently it can already read a file with FEN or EPD (-loadPositionFile), and step automatically through them (-loadPositionIndex -1). But it only does that for playing games from these starting positions. It would of course be only a minor modification to limit those 'games' to a single move only, before restarting the next.
So the main question is, what should WinBoard record and report from this. From full games in match mode it would count the wins/draws/losses, and display those as a popup at the end. What would we want here? Record the time until a given best move is first found, and calculate the average? Record the moves that are found after a preset time, and count the good solutions? How are the engines to be run in this mode? Just set them for a long time, and use the move-now command after the time is up? (But what if they do not support it?) Use the st command to set them for fixed time per move? (But what if they then think much shorter than this, to keep a safety margin?)
With one-line reporting for each position, (which could be done, for instance, in the lower pane of the Engine-Output window, like in -autoKibitz mode), what should the line preferably contain? Another EPD?
Any suggestions would be most welcome.
Look at the functionality of epd.c in crafty (SJE did that bit).
