Bernoulli(1) = +½

[Parcly-Taxel]

There was a discussion in SymPy at sympy/sympy#23866 on changing its value of $B_1$ (the first Bernoulli number) to $+\frac12$ from the old value of $-\frac12$. Using $+\frac12$ allows interpolating the Bernoulli numbers and polynomials with the entire Bernoulli function $B(s,a)=-s\zeta(1-s,a)$ and confers several other advantages – in short, when considering the many appearances of the Bernoulli numbers across mathematics, $+\frac12$ is the most logical choice for $B_1$.

That discussion has been closed because I have got PRs merged into SymPy changing its $B_1$ to $+\frac12$; cf. sympy/sympy#23926. I thought that also changed the value in SageMath (which SymPy includes), but @oscarbenjamin corrected me, pointing out the ability of SageMath to use other libraries' Bernoulli number implementations, all of which still have $B_1=-\frac12$. I dug through Sage's code and found that it uses FLINT for the smaller arguments; in order to ensure consistency with mathematical truth as soon as possible, I have opened this PR.

---

The associated sage-devel mailing list thread is
https://groups.google.com/g/sage-devel/c/G4sbKoibXK4
The corresponding trac ticket is
https://trac.sagemath.org/ticket/34521

[JeffreySarnoff]

I concur.

[fchapoton]

This should not be merged, at any prize. This is breaking the standard convention. It is not because somebody has tricked sympy to change that that you should be tricked here too.

[edgarcosta]

Copying my reply to sage-devel.

The choice of the sign is arbitrary. So why make this change? What is the benefit?
Most recent papers, algebra systems (Maple/Mathematica/Magma/Matlab/Oscar), and libraries (Pari/Flint/Mpmath/ARB) seemed to have picked B_1 = -1/2.
Thus why put work into changing the default value and go against the current norm?
By doing this you will generate a lot of unnecessary work to go from one arbitrary choice (that most people use) to another that few seem to use.

[asmeurer]

Can you cross link the relevant discussion(s) on the Sage mailing list and/or issue tracker?

[Parcly-Taxel]

Can you cross link the relevant discussion(s) on the Sage mailing list and/or issue tracker?

https://groups.google.com/g/sage-devel/c/G4sbKoibXK4
https://trac.sagemath.org/ticket/34521

These have also been edited into the first post here.

[thofma]

I agree with @edgarcosta. Too much code churn for so-called "consistency with mathematical truth" (aka an arbitrary choice of sign).

flint2 is quite defensive when it comes to breaking changes (there are usually none). So maybe this is something for flint 3.0 Maybe someone will write another "manifesto" and suddenly -1/2 is again the "mathematical truth".

[Parcly-Taxel]

I agree with @edgarcosta. Too much code churn for so-called "consistency with mathematical truth" (aka an arbitrary choice of sign).

The choice of sign is not arbitrary – it is how Jakob Bernoulli originally defined his numbers. The second part of Luschny's manifesto notes that the real arbitrary choice, setting $B_1=-\frac12$, was made in the early 20th century and perpetuated in things like A&S. "Well-intentioned but ultimately poor", as Knuth puts it.

Also, I managed to not break the tests by changing only 4 lines of code. It can hardly be called code churn.

Maybe someone will write another "manifesto" and suddenly -1/2 is again the "mathematical truth".

There can only be one truth, and the truth is that $B_1=+\frac12$.

[edgarcosta]

It is irrelevant how Bernoulli defined them originally. Or what Knuth thinks. We can take their opinion, but they are word is not the "truth".

There can only be one truth...

Mathematical truth is about what logical statements one can deduce from a set of axioms. How you define things along the way is irrelevant. Some definitions provide shorter statements, but in the end, definitions are just shortcuts. For example, I could define primes to be negative instead of positive, and that wouldn't change any "mathematical truth", would just introduce annoying negative signs whenever we referred to concrete primes...

[oscarbenjamin]

Too much code churn

What churn exactly?

The question I keep coming up against as I said here (sympy/sympy#23866 (comment)) is whether bernoulli(1) really matters. I haven't seen any concrete example where changing this is any significant problem.

[fingolfin]

The churn is in the code of all the people who use FLINT in their own projects, which may have to adopt their code to the new behavior. Worse than this is that they may not even notice the change, and end up with silently broken code.

[oscarbenjamin]

The churn is in the code of all the people who use FLINT in their own projects

I realise that is what is being referred to but do you know of any concrete examples where this would affect anything?

I asked that question because I wanted to know if anyone could point to a place where some code depends on this but no examples have so far been given. All examples I've seen that use the Bernoulli numbers do not care about Bernoulli(1) because they only use the even Bernoulli numbers. The odd Bernoulli numbers are not really that useful being mostly just zero in either convention.

[Parcly-Taxel]

Worse than this is that they may not even notice the change, and end up with silently broken code.

As I said in various places some time ago, any software that assumes B(1) = -½ is already broken. The mathematical results obtained after fixing this bug will speak for themselves as to whether any FLINT-using software needs to be changed, and how.

[albinahlback]

I agree with Max and I think we should close this.