Talk:Range expansion

Negative ranges

Should the test case contain a negative range, such as -15--10? Stormneedle 18:57, 16 July 2010 (UTC)

It was carefully chosen to have a negative number as I found it complicated the Python solution I was working on. Self flagellationarily yours, --Paddy3118 19:17, 16 July 2010 (UTC)

I think he was asking if the test case should be extended to include a range where the terminating number is negative. For example, perhaps -3--1 instead of -3-1? --Rdm 19:21, 16 July 2010 (UTC)

Yes, I was, Rdm. Sorry that I was unclear. Stormneedle 21:35, 16 July 2010 (UTC)

Ahh. I understand now. Yes. I'll make the change within the hour, but it will invalidate all current entries. (How do you flag all entries for update due to a change in the task? --Paddy3118 04:59, 17 July 2010 (UTC)

Spaces in the list

The examples are all without spaces in the list, e.g. "1, 3-6". I guess this means that solutions which don't allow for spaces are correct, right? What about the converse: Would an example which does allow for spaces be incorrect? In other words: Is accepting spaces mandatory, optional or forbidden?

BTW, my C++ code accepts whitespace between numbers and commas/range dashes as well as at the beginning and end (the latter is especially handy for reading directly from standard input, because with normal usage there's always a line feed at the end) --Ce 09:12, 17 July 2010 (UTC)

For the purposes of examples given to tasks, no spaces should be given to expansion routines or created from extraction routines. There is however, no need to ensure that you can only work within such restrictions however. --Paddy3118 10:11, 17 July 2010 (UTC)

Thanks for the clarification. --Ce 11:14, 17 July 2010 (UTC)

Result format, Unary +

Is the result supposed to be a string of comma-separated integers, as in the example? Or a legal list literal in the language? What if the two are different? I added the Perl, where the two happen to be (almost) the same. But that's not going to be the case for every language. --Snoman 22:08, 17 July 2010 (UTC)

Also, what about handling unary + on positive integers in the input string? Or just assume that positive integers are always unmarked? I guess this could also be language-dependent. --Snoman 02:17, 18 July 2010 (UTC)

Assume there will be no plus characters in the range format; and that the list format is the easiest printed representation of your languages internal list of integers data structure that also reads nicely to humans. (Drawing the pointers of a linked list would be over the top, even if you have the routine to do that handy :-)
--Paddy3118 05:44, 18 July 2010 (UTC)

OK, that's clear, many thanks! Of course, Snobol4 (my other contribution) has no list or array literals - yes, it's an annoyance :-) - so I just followed your example. --Snoman 08:02, 18 July 2010 (UTC)

Ranges oddness

What is the "desired" behaviour if the range input is e.g. "4,10-6" instead of "4,6-10"? My current implementation of Range extraction from "4,3,2,1" produces "4-1", while the current impl of Range expansion won't expand "4-1" to "4,3,2,1"... I have a ready solution where range limits are "ordered", but this way "4-1" is equivalent to "1-4" and produces "1,2,3,4" which is not the original "4,3,2,1"... --ShinTakezou 17:36, 18 July 2010 (UTC)

The task assumes that it gets correctly formatted ranges that expand to an increasing series of different integers. I know that this most likely would not be the case 'in the real world', but we just need to have comparable examples.