Once I commented out the debug statements, the program didn’t output anything at all. Please could you show the code you actually submitted?
I can’t find a test case where your code gives the wrong answer.
My only suggestion is to remove the exception ignoring - perhaps something is going wrong, and you don’t know it?
the fast I/o class I am using is a checked exception so I can’t remove it and using normal scanner for input causes TLE.
Also I didn’t understand why they specified the length of all words <10^6 ?
The output format is correct right ?
But do you need to ignore the exception? Can’t you re-throw it? or throw another? At least then you’d know something was not as you expected.
Length of all words <10^6 tells you how many trie elements you need.
The output format looks ok to me. Are you removing the line feed after the final test case? There’s no need to.
After removing return, spoj did give a nzec. I will try to see why now. Can it be related to heap space for java. I also removed the extra list of words that i had introduced for devugging . It did reduce the memory consumption 10 times but still runtime error (NZEC) .
But in other questions this has happened too when I used this method of i/o . And after just returning , i used to get AC. Like CSTreet and other questions. Still I will try some far fetched test cases.
String []s=sc.readLine().trim().split(" ");
n=Integer.parseInt(s[0]);
q=Integer.parseInt(s[1]);
This kind of thing is fragile, all it takes to break it is an extra space in the input. Try using the nextInt function.
updated the code for nextInt(). Same thing again. I just got an AC for blinnet . In that I faced no issues like this.
I used assert statements to discover that none of the words in the list are longer than 20 characters,
Are you saying there is no issue with I/o here . I have already tried with varying the buffer length in readline() in previous comments ?
Well, you said:
so I suspected that there may be some words longer that the 64 byte buffer allocated in readline. But. I’ve now discovered there aren’t any long words. Whatever the problem is in readline, it’s not caused by words longer than 64 characters.
What makes you sure readline is the culprit?