Talk:Range modifications

Consistent with the goals of Rosetta Code ?

These formulations are charmingly Procrustean and intemperate:

1. "Solutions must work by XYZ ..."
2. "Do not use algorithms that XYZ ..."

but I do wonder how much they really contribute to the aim of Rosetta Code, expressed on the landing page: "to aid a person with a grounding in one approach to a problem in learning another" ?

They seem a little anxious not to be exposed to alternative solutions to a given problem :-) Hout (talk) 18:59, 23 October 2020 (UTC)

I must admit I was slightly taken aback by imm. slapping Wren got for "[ ]", esp. as the task does not specify output.

Another concern is whether modified ranges should be held as a string, or something more native/useable. --Pete Lomax (talk) 22:22, 23 October 2020 (UTC)

Think of an expensive design automation tool needing time and money to run. To apply a patch to the design, the documented flow amounts to a timely and costly rerun, or, a hack to an internal file of this format. The customer normally manually hacks, but while waiting for the vendor to decide on its support, can can make the hack even less error prone and present the vendor with an example of the requested functionality.

I've done similar. --Paddy3118 (talk) 04:17, 24 October 2020 (UTC)

Sadley I have no problem believing that. Did BoJo involve you in his world beating Covid app? Now -5 and -2 are both integers. Is -5--2 a valid range? How many of the 'hacks' implemented will make your unlucky customer less error prone?--Nigel Galloway (talk) 15:17, 26 October 2020 (UTC)

On algorithm restriction: RC tasks must be succinct. I can't show huge extensive input but try and restrict this algorithm so it may work with such. --Paddy3118 (talk) 04:17, 24 October 2020 (UTC)

These formulations are charmingly Procustean and intemperate:

had to look those up. You should check the spelling of procustean - did you mean procrustean with another r? Intemperate isn't usually applied to someone's work, and both words have conflicting meanings wrt control. --Paddy3118 (talk) 05:11, 24 October 2020 (UTC)

The story of Procrustes (or Προκρουστης, if you prefer) captures very well the intemperate tone of this task description, and the angry bold lettering of its attempt to dictate a solution :-)

A Rosetta task is a problem to be solved. The value lies precisely in the variety of solutions. A problem setter who tries to dictate and limit the solutions, and then chops off any hint of variety with warning notices, is missing the point and not contributing much.

(There is a risk here of appearing more preoccupied with control than with Rosetta quality and value).

Set a new problem (this one seems mainly a rehash of two existing problems) and let everyone else stretch their own limbs, and enjoy and learn from the variety of responses. Hout (talk) 06:34, 24 October 2020 (UTC)

Your not stating that you don't understand the requested format. You want to ignore it. If the task asks for JSON, don't produce XML. If it states the sequence format should be produced as part of the task and a solution instead gives something else with a glib comment that the requested format could be produced with a slight change then why not complete the task?

You're not specifying an output format in those two shouty clauses with bold lettering ("Solutions must work by XYZ ..." "Do not use algorithms that XYZ ...")

(Consistent output formats in problem solutions are fine and useful, no one disputes that).

What is not constructive, and not consistent with the aims of Rosetta Code, is to be intemperately Procrustean about the routes to that solution. Rosetta is about discovering alternative approaches, not about awarding oneself the pleasure of chopping them off. Hout (talk) 11:04, 24 October 2020 (UTC)

Coding does tend to need precision. Finding wriggle-room often takes experience and interpersonal skills, and might not materialise. --Paddy3118 (talk) 07:32, 24 October 2020 (UTC)

"Coding does tend to need precision" Completely irrelevant. Your proscriptions have nothing to do with "precision". You are taking a machete to the variety of approaches on a website which is explicitly dedicated to the variety of approaches.

The role of a setter is to frame a problem and specify an output. Not to meddle in the middle and take an axe to unexpected approaches Hout (talk) 11:04, 24 October 2020 (UTC)

So, should the output have quotes? On the start range only but not on subsequent results?

Should an input of "10-25,1-5,27-30" quietly discard the "1-5"?

Is "3-1" a valid and necessary, or illegal and ignore-able or error-inducing input? --Pete Lomax (talk) 10:34, 24 October 2020 (UTC)

Output quotes?

The example needs to be able to parse, modify and output the format. Showing normal language string literals is optional, but used in the task description start case as it more clearly shows the null string.

If your language idiomatically uses brackets or other methods to show string literals then that would be fine too. --Paddy3118 (talk) 07:24, 25 October 2020 (UTC)

Proposal:: Drop the two redundant (and Procrustean) bullet points

The two Procrustean clauses ("Solutions must work by XYZ ..." "Do not use algorithms that XYZ ...") are redundant and contrary to the aims of Rosetta Code.

Rosetta Code users should be allowed to do what is described on the landing page – namely, to express and learn a variety of approaches.

I suggest that the quality of this task is improved by deleting the two Procrustean clauses. Hout (talk) 11:11, 24 October 2020 (UTC)

Specifying an algorithm to use is done on many tasks. You are given potentially more freedom here as you are not restricted to a specific algorithm, just barred from what is a memory hungry approach for large ranges. --Paddy3118 (talk) 13:09, 24 October 2020 (UTC)

"is done on" – examples ? They may need improvement too.

"barred from" (sic) – Where scope is seen for better approaches, variant drafts can illustrate them. There's no place on Rosetta code (the very raison d'etre of which is comparison of alternative approaches) for an appetite for "barring" approaches to solving a problem. Deletionary appetites are better satisfied elsewhere. This is not the place for them. Hout (talk) 14:09, 24 October 2020 (UTC)

One way to resolve this dispute might be to simply add a suitably high range, eg

              Start with: "13-14,22-22,100000999999-100001000000,100001000003-999999999999"
   remove 22           -> "13-14,100000999999-100001000000,100001000003-999999999999"
   remove 100000999999 -> "13-14,100001000000-100001000000,100001000003-999999999999"
   remove 100001000000 -> "13-14,100001000003-999999999999"
      add 100001000001 -> "13-14,100001000001-100001000001,100001000003-999999999999"
      add 100001000002 -> "13-14,100001000001-999999999999"
   remove 100001000002 -> "13-14,100001000001-100001000001,100001000003-999999999999"
   remove 100001000001 -> "13-14,100001000003-999999999999"

That should be enough to deter anyone from using an array of nearly 1,000,000,000,000 bools --Pete Lomax (talk) 11:19, 25 October 2020 (UTC)

Absolutely, that's a much better approach than strutting about in imitation of a dictatorial manner, with comedy bolded proscriptions :-) Hout (talk) 14:35, 25 October 2020 (UTC)