Author: Dann Corbit
Date: 02:05:59 10/25/02
Go up one level in this thread
On October 25, 2002 at 04:33:27, Dave Gomboc wrote:
>On October 24, 2002 at 15:47:37, Dann Corbit wrote:
>
>>On October 23, 2002 at 21:40:23, Dave Gomboc wrote:
>>
>>>On October 23, 2002 at 15:25:04, Colin Frayn wrote:
>>>
>>>>Then I suddenly realised. Carlos had been sending strings to the engine of the
>>>>form;
>>>>3r4/5b2/1k1r1p2/Np5p/4P1p1/2R1KPP1/2P4P/R7 w
>>>>
>>>>(i.e. missing off the last two dashes.) The full string should be
>>>>3r4/5b2/1k1r1p2/Np5p/4P1p1/2R1KPP1/2P4P/R7 w - -
>>>>
>>>>but of course the shortened version should still be valid.
>>>
>>>Why do you say that? All those fields are required. The EPD parsing code I
>>>ahve written throws an exception on your first example. Sounds like that would
>>>have saved you a lot of grief!
>>
>>If castling is impossible, it's not hard to figure out what the flags are.
>>Leaving them out is a common mistake.
>>
>>Similarly, Winboard will accept all sorts of goo as PGN. It just silently eats
>>the ugly crud and turns it into a clean version.
>
>Leaving the castling and en-passant flags out is a common mistake only because
>broken tools accept them instead of rejecting them. I strongly believe that
>it's simply better to gratuitously reject non-conforming input. Colin will
>hardly be the last person to slave for days to hunt down a bug that was caused
>by slack input parsing. Input parsing is a *notorious* place for bugs, probably
>because most people want to get it over with and get on with the "real"
>programming.
>
>Recent example: take a slighly old version of crafty, and set the time to
>0.137258 seconds ("st 0.137258") -- and check out the time limit that is
>actually set! Bob fixed this input parsing bug in about 15 seconds -- once I
>had spent a chunk of time trying to figure out what was wrong with _my_ code
>that was communicating with crafty. The basic problem was that crafty assumed
>the time sent to it would have resolution of at most in the hundredths of
>seconds. But unfortunately, nothing in the code actually verified that that was
>the case. Had it done so, and signalled an error, I would have understood the
>problem immediately, and either changed my code to suit, or sent him a code
>patch in 15 seconds myself. And perhaps while writing that checking code he
>would have realized that it was a pain in the neck to make that check, and have
>came up with the idea of just reading in a floating-point number in the first
>place, in which case the bug would have never been there at all.
>
>If one wants to implement automatic cleaning-up of EPD strings, PGN files, or
>what have you, I think it should be done in distinct code expressly written for
>the purpose. When you do that, you'll be focusing more carefully on the
>possible things that might be wrong. But at a bare minimum, a compromise would
>be to present a user-visible warning when the mandatory fields are absent. This
>isn't as good as outright rejection, though, because the individual might have
>just added the missing fields after he saw that his software didn't work but
>that a warning had been emitted. In that case, the developer might not have
>been notified, or might have not bothered to look at it carefully because the
>person who noted the problem had already worked around it; the code itself would
>still contain the bug.
Writing stuff that anticipates errors and corrects them is a lot harder than
writing something that simply rejects them and quits.
The EPD kit from crafty drives me nuts sometimes.
It simply stops running when it encounters a problem. That's the worst possible
behavior I can imagine, except crashing the machine.
If something obvious is done wrong (e.g. "QK -" instead of "KQ -" it croaks. It
would clearly be harder to write something that tries to make sense out of
questionable input.
The problem is that a huge percentage if input is questionable. I prefer
something that fixes and goes on (or reports the problem and goes on, or at
worst ignores and goes on) to something that just stops running.
And I do think that Tim Man's solution of allowing 0-0-0 and 0-0 for castling is
better than refusing to parse the game. The same is true for all his other
fixes to crappy input.
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.