OpenEuphoria

Re: Contest Update

• Posted by Andy Serpa <ac at onehorseshy.com> Nov 08, 2004
• 515 views

Derek Parnell wrote:
> 
> 
> If I may weigh in here, the EOF marker is not bad data. It is perfectly
> allowable in text files and *any* program that reads a file as a text file
> ought to take it into consideration, as you have said. However, who said
> they were going to be text files?
> 
> The confusion might come about because it was assumed that the test files
> would be 'text' files. There is no statement in the rules that this would
> be the case. All it says, and I quote rule 13, ...
> 
> "The file should only contain bytes in the range #00 - #7F, and you can
> consider those to be ASCII characters."
> 
> A better program would most likely validate the input rather than assuming
> it to be correct. 
> 
> I'm sorry I didn't make it too easy for people, but this specification is
> still a whole lot better than most specifications received from a client.
> So yes, I could have told you how to open the file, how to hash the tokens,
> how to store the lists of tokens, how to sort or order the tokens,
> how to ...  etc... but I didn't. I wanted you to work out some of the
> 'traps' that might be there. 
> 
> Its a game more than a contest, so one needs a bit of an interesting 
> challenge.
> 
> If anyone wants to withdraw, just let me know.
> 

I just figured you wanted this to be a programming challenge rather than a
"rule-reading" challenge.  I would submit that your referring to the tokens as
"characters" rather than "bytes" (at least in some places) would allow one to
assume that the inputs are *supposed* to be text files.  "Characters" only exist
in text, at least in a Euphoria context (maybe if this were C, where a character
might be assumed to be any single byte).  I also thinking making assumptions
about the intentions of the creator of the input file (maybe the EOF is supposed
to be there, and you are NOT intended to read past it) is questionable.  If the
scope of the contest is to include the possibility of an ambiguous program
specification where the true wants of the (hypothetical) "client" are therefore
unknown, then my interpretation is just as valid as yours, and the programmer
should only be penalized if his program handles the same (ambiguous) situation
inconsistenly with different input files.

Or, alternatively, as I said before, if you (as the "client") remove such
ambiguousness from the rules/specification.