Talk:Chowla numbers

"use commas within appropriate numbers"

Why is that hip now? Why is that part of many tasks instead of being solved once in an own task? This just adds silly useless complexity to a task and nothing else. Here it absolutely has nothing to do with Chowla numbers and just blows up the code while distracting from the main topic. E.g. calculating Chowla numbers in Dc would be easy but string maniupulation is not and is a completely different task and topic. A Dc solution probably would need 90% of its code just for that useless unrelated subtask. Please: Back to the roots! Concentrate on on clear tasks and problems with a narrow definition. Complex tasks spiced up with lots of unrelated subtasks don't fit well into a context like Rosetta Code.

(This is not meant to sound harsh. Please consider that not everyone is born with an English tongue and much misunderstanding may be caused by the translation.)

-- Yeti (talk) 08:11, 11 March 2019 (UTC)

Please sign your comments with a trailing:     -- ~~~~                     -- Gerard Schildberger (talk) 09:44, 11 March 2019 (UTC)

There is a reason that people add commas to numbers --- to make then easier to read, especially if there are some numbers like 100000 10000 35000000 10000000 100000000 (just to show a few).   It is not a useless thing to require.   If adding commas to numbers is too complex or cumbersome, leave the task to others   (this isn't meant to sound harsh).   The requirement is not to make it more complicated, but to to make the output (displayed) numbers easier to read.   The REXX solution essentially has a one-line function to add commas to integers;   most computer programming languages have commatizing capability within the   print   or   format   statements/functions.   Adding commas shouldn't be that difficult for most computer programming languages.   See if the computer programming language(s) you know has/have an entry for the Rosetta Code task   commatizing numbers   which is a much more comprehensive task as it includes locating a suitable number (within a string) which maybe is a number expressed in a floating point expression   (but in this Rosetta Code task, the number is a non-negative integer (that contains no leading or trailing blanks which makes it much simpler).   That commatizing Rosetta Code task also asks to use a user-defining "period" length (normally three), a character (or characters, including a blank) to be inserted (such as a period for a European look, and not to commatize exponents of many kinds, and not to commatize leading zeros, among other things).   Also note that some tasks require a certain format for a list of numbers, most often specifying a horizontal or vertical list to make it easier to compare the outputs of the various entries.   Vertical formats are much more easier to read/comprehend if there are multiple numbers to be displayed (such as an index) where a columnar output would be best.   I never thought that adding commas to (larger) numbers would be considered spicing it up.   If there is any confusing about the task's requirements for non-English speaking programmers, one could always look at the other solutions.     -- Gerard Schildberger (talk) 09:37, 11 March 2019 (UTC)

I cannot agree. Rosetta Code is about comparing code in n-1 languages. The more subtasks unrelated to the main topic/task a task additionally gets, the more the primary goal gets blurred. Solutions should be like clear statements, not epic operas. --Yeti (talk) 10:02, 11 March 2019 (UTC)

I'm sorry if you think that added commas to make the output numbers easier to read as an epic opera.   The primary goal was quite simply put, to use a user-written chowla function to find/display chowla numbers, to use the same function to find/count prime numbers and perfect numbers   (the last two requirements have two reasons:   verify that the chowla function executes correctly, and the other is that it should be written/coded in a robust manner suitable for Rosetta Code).   This was the goal, but stating the goal wasn't part of the lexicon of the task's requirements.   Rosetta Code tasks can have more than one goal, and in fact, many Rosetta Code tasks do, although goals and requirements overlap.   I may be a bit demanding, but I don't see any blurriness in the goal(s), especially since no goal was mentioned.   I prefer to simply list the task's requirements after the definitions in the task's preamble.   As for what solutions (programs) should look like, I don't subscribe to the belief that solutions should or shouldn't look like;   there are just too many styles and syntax that programmers use and/or prefer.   Not to mention what is idiomatic or not idiomatic for a particular computer programming language.   Others can argue about the merits of comments within the code.   I do believe in specific requirements.   Without them, some programmers have written solutions that don't show any output (although it was obvious that the task's author intended output to be shown, otherwise, how are we to compare the validity of the computer programs?), or the output is in a different format than all the others, or the output doesn't match the others because it uses different input(s), and even some programmers don't even use the same nomenclature.   There are reasons that requirements are specific (even numerous), and that is to ensure we are all seeing the same output(s) for the task's requirements.     -- Gerard Schildberger (talk) 10:50, 11 March 2019 (UTC)