Aug 2019
1 / 9
Aug 2019
Aug 2019
simes
Aug '19
1

The short answer, you don’t. That’s all part of the challange, and sometimes the frustration.

The example test cases are usually just a simple example of the I/O format. They won’t exercise the full requirements of the program, nor cover the full range of input values. Passing the example test cases is only the first step in getting an accepted solution.

The hidden test cases will always be much more thorough. You should expect them to contain tricky test cases, corner cases, and the minimum and maximum of the range of allowed values.

Some ideas for further testing…

  1. Generate your own test data and verify your program’s output. It may be useful to write a simple brute-force solution and compare its output with that from your program.

  2. Look in the comments for the problem. People sometimes post interesting test cases.

  3. go to http://www.spojtoolkit.com/test/PALIN316 and use their test cases. Be warned though, many test cases on spojtoolkit don’t conform to the layout or ranges given in the problem description, and it’s not unusual to find incorrect answers being given for valid test cases.

  4. Search this forum for test cases and their answers.

Good luck!

vaishcr7
Aug '19

If you just started here, I would recommend doing some others before coming here. This one is quite tricky and has a multitude of boundary cases. I got AC in it after almost 25 submissions.

bnnj
Aug '19

I’d be curious to know what was your error, vaishcr7.
I’ve tested all numbers from 0 to 100,000,000, and hundreds of millions of randomly generated numbers of random length up to 1,000,000,000, without finding a single error, even after comparing with a palindrome program that passes the judge.
I’m thinking there are special cases that are not simple numbers and are not described in the problem page, and for which I cannot prepare my code without more data.

So… please share what helped you get AC !

vaishcr7
Aug '19

i have edited the other thread accordingly. Although I did nothing special , I just shuffled the way I was testing for the cases.

devloping
Aug '19

Guess I should post an update on this.

per @slimes I reread the the problem and was going to to try out the upper bound. I must have read it wrong the first time as it sounds like the numbers that we’re dealing with for this problem are large so a 1 with one million zeroes after it as opposed to the number 1 million.

Since i’m dealing with c++ i wrote my own class for it since no way int can handle those numbers. But, I guess your stuck with submitting one file for the submision, as I could not figure out how to add new .h and .cpp and had to lump them into one…yuck

So I don’t get wrong answer anymore, I instead get time limit exceeded so that’s better I suppose.

simes
Aug '19

I’d say TLE is worse than WA. When you run out of time, the output of your program isn’t checked, so once you resolve the time issue, you might find you still get WA.

bnnj
Aug '19

Just use strings.

devloping
Aug '19

Re-wrote it again for the third time since I noticed a few simplifications that I could add and it got accepted!!!

I guess with regards to time limit exceeded,
i added prefix increment operator to my class since that’s all that’s really needed for this (better implementation as well since there’s less digits to go through than before) and at a few places I wasn’t passing string as reference parameters so i made them const reference parameters instead and re-writting stuff probably helped as well since I have a lot less string variable and std:reverse calls now.

I found a number where my class had a wrong answer but I think that’s because I re-wrote it and had a stupid mistake.
Number was:
9999191291839 <-- input
999919919999 <-- my program was giving this as the next palindrom anwser instead, lol… 1 digit too short

=== Now for the cool part ===
I also found a way that you could better diagnose these wrong answer problems so I figured that I would share, not that I used it for this problem. Used it for a practice one :grinning:
Looks like if a condition fatally fails say input < output looks you could proably do something like:

if( input.length() < output.length() )
  throw length_error("Output length is less than input");

Obviously for something like this you should get rid of leading 0’s from input before comparing. But, instead of getting wrong answer you would get SIGBART which at least you know where in the code that happened. You don’t get told the error but SIGBART is probably easier to figure out than wrong answer. i.e. wrong assumptions etc.