sje wrote:ilari wrote:I've uploaded a new version (0.1.3) with a few changes:
- Support millisecond-precision in time controls
I agree that millisecond resolution is the way to go. Piloted spacecraft use a millisecond period update for critical telemetry; if it's good enough for a spaceship then I suppose it's good enough for a chess clock.
A new EPD specification is coming, and it uses a tighter formalism for a number of things including time values. Example:
Code: Select all
r1bqkbnr/pppp1ppp/2n5/8/3Q4/2N5/PPP1PPPP/R1B1KBNR w KQkq - 1 4 acd 6; acn 1436575; cc 4:55.265 4:54.606; pes +0.020; pv Qd3 h6 Nf3 Nf6 e4 Bd6; te 1.445; tu 1.333;
Note:
1) The half move counter and the full move number now appear explicitly as the fifth and sixth fields of a standard FEN position specification. The earlier EPD version had these omitted or appearing as optional operations (hmvc and fmvn).
2) Most things don't change: acd, acn, am, bm, pv, sv, etc.
3) Some things are deprecated, such as pm (use the first parameter value of pv instead).
I find pm useful (predicted move may not be the same thing as best move for instance). I have code that uses the pm field.
4) All time values share the same the same format of DDD:HH:MM:SS.mmm with optional leading zero suppression. Example: cc (chess clock) has a White and a Black countdown time operand.
5) Instead of acs, te records analysis elapsed (wall) time, and tu represents usage time. Usage may be greater than elapsed time for multicore analysis.
6) The ce operator is deprecated; the replacement pes (pawn equivalent score) operator gives an evaluation in signed floating point pawns with millipawn resolution. There are a few non-decimal values: MateInN (e.g., MateIn3), LoseInN, Even, PosInf, NegInf, and Broken.
Perhaps inconvenient for some, since almost nobody uses floating point for evaluation. But if you are going to make it floating point, and 1.0 is supposed to represent a pawn, then why use milliseconds? Just let it be a double and then they can have an internal precision that they like. In any case, we're going to use sscanf("%lf"... to collect it.
7) A few operations are undecided at the moment, like dm and solve.
I find dm very useful. I do not even know what solve is for because I have never run across that field. People are going to use different scales for checkmate (even though you have 32767 listed as written in stone, lots of people use 9999, 99999 or some other value instead, so dm has a clear purpose here).
8) Symbol operands are never quoted and string operands are always quoted. Examples:
id WAC.241;
I have literally hundreds of thousands of id fields with spaces in them. There was nothing in the original spec to prevent that and I will find it most annoying if I am not allowed to quote id fields. In fact, I can tell you now that I will ignore that new part of the spec because I have not enough time nor the compulsion to correct them.
name "Win at Chess problem 241";
