Talk:Möbius function

From Rosetta Code

Möbius function for positive integers

This task says to write a function to     ... find the Möbius number for a positive integer   n.

But it is also apparently being used to find the Möbius number for zero, a non-positive number, as zero is apparently the 1st term as shown in the task's first written example's output.

Could/should it be stated:   ... find the Möbius number for a non-negative integer n     ?

Or, should solutions treat zero as a special case?     -- Gerard Schildberger (talk) 22:12, 25 January 2020 (UTC)

Zero is not a positive integer. The Möbius function is undefined at zero. No need to special case it. I don't see any examples that show a Möbius number for zero. Which ones are showing a value at zero? The only example that shows ANYTHING for an input of zero is the REXX example, and while that's a little odd, I wouldn't count it as wrong, as it specifically states that "bullet (•) to signify that a "null" is being shown (for the 0th entry)" ¯\_(ツ)_/¯ If REXX can't easily skip over zero, I'm not going to hold that against it. --Thundergnat (talk) 22:51, 25 January 2020 (UTC)
Sorry, my mistake that I thought I saw a zero being used for the input in showing the output   (in fact, most programs inserted a blank   (which I thought was a null being used for zero)   to make the grid align with the others.   Most of the programming solutions show a blank for the zeroth term, but that may just be an editing solution in showing a grid in leaving the place where a zero could/would be computed.   Not knowing much about some languages, I misinterpreted what I observed.   I've kept the REXX program to start at zero so as to make it look like (aligned with) all the other grids.   I could special case the problem to ensure a blank is shown to align/match all the other grids, but I had already generalized the showing of a grid (even size 1).   Sorry for all my confusion.     -- Gerard Schildberger (talk) 23:34, 25 January 2020 (UTC)
If the REXX solution would show 199 entries, starting at unity, it would show something like   (and make comparisons to other grids rather hard to visualize easily):
 1 -1 -1  0 -1  1 -1  0  0  1 -1  0 -1  1  1  0 -1  0 -1  0
 1  1 -1  0  0  1  0  0 -1 -1 -1  0  1  1  1  0 -1  1  1  0
-1 -1 -1  0  0  1 -1  0  0  0  1  0 -1  0  1  0  1  1 -1  0
-1  1  0  0  1 -1 -1  0  1 -1 -1  0 -1  1  0  0  1 -1 -1  0
 0  1 -1  0  1  1  1  0 -1  0  1  0  1  1  1  0 -1  0  0  0
-1 -1 -1  0 -1  1 -1  0 -1 -1  1  0 -1 -1  1  0  0  1  1  0
 0  1  1  0  0  0 -1  0  1 -1 -1  0  1  1  0  0 -1 -1 -1  0
 1  1  1  0  1  1  0  0 -1  0 -1  0  0 -1  1  0 -1  1  1  0
 1  0 -1  0 -1  1 -1  0  0 -1  0  0 -1 -1  0  0  1  1 -1  0
-1 -1  1  0  1 -1  1  0  0 -1 -1  0 -1  1 -1  0 -1  0 -1
And that would be perfectly valid. This task was mostly added as a related (preliminary) task to Mertens function task, so I followed a similar layout as I did for that. Good, bad or indifferent, when I was putting it together I figured a reasonable sub-task would be to generate a table similar to the one at wp:Mertens function; the table on that page has a layout that leaves a space for a zero and I emulated it without really thinking about it much. Most (all?) of the subsequent entries have copied that layout, but there isn't any requisite that they need to, it is likely just (as you surmise) that it is easier to compare with other entries. Your layout above would also be perfectly valid and be within the task requirements. Note that the task requires a minimum of 99 terms. I chose to show 199 but that was a totally arbitrary choice. --Thundergnat (talk) 00:48, 26 January 2020 (UTC)