OpenEuphoria

Re: Contest Update

• Posted by Derek Parnell <ddparnell at bigpond.com> Nov 07, 2004
• 519 views

Andy Serpa wrote:
> 
> Patrick Barnes wrote:
> > 
> > On Sun, 07 Nov 2004 14:50:20 -0800, Andy Serpa <guest at rapideuphoria.com>
> > wrote:
> > > Making an assumption that one should continue after an EOF marker could be
> > > wrong if this was
> > a "real-world" application.  Sticking to this esoterica would seem to be
> > making the contest
> about "who can best interpret</font></i>
> > logical loopholes in the rules" rather than best program a well-defined
> > task.</font></i>
> > > 
> > > Alternatively, simply put in a rule that says, "Input files should be
> > > opened in binary mode".
> > 
> > I believe that this is covered in the programming style criteria:
> > "Defensive coding that is tolerant of bad data." That's why files 6-11
> > are there - they contain a lot of border cases that may trip up
> > programs less tolerant. You're not penalised anywhere near as much for
> > making mistakes with these files than you are with the first 5.
> > 
> > 
> I understand bad data, but ignoring an EOF marker in a text file is making an
> assumption
> that I wouldn't neccessarily consider correct.  Some data is so "bad" that you
> can't
> expect the program to know what to do with it (unless that case is explicitly
> covered
> in the rules).  Should I make guesses at what other "bad" bytes in the file
> are "supposed
> to be" and adjust my token counts accordingly?
> 
> I just don't think it is reasonable, just as if there was a rule that said,
> "Program
> must continue to perform while computer is set on fire."

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.

-- 
Derek Parnell
Melbourne, Australia