On Sat, Sep 10, 2022 at 7:17 AM Jeremy Tan <reddeloo...@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?
It could be done via the "1 year deprecation policy". I.e., return the current value by default with a warning message (and note about an option to change it) for the next year, then when there is a release in late 2023 (?), the default would change. This would give people time to update their code. I have no comment on the pros and cons of this personally, though I'm curious if the change breaks any code anywhere else in Sage (e.g., maybe for computing q-expansions of modular forms?)... > > 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/CAGYgO94gF%3DBKo7gRnUj8c3H0bJyuLp_Apr%3D8Y9NC%2BFM%2BSZHNOg%40mail.gmail.com. -- William (http://wstein.org) -- 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/CACLE5GDODH97Xe%2BgnLZYA0GjP%2B%2BJv25nfWDrnD8f5oCNS%3D0twg%40mail.gmail.com.
