Talk:Commatizing numbers

several numbers in the input

shouldn't 2000 become 2,000 ? --Walterpachl (talk) 05:07, 11 April 2014 (UTC)

If you're referring to the 4^th string to be commatized ===US$0017440 millions'..., then no.   The 1^st numberic string is 0017440, not 2000 (which is the 2^nd numeric string). -- Gerard Schildberger (talk) 05:26, 11 April 2014 (UTC)

Ambiguous task spec. Oddly specific for some things while it glosses over others completely.

It seems to me that this task is really 3 subtasks that have been mashed together. That isn't necessarily a problem, but there is no separation of subtasks in the task description. It is all or nothing. As I interpret it, the first, and ostensibly the primary task, is to add appropriate separators to numbers to display them as numeric strings. That one I have no problem with. It is a fine, useful and commonly performed operation.

The second subtask, as I read it, is to algorithmically pick out numeric strings from mixed alphanumeric strings. Again, a fine, useful operation, though a little more touchy-feely and open to interpretation.

The third subtask, and the one I have the real problem with, is to algorithmically determine WHAT a particular numeric string represents so the "correct" arbitrary, inconsistent, seemingly pulled-out-of-the-air set of rules can be applied. I would be happier if the spec followed wikipedias guidelines for digit grouping (which incidentally doesn't mention scientific notation at all) but that's neither here nor there. Task writers are free to impose arbitrary restrictions.

My issue is that the task implies and assumes that there is some general algorithm that can be determined, but language is too messy and inconsistent to do that. Numeric strings VERY commonly are identifiers, not numbers: zip codes, phone numbers, credit card numbers, dates (it could be argued that 2014 is numeric, but really it just identifies a certain period of time to make it easier to refer to it). How about numbers in binary? hexadecimal? base 36?

Perhaps if someone could demonstrate how the current implementations "correctly" commatize the following strings:

   "The number 8675309 had to be taken out of service in every area code after Tommy Tutones song 'Jenny' was released"
   "Including in Beverly Hills 90210"
   "Use the credit card number 6011123456789876"
   "1946 was a good year for some; 6/9/1946 was a good day at most." 
   "hex 1234e56 = decimal 1091030"
   "bogus(36) = 1001010110101011001010100(2)." 
   "123456789 is often used as an 'unused' demonstration social security number."

If the answer is "Well you need to know what the numeric string represents ahead of time and only use when appropriate.", then don't pretend that there is some general algorithm that can be applied. Knowing ahead of time is not an algorithm.--Thundergnat (talk) 15:54, 19 April 2014 (UTC)

I share your frustration with this task. Like you, I do not think that this task represents any sort of "general algorithm", and I'd much rather see efforts directed at geometric or mechanical modelling, or manipulation of audio data, or something interesting like that. That said, I would not characterize it as "ambiguous" so much as "completely arbitrary". And perhaps it would indeed be better to create one or more of the three modular tasks you've implied, and add links to them from here? That said, I guess I also need to acknowledge that knowing ahead of time is actually kind of important. --Rdm (talk) 16:07, 19 April 2014 (UTC)