Rosetta Commatizing numbers

[Solomon E via Digitalmars-d-learn]

On Wednesday, 31 May 2017 at 15:44:51 UTC, Ivan Kazmenko wrote:
> On Wednesday, 31 May 2017 at 13:27:24 UTC, Solomon E wrote:
>
> Fine, by the numbers:
>
>> 1. pi has the commas start at the wrong digit, and doesn't 
>> follow the explicit instructions to use spaces as the 
>> separator and a grouping of 5
>
> Can be solved by calling the function with a right set of 
> parameters: start = 6 and step = 5.  That's what function 
> parameters are for.
>
> Here, I understand that a real-world solution would try to 
> center around the decimal point.  There are, however, two 
> reasons not to do so.  First, it is not required in the problem 
> statement.  Second, the solutions in other languages don't 
> interpret the statement like that, and instead, just add a 
> parameter to start reading from a certain point.  Remember that 
> one of the main purposes of Rosettacode is to provide a 
> translation from one language to another.  There are other 
> places on the web for solving the problems in the best possible 
> way.
>
>> 2. There are no newlines (although the input is the list of 
>> lines to be "commatized" not concatenated.)
>
> write -> writeln
>
>> 3. Zimbabwe dollars are given commas, against the explicit 
>> request to have dots. (That would be undesirable in the real 
>> world, not just in this silly example, because comma is used 
>> as a decimal point in the Zimbabwe press, and spaces for 
>> thousands separators.)
>
> Can be solved by calling the function with a right set of 
> parameters: ins = '.'.  That's what function parameters are for.
>
>> 4. The second number in the line
>> ===US$0017,440 millions=== (in 2,000 dollars)
>> is "commatized" which is against the explicit instructions to 
>> "commatize" the first number only, given in the task 
>> description and explained on the task's talk page.
>
> replaceAll -> replaceFirst
>
>> 5. The exponent in 123.e8000 is "commatized" which is against 
>> explicit and repeated instructions not to "commatize" 
>> exponents.
>
> replaceAll -> replaceFirst
>
>> 6. (The commas in the Eddington number are acceptable enough.)
>
> OK.
>
>> 7. The year in 6/9/1946 is "commatized" against explicit 
>> instructions to "commatize" only the first number field. It 
>> was discussed in the task's talk page that years shouldn't be 
>> commatized, and that's easy to avoid by never "commatizing" 
>> past the first number.
>
> replaceAll -> replaceFirst
>
> So, two custom calls, two minor changes, no sweat.  Is 
> everything right now?  Even if not: that was fast, we can do 
> another iteration.  When we have a short readable solution with 
> no special cases, the first few changes are going to be easy.
>
>> For the Eddington number, the task didn't explicitly state to 
>> use spaces in that long a number, but the task does say there 
>> should be spaces in the digits of pi, which leaves open to 
>> interpretation whether that's a special request or a rule that 
>> could apply to any sufficiently long number, AND the task 
>> includes a reference to a Wikipedia page on the number that 
>> does use spaces.
>
> Here, I'd say you are greatly overthinking the problem.
>
>> The other language solutions to Rosetta tasks may be 
>> "inspirational" in some ways, but there are also errors in 
>> them, at least for this task, that would be found if they were 
>> fully tested. They're made by human beings, and Rosetta code 
>> is just a game. It's not something that's been around as long 
>> as the older languages used there have existed, to look up to 
>> solutions in old languages with awe as time-worn and carved in 
>> stone.
>
> If you see a problem, ~10 solutions, and think all of them have 
> serious issues, you may well be right.  But it is also likely 
> that all other solution authors read the problem differently.  
> Which leaves an open formal question whether you are reading it 
> correctly.  As well as an open informal question whether 
> enforcing your reading is a good goal, keeping in mind that 
> Rosettacode is a collection of translations.
>
> -----
>
> If you still insist you are doing the right thing and all 
> others are wrong, let's agree to disagree on that, and please 
> just leave the original solution there by introducing two 
> versions.
>
> Ivan Kazmenko.

I just now updated with a version that contains two functions: 
one function "commatize" very similar to the bearophile original 
but corrected, and the other my specialization "commatizeSpec" 
which calls commatize and processes all the example inputs 
programmatically.

I didn't split those functions into two solution blocks, because 
they're not really separate, one calls the other, and they were 
compiled and tested together only, and they use the same two 
lines of compiled regex.

That was a good challenge and good advice, to get called out on 
overcomplicating a function. I felt horrible about the 
complication, and enjoyed the simplification.

One of the goals of Rosetta code I thought was to show the style 
in which things are done in different programming languages, 
their differences in capabilities, and idioms. That way you can 
translate what you want to do more idiomatically. If the versions 
were all strict translations, word for word, that would be dry as 
dust boring, and not as useful.

I wanted to show D is a language that can get things right, not 
wrong. That was my main point.