7 / 7
Aug 2015

The description says the input is guaranteed to be an integer, but several users have reported getting WA unless they read it as a floating point number. I had the same experience. In fact I ran my two scripts (WA and AC) on every valid input value (all integers 1...1000000), and the outputs were identical, according to diff. The only difference between the scripts is the AC one reads its input as floating point. So it seems like the test cases violate the problem description.

It seems that there are some '.' char in input, but all input numbers are integers in fact.
Eg 13.0 can be an input number, and it is an integer (mathematically) !
I agree that it is a floating point number (computationally) !

A well designed code should get AC reading input as float or integer.

This is not true. There are no '.' in the input.

My solution using this code for input did not give a SIGABRT.

#include <iostream>
#include <cstdio>
#include <cassert>
using namespace std;
long long readll() {
	long long x = 0;
	char c=' ';
	while(c < '0' || c > '9') {
		c = getchar();
		assert(c != '.');
	}
	while(c >= '0' && c <= '9') {
		x *= 10;
		x += c - '0';
		c = getchar();
	}
	assert(c != '.');
	return x;
}

@Leppy :
Maybe you didn't get SIGABRT if the '.' is ending the input.
What about that ?

2
12
12.0

Did you get SIGABRT ?
Is there a '.' in input ?

My python code read T the number of test case,
then T (full) lines, and I get NZEC with

assert '.' not in line

So there were a '.' in input !

According to your test, I think it could be only possible with a (almost) final point ; like ending with 12.0 or 12.

Mitch did some tests too with C, I really trust in his knowledge, I'm sure he will find the real mystery and the best answer for that strange thing.

[color=#00BF80]Now I not sure if there's a '.' in input.
My tests are giving some more strange things !!!!!!!!!!!
I don't understand for now.
[/color]
[b]Edit[/b] : My test was wrong, as some input lines have only one char, and

assert '.' not in line

gave NZEC in such cases.

assert '.' not in list(line)

didn't give me NZEC, so there's no '.' in input.
My conclusion, like Mitch, is that input is well formatted.

===
last edit :

as some input lines have only one char, and
This was a wrong reason too.
Now I understand the real reason.
And confirmed again that input is good, like Mitch and Leppy.

6 months later

I confirm that test contains only digits and newlines so I'm moving this thread to the archive.

10 days later

closed Aug 28, '15