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 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.