From Rosetta Code

This task is pretty elegant; I suspect it could handily replace both User Input and User Output. --Michael Mol 16:49, 8 April 2010 (UTC)


This tasks doesn't follow the normal task formatting conventions, where the Task description does not contain explicit headings so that all the task description appears above the contents; and all languages appear with equal "double-equals" heading.

I could reformat it if you like?

P.S. Fabula?

--Paddy3118 18:48, 8 April 2010 (UTC)

I've done some reordering/reformatting. The header/problem material still needs work, but the solutions should now be relatively OK. –Donal Fellows 19:56, 8 April 2010 (UTC)
Ta! --Paddy3118 21:46, 8 April 2010 (UTC)

Input Specification

It is not quite clear whether the input is solely two integers separated by a single space, whether there's a new line or not, whether there can be more stuff in the input, whether there may be leading spaces and things like that. Some solutions displayed are resilient to such variations, others will fail. Some even seem to depend input being separated by a newline for each number.

In other words, it would be nice if the input could be more strictly specified. -User:dcsobral/Daniel Sobral 21:27, 8 April 2010 (UTC)

If you look at the solutions contributed in the first version of the page, you'll see code that only makes any sense if the input is two integers on a single line separated by whitespace. There might or might not be leading and trailing whitespace on that line. Or at least that's what the Pascal and C solutions wanted at that point. –Donal Fellows 23:27, 8 April 2010 (UTC)

Input specification ("constraints")

The task's text says that A and B are (must be? should be?) between -1000 and 1000; no a single example checks this. Is it a mandatory requirement we should add the check for, or it can be ignored? —ShinTakezou 06:30, 13 May 2010 (UTC)

Usually in such tasks (at least for the ACM ICPC) all input follows the initial specification so no checking is required. Usually the boundaries provided by the task description provide insight into how the problem can be solved; for example, if the problem size is very small it can well be an NP-complete problem you need to brute-force, for medium-sized problems an n2 algorithm might still be possible. If input numbers easily exceed 109 or so you shouldn't iterate through them and find a more clever solution. After all, your program has to solve a task in a certain time (usually between 1 and 5 seconds).
So, in short, given where the problem comes from I consider checking the input superfluous. There are many more things not checked as well. The Ruby example will dutifully add as many whitespace-separated numbers as there are in the input; not just two. —Johannes Rössel 10:22, 13 May 2010 (UTC)