Talk:A+B: Difference between revisions

From Rosetta Code
Content added Content deleted
(→‎Input Specification: Many implementations are incorrect.)
(→‎Input Specification: does it really matter?)
Line 22: Line 22:


:: Task specification says that the input contains two numbers separated by space. However, many implementations seem to prompt the values one by one. For example Delphi, DMS, DWScript and Elena, just to name few. I think these implementations are incorrect. However, the task specification does not say if the input may contain leading and trailing spaces. --[[User:PauliKL|PauliKL]] 16:02, 25 September 2011 (UTC)
:: Task specification says that the input contains two numbers separated by space. However, many implementations seem to prompt the values one by one. For example Delphi, DMS, DWScript and Elena, just to name few. I think these implementations are incorrect. However, the task specification does not say if the input may contain leading and trailing spaces. --[[User:PauliKL|PauliKL]] 16:02, 25 September 2011 (UTC)
:::I don't think we really need to worry about that. That's not really the point of the task. I say let it go ad let people input the numbers in whatever way is natural to the language. --[[User:Mwn3d|Mwn3d]] 16:21, 25 September 2011 (UTC)


===Input specification ("constraints")===
===Input specification ("constraints")===

Revision as of 16:21, 25 September 2011

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)

Formatting

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)
Task specification says that the input contains two numbers separated by space. However, many implementations seem to prompt the values one by one. For example Delphi, DMS, DWScript and Elena, just to name few. I think these implementations are incorrect. However, the task specification does not say if the input may contain leading and trailing spaces. --PauliKL 16:02, 25 September 2011 (UTC)
I don't think we really need to worry about that. That's not really the point of the task. I say let it go ad let people input the numbers in whatever way is natural to the language. --Mwn3d 16:21, 25 September 2011 (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)
as does one of my Batch File solutions --Axtens 14:37, 13 May 2010 (UTC)
The task specifies that we need the sum of A and B and that they are between -1000 and 1000. It does NOT specify that we should not provide the sum when they are out of this range. I believe the intent was that outside of this range the behavior of the program is unspecified. --Rdm 10:30, 13 May 2010 (UTC)