[seqfan] Re: Farey series of order 0

[Fred Lunnon]

  One of the benefits of my training in computer science has been the
ability to
distinguish (for example) between an address and the value stored at that
address,
or between the identifier of variable and its value.  In the world outside
such
special disciplines, such distinctions are commonly ignored, dismissed as
irrelevant, or completely overlooked --- so generating much avoidable
obfuscation.
  It seems to me that the apparent difficulty here results from conflating
two concepts:
an  n-th order (finite) sequence of pairs of integers, versus a sequence of
rational numbers which it commonly is utilised to represent.  However,
although
the two coincide throughout an important and useful subset of instances,
outside of that they diverge; analogous situations arise not infrequently
in
mathematics, and particularly among special values of integer sequences.
  By all means, this particular case should be examined and flagged;
but I can see no justification for alteration of an existing entry which
has not
clearly been compromised by unintentional computational error!

WFL

On Wed, Dec 1, 2021 at 5:54 PM <hv at crypt.org> wrote:

> Since A005728 was added 30 years ago, it has given a(0) = 1 with a mostly
> unchanged title "Number of fractions in Farey series of order n".
>
> Can someone explain how a(0) = 1 is justified for that definition?
> In my understanding the first order Farey series is [0/1, 1/1], and
> a zeroth order would either have zero terms or not be well defined -
> it would have to consist of terms with denominator 0.
>
> I see the value does match a formula such as a(n) = 1 + Sum_{i=1..n}
> phi(i);
> I'd argue that is coincidental: a(n) = a(n-1) + phi(n) by definition for
> n > 1, but not for n = 1.
>
> If my argument seems reasonable, I'd propose only adding a comment to warn
> about the relevance of a(0) - I think the entry would be diminished if we
> changed the title to be the formula and reduced the Farey connection to
> a comment, and it could cause unnecessary problems if we changed the
> values of so venerable a sequence.
>
> Hugo
>
> --
> Seqfan Mailing list - http://list.seqfan.eu/
>