1 / 7
Apr 2010

It looks there are no real requirements to the input data. Wouldnt it be a great idea to define them?
- sometimes lines end with \n
- sometimes lines end with \r\n
- sometimes there are trailing \n
- sometimes there are multiple blanks between numbers whereas I usually expect only 1
- sometimes even the data itself dont comply with the input specification

  • created

    Apr '10
  • last reply

    Aug '10
  • 6

    replies

  • 400

    views

  • 4

    users

  • 1

    link

This is the only one I take issue with.

3 months later

@hendrik

"sometimes" does not help much.

We receive much help from problem setters who spend their free time to give us "fresh meat"
and the Editorial Board who take care for the quality of the problems.

All other help is also appreciated but please point out the details.

In other cases there is not much trouble (and even a "good programmer practise")
to write programs which work fine with all described cases.

As regards the inconsistent inputdata I complained earlier about MKMONEY. See my comments to this task. But nobody cares. The test case I showed is inconsistent in two cases: 100.0 is not less than 100 and also it does not have two fractional digits. This almost ruined my integer approach for that problem until I found that out.

As regards the format I also disagree. I would rather focus on the problem itself as they are in most cases quite challenging what I really like. I doesnt really improve my programming skills to find out how the input format looks like.

Another thing: In many cases the input data are taken as is from the contest sites. I would appreciate if the problem setters at least add one or two test cases more. Can't be so difficult or time consuming.

8 days later

Indeed, the description and the example suggested two digits after a dot - corrected.

Yes, this is clear. We do our best to make the system running - so you do not have to care about it at all,
you just type "spoj.pl" and it works.
And we want the same about problem statements and input data. Unfortunately, we have no available resources to review all the problems, so your help is very welcome - thank you.

PS: If you like to become a problem setter to contribute high qulity and bug free problems,
just let us know (contact@spoj.pl).

Thanks Łukasz for updating MKMONEY. Now my integer approach got AC without workarround.

I havent complained about SPOJ. I like the site very much. It is actually the responsibility of the problem setter to ensure that the data is as good as possible. But SPOJ could support this.