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. On Monday, September 12, 2022 at 5:09:24 PM UTC-4 Fredrik Johansson wrote:
> I'm pretty neutral about this change, but I've received PRs for FLINT and > mpmath (presumably there will be one for Arb as well) so I suppose I will > need to make a decision about merging or closing them sooner or later :-) > > The sign convention for B_1 is fairly arbitrary, and the downside of > changing it is that this introduces ambiguity and inconsistency where there > was none before. On the other hand, you can make the case that "patching" > deficient conventions is better in the long run... at least if the new > convention eventually sees near-universal adoption (which is not at all > guaranteed here). > > An advantage of B+ is that it would agree with the definition used in Sage > for generalized Bernoulli numbers when restricted to the trivial character; > see > https://doc.sagemath.org/html/en/reference/modmisc/sage/modular/dirichlet.html#sage.modular.dirichlet.DirichletCharacter.bernoulli > > The claim "bernoulli_plus admits a natural generalisation to real and > complex numbers but bernoulli_minus does not" (made elsewhere in this > thread) seems a bit hyperbolic. For B+ this natural generalization is > -n*zeta(1-n); for B- one can just use -n*zeta(1-n)*cos(pi*n). OK, one is a > bit simpler than the other, but both are perfectly fine entire functions. > > For Sage and mpmath, I suppose the least intrusive option is to introduce > a keyword argument to select the plus/minus convention, with B- as default > until there is community consensus to change it. There is not really a > strong need to change low-level libraries like FLINT at this point since > it's trivial to handle both conventions in a wrapper. > > Fredrik > > > On Saturday, September 10, 2022 at 4:17:08 PM UTC+2 redde...@gmail.com > wrote: > >> My name is Jeremy Tan, or Parcly Taxel in the furry/MLP art scene. As of >> this post I am a recent graduate from the National University of Singapore >> with two degrees in maths and computer science. >> >> Over the past month I had a good read of Peter Luschny's Bernoulli >> Manifesto (http://luschny.de/math/zeta/The-Bernoulli-Manifesto.html) and >> was thoroughly convinced that B_1 (the first Bernoulli number) *has* to >> be +½, not -½. (Much of Luschny's argument centres on being able to (1) >> interpolate the Bernoulli numbers when B_1 = +½ with an entire function >> intimately related to the zeta function, and (2) extend the range of >> validity of or simplify several important equations like the >> Euler–Maclaurin formula. Have a read yourself though – it is close to >> divine truth.) >> >> So I went to SymPy – one of SageMath's dependencies, and where a >> discussion on this topic was open ( >> https://github.com/sympy/sympy/issues/23866) – and successfully merged >> several PRs there (https://github.com/sympy/sympy/pull/23926) >> implementing both that change and some functions in Luschny's "An >> introduction to the Bernoulli function" (https://arxiv.org/abs/2009.06743 >> ). >> >> I thought I was also done with changing B_1 = +½ for SageMath, but then >> someone pointed out that the latter currently uses other libraries that all >> have B_1 = -½. I have already opened a PR for one such library, FLINT, to >> change B_1 = +½ there (https://github.com/wbhart/flint2/pull/1179). >> However Fredrik Johansson has advised me that I take the discussion right >> here, to sage-devel, because (in his words) >> >> > if FLINT and Arb change their definitions but the Sage developers >> decide that they don't like it, they will just treat the new behavior as a >> bug and add a special case in the wrapper to return B_1 = -½. >> >> So my proposal is to special-case it the other way – before the backend >> selection in Sage's Bernoulli code ( >> https://github.com/sagemath/sage/blob/08202bc1ba7caea46327908db8e3715d1adf6f9a/src/sage/arith/misc.py#L349), >> >> add a check for argument 1 and immediately return +½ if that is the case. >> This also has the advantage of bypassing libraries that haven't or don't >> want to change. >> >> What do you think? >> >> Jeremy Tan / Parcly Taxel >> > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/9c61b1ee-d2c4-4c6c-b539-f89ad6d45941n%40googlegroups.com.
