Talk:Range modifications

Consistent with the goals of Rosetta Code ?

These formulations are charmingly Procustean 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)

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)