Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[William Stein]

On Thu, Sep 15, 2022 at 7:36 PM Kwankyu Lee  wrote:

> On Friday, September 16, 2022 at 10:46:09 AM UTC+9 wst...@gmail.com wrote:
>
>> I just happened to stumble again on the original scrap of paper just
>> now where I made up the name
>> Sage back in 2004.
>>
>
> A good photo of it deserves to be permanently placed in the history
> section of the sagemath website.  But I could not find the history section.
>


Wow a history section would be a great idea. It could also highlight how
much work people put into the sage notebook back in the day, and the extent
to which sage builds on pari, singular, gap, etc…

>
>
>
> --
> 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/155dc41c-6d30-4792-923f-2ff85d831de7n%40googlegroups.com
> 
> .
>
-- 
-- William Stein

-- 
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/CACLE5GDeXcHgy-F%3DXw1Hx5afOWAeYjZ-rdvWzrwfJ2hOCHUQGA%40mail.gmail.com.

Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[Kwankyu Lee]

On Friday, September 16, 2022 at 10:46:09 AM UTC+9 wst...@gmail.com wrote:

> I just happened to stumble again on the original scrap of paper just 
> now where I made up the name 
> Sage back in 2004. 
>
 
A good photo of it deserves to be permanently placed in the history section 
of the sagemath website.  But I could not find the history section.

 

-- 
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/155dc41c-6d30-4792-923f-2ff85d831de7n%40googlegroups.com.

[sage-devel] Re: On changing Bernoulli(1) to +½

[Jeremy Tan]

There is now an Arb equivalent of the Sage ticket that implements the 
generalised Bernoulli function but nothing else:

https://github.com/fredrik-johansson/arb/pull/438

Any further equivalents (e.g. on mpmath) will be edited into the 
description of the Sage ticket rather than being mailed here.

Parcly Taxel

On Thursday, 15 September 2022 at 02:01:36 UTC+8 peter@gmail.com wrote:

> tl;dr, 80 lines, sorry.
>
> I think there is a better alternative than changing the current 
> implementation of the Bernoulli numbers.
>
> Fredrik: "The sign convention for B_1 is fairly arbitrary, ..."
>
> Calling the question a 'convention' sets a wrong framing from 
> the start. Conventions are treated differently than bugs. 
> And this is a bug. Setting B- leads to inconsistency in several
> identities, which I have described on my known web-page.
>
> Fredrik, honestly, do you really think Knuth rewrites TAOCP 
> and CM just to change an arbitrary sign convention? Knuth 
> expressly considers it a mistake.
>
> As long as the discussion is viewed as one about conventions, 
> it is uninteresting and does not improve our understanding of
> the situation. People who believe this can equally well flip
> a coin when in doubt.
>
> Best leave the whole discussion behind, the question of + or -, 
> the question of convention or bug, the question of decision 
> or compromise, or what people on Twitter think (Fredrik asked :)) 
> All answers to such questions must be profoundly unsatisfactory.
>
> The matter should be solved mathematically in a way Euler 
> would have liked, without resorting to this absurd fixation
> on a single value.
>
> And by that, I mean to define a suitable complex function, 
> call it the 'Bernoulli function', and then say: The 'Bernoulli 
> numbers' are the values of this function on the non-negative integers.
>
> Everyone knows a possible way to do this: B(z) = -z*zeta(1-z).
> Of course, you could add a sin or cos factor to it (Fredrik 
> mentioned that, Knuth too, by the way), but why should you do
> that? Occam's razor speaks against it. Maximum simplicity has
> always belonged to the beauty criteria in mathematics.
>
> Similar approaches have already been done; Helmut Hasse, for 
> example, has constructed the corresponding function without 
> recourse to the zeta function. And there are also other 
> representations without reference to the zeta function.
>
> Another pleasing possibility is via the Jensen-Johansson-Blagouchine
> formulas, first given by Jensen and first proved by Johansson 
> and Blagouchine ("Computing Stieltjes constants using complex 
> integration").
>
> These formulas are also the starting point in my arXiv paper. 
> There I try to show that this function is also essential in 
> other contexts in the theory of special numbers and offers 
> some technical advantages. 
>
> * My suggestion: Offer this function in Sage. This may not mean
> much more than a three-line wrapper around the zeta function. 
> Then the current code does not have to be changed, no deprecation
> warnings, no keywords for alternatives are required.
>
> The decision is then solely up to the user whether he wants 
> to continue the current usage and use bernoulli(n) or find 
> pleasure in bernoulli_function(n).
>
> Fredrik's fear that new "ambiguity and inconsistency" could 
> creep in is then unfounded: The names and the definitions are 
> too different; here polynomials, there a zeta-like function, 
> both with different applications.
>
> If you want to describe this approach in a highfalutin way, 
> it is Grothendieck-ish. It does not answer the question which
> of the two values is the 'correct' one; it shows how this problem
> disappears when put into the proper conceptual framework.
>
> This approach also makes sense in all the other cases that 
> Fredrik has to decide. With it, the burden of making a sensible
> decision is turned into the freedom for the user to explore 
> a fascinating function.
>
>  --
>  Peter
>  
>
>

-- 
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/f2ef3552-bfd7-4742-ba27-cfc5f3fea8fdn%40googlegroups.com.

Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[Jeremy Tan]

https://trac.sagemath.org/ticket/34536

There, Luschny!

On why I initially only changed B_1 = +½, I have a rebuttable demand of my
code: *it must be as beautiful as the maths it implements*. Having
bernoulli_gen() (your generalised Bernoulli function as implemented in the
SageMath ticket) alongside an integer-only bernoulli() is not pretty to me,
and especially not pretty when they return inconsistent values at 1.

Hence my first idea was to overload bernoulli() like I did with SymPy, but
seeing as that was not very feasible, my second idea was to simply change
B_1 = +½. Now that you prodded me into finding hurwitz_zeta() at top-level,
I have the new ticket *only* implementing bernoulli_gen().

Jeremy Tan / Parcly Taxel

On Thu, 15 Sept 2022, 02:01 Peter Luschny,  wrote:

> tl;dr, 80 lines, sorry.
>
> I think there is a better alternative than changing the current
> implementation of the Bernoulli numbers.
>
> Fredrik: "The sign convention for B_1 is fairly arbitrary, ..."
>
> Calling the question a 'convention' sets a wrong framing from
> the start. Conventions are treated differently than bugs.
> And this is a bug. Setting B- leads to inconsistency in several
> identities, which I have described on my known web-page.
>
> Fredrik, honestly, do you really think Knuth rewrites TAOCP
> and CM just to change an arbitrary sign convention? Knuth
> expressly considers it a mistake.
>
> As long as the discussion is viewed as one about conventions,
> it is uninteresting and does not improve our understanding of
> the situation. People who believe this can equally well flip
> a coin when in doubt.
>
> Best leave the whole discussion behind, the question of + or -,
> the question of convention or bug, the question of decision
> or compromise, or what people on Twitter think (Fredrik asked :))
> All answers to such questions must be profoundly unsatisfactory.
>
> The matter should be solved mathematically in a way Euler
> would have liked, without resorting to this absurd fixation
> on a single value.
>
> And by that, I mean to define a suitable complex function,
> call it the 'Bernoulli function', and then say: The 'Bernoulli
> numbers' are the values of this function on the non-negative integers.
>
> Everyone knows a possible way to do this: B(z) = -z*zeta(1-z).
> Of course, you could add a sin or cos factor to it (Fredrik
> mentioned that, Knuth too, by the way), but why should you do
> that? Occam's razor speaks against it. Maximum simplicity has
> always belonged to the beauty criteria in mathematics.
>
> Similar approaches have already been done; Helmut Hasse, for
> example, has constructed the corresponding function without
> recourse to the zeta function. And there are also other
> representations without reference to the zeta function.
>
> Another pleasing possibility is via the Jensen-Johansson-Blagouchine
> formulas, first given by Jensen and first proved by Johansson
> and Blagouchine ("Computing Stieltjes constants using complex
> integration").
>
> These formulas are also the starting point in my arXiv paper.
> There I try to show that this function is also essential in
> other contexts in the theory of special numbers and offers
> some technical advantages.
>
> * My suggestion: Offer this function in Sage. This may not mean
> much more than a three-line wrapper around the zeta function.
> Then the current code does not have to be changed, no deprecation
> warnings, no keywords for alternatives are required.
>
> The decision is then solely up to the user whether he wants
> to continue the current usage and use bernoulli(n) or find
> pleasure in bernoulli_function(n).
>
> Fredrik's fear that new "ambiguity and inconsistency" could
> creep in is then unfounded: The names and the definitions are
> too different; here polynomials, there a zeta-like function,
> both with different applications.
>
> If you want to describe this approach in a highfalutin way,
> it is Grothendieck-ish. It does not answer the question which
> of the two values is the 'correct' one; it shows how this problem
> disappears when put into the proper conceptual framework.
>
> This approach also makes sense in all the other cases that
> Fredrik has to decide. With it, the burden of making a sensible
> decision is turned into the freedom for the user to explore
> a fascinating function.
>
>  --
>  Peter
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/G4sbKoibXK4/unsubscribe.
> To unsubscribe from this group and all its topics, 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/19d2d0c8-556b-4bbf-a9d1-e87e7e8ed4c9n%40googlegroups.com
> 
> .
>

-- 
You 

Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[Jeremy Tan]

Thank you for coming, Luschny.

I not only wholeheartedly believe B_1 = +½ and that there is no convention
about it, but also that I believe in the reality and usefulness of the
Bernoulli, Euler and other functions you defined in your 2020 paper.

When I implemented those functions in SymPy there was already a base –
two-argument bernoulli() and euler() with polynomial support were there, as
well as genocchi(). So I could easily generalise those functions into yours.

On the other hand, until writing this reply I did not know that SageMath
exposed a hurwitz_zeta() function by default from which I can define the
generalised Bernoulli function. Hold on; I'll have a new ticket ready.

Jeremy Tan / Parcly Taxel

On Thu, 15 Sept 2022, 02:01 Peter Luschny,  wrote:

> tl;dr, 80 lines, sorry.
>
> I think there is a better alternative than changing the current
> implementation of the Bernoulli numbers.
>
> Fredrik: "The sign convention for B_1 is fairly arbitrary, ..."
>
> Calling the question a 'convention' sets a wrong framing from
> the start. Conventions are treated differently than bugs.
> And this is a bug. Setting B- leads to inconsistency in several
> identities, which I have described on my known web-page.
>
> Fredrik, honestly, do you really think Knuth rewrites TAOCP
> and CM just to change an arbitrary sign convention? Knuth
> expressly considers it a mistake.
>
> As long as the discussion is viewed as one about conventions,
> it is uninteresting and does not improve our understanding of
> the situation. People who believe this can equally well flip
> a coin when in doubt.
>
> Best leave the whole discussion behind, the question of + or -,
> the question of convention or bug, the question of decision
> or compromise, or what people on Twitter think (Fredrik asked :))
> All answers to such questions must be profoundly unsatisfactory.
>
> The matter should be solved mathematically in a way Euler
> would have liked, without resorting to this absurd fixation
> on a single value.
>
> And by that, I mean to define a suitable complex function,
> call it the 'Bernoulli function', and then say: The 'Bernoulli
> numbers' are the values of this function on the non-negative integers.
>
> Everyone knows a possible way to do this: B(z) = -z*zeta(1-z).
> Of course, you could add a sin or cos factor to it (Fredrik
> mentioned that, Knuth too, by the way), but why should you do
> that? Occam's razor speaks against it. Maximum simplicity has
> always belonged to the beauty criteria in mathematics.
>
> Similar approaches have already been done; Helmut Hasse, for
> example, has constructed the corresponding function without
> recourse to the zeta function. And there are also other
> representations without reference to the zeta function.
>
> Another pleasing possibility is via the Jensen-Johansson-Blagouchine
> formulas, first given by Jensen and first proved by Johansson
> and Blagouchine ("Computing Stieltjes constants using complex
> integration").
>
> These formulas are also the starting point in my arXiv paper.
> There I try to show that this function is also essential in
> other contexts in the theory of special numbers and offers
> some technical advantages.
>
> * My suggestion: Offer this function in Sage. This may not mean
> much more than a three-line wrapper around the zeta function.
> Then the current code does not have to be changed, no deprecation
> warnings, no keywords for alternatives are required.
>
> The decision is then solely up to the user whether he wants
> to continue the current usage and use bernoulli(n) or find
> pleasure in bernoulli_function(n).
>
> Fredrik's fear that new "ambiguity and inconsistency" could
> creep in is then unfounded: The names and the definitions are
> too different; here polynomials, there a zeta-like function,
> both with different applications.
>
> If you want to describe this approach in a highfalutin way,
> it is Grothendieck-ish. It does not answer the question which
> of the two values is the 'correct' one; it shows how this problem
> disappears when put into the proper conceptual framework.
>
> This approach also makes sense in all the other cases that
> Fredrik has to decide. With it, the burden of making a sensible
> decision is turned into the freedom for the user to explore
> a fascinating function.
>
>  --
>  Peter
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/G4sbKoibXK4/unsubscribe.
> To unsubscribe from this group and all its topics, 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/19d2d0c8-556b-4bbf-a9d1-e87e7e8ed4c9n%40googlegroups.com
> 
> .
>

-- 
You received this 

[sage-devel] Re: On changing Bernoulli(1) to +½

[Peter Luschny]

tl;dr, 80 lines, sorry.

I think there is a better alternative than changing the current 
implementation of the Bernoulli numbers.

Fredrik: "The sign convention for B_1 is fairly arbitrary, ..."

Calling the question a 'convention' sets a wrong framing from 
the start. Conventions are treated differently than bugs. 
And this is a bug. Setting B- leads to inconsistency in several
identities, which I have described on my known web-page.

Fredrik, honestly, do you really think Knuth rewrites TAOCP 
and CM just to change an arbitrary sign convention? Knuth 
expressly considers it a mistake.

As long as the discussion is viewed as one about conventions, 
it is uninteresting and does not improve our understanding of
the situation. People who believe this can equally well flip
a coin when in doubt.

Best leave the whole discussion behind, the question of + or -, 
the question of convention or bug, the question of decision 
or compromise, or what people on Twitter think (Fredrik asked :)) 
All answers to such questions must be profoundly unsatisfactory.

The matter should be solved mathematically in a way Euler 
would have liked, without resorting to this absurd fixation
on a single value.

And by that, I mean to define a suitable complex function, 
call it the 'Bernoulli function', and then say: The 'Bernoulli 
numbers' are the values of this function on the non-negative integers.

Everyone knows a possible way to do this: B(z) = -z*zeta(1-z).
Of course, you could add a sin or cos factor to it (Fredrik 
mentioned that, Knuth too, by the way), but why should you do
that? Occam's razor speaks against it. Maximum simplicity has
always belonged to the beauty criteria in mathematics.

Similar approaches have already been done; Helmut Hasse, for 
example, has constructed the corresponding function without 
recourse to the zeta function. And there are also other 
representations without reference to the zeta function.

Another pleasing possibility is via the Jensen-Johansson-Blagouchine
formulas, first given by Jensen and first proved by Johansson 
and Blagouchine ("Computing Stieltjes constants using complex 
integration").

These formulas are also the starting point in my arXiv paper. 
There I try to show that this function is also essential in 
other contexts in the theory of special numbers and offers 
some technical advantages. 

* My suggestion: Offer this function in Sage. This may not mean
much more than a three-line wrapper around the zeta function. 
Then the current code does not have to be changed, no deprecation
warnings, no keywords for alternatives are required.

The decision is then solely up to the user whether he wants 
to continue the current usage and use bernoulli(n) or find 
pleasure in bernoulli_function(n).

Fredrik's fear that new "ambiguity and inconsistency" could 
creep in is then unfounded: The names and the definitions are 
too different; here polynomials, there a zeta-like function, 
both with different applications.

If you want to describe this approach in a highfalutin way, 
it is Grothendieck-ish. It does not answer the question which
of the two values is the 'correct' one; it shows how this problem
disappears when put into the proper conceptual framework.

This approach also makes sense in all the other cases that 
Fredrik has to decide. With it, the burden of making a sensible
decision is turned into the freedom for the user to explore 
a fascinating function.

 --
 Peter
 

-- 
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/19d2d0c8-556b-4bbf-a9d1-e87e7e8ed4c9n%40googlegroups.com.

Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[John H Palmieri]

I have no opinions about what B_1 should be, but I am concerned about 
potential confusion: some users will expect one value for B_1, others will 
expect a different value, and so one group or other will end up being 
confused when answers don't come out the way they expect. The safest course 
might be to drop "bernoulli" altogether and have two functions for the two 
different conventions. Or keep "bernoulli" but have it just print a message 
saying that there are two conventions, so instead use either 
"bernoulli_plus" or "bernoulli_minus" (or whatever they might be called). I 
don't know if the safest course is the right course, though.

(This is how I feel about the "range" of a function in mathematics: some 
people use this word to mean the image, some people mean it to use the 
codomain. Since there is serious possibility of confusion, I personally 
just never use the term at all.)

-- 
John

On Tuesday, September 13, 2022 at 4:15:07 AM UTC-7 redde...@gmail.com wrote:

> On Tue, 13 Sept 2022, 17:00 David Joyner,  wrote:
>
>> Let's play nice here, okay?
>
>
> Let me explain what I mean in a nicer way. Not defining B_1 looks good on 
> the surface given the current discussion, but is really a strictly worse 
> option than defining B_1 = +½ or -½ because then the n = 1 case has to be 
> special-cased out of formulae where B_1 is normally used.
>
> That B_n for odd n at least 3 is zero may provide computational 
> advantages, but is a non-trivial fact. It is more parsimonious to put the 
> even, one and greater-odd instances of the Bernoulli numbers into one bag.
>
> 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/6c6859b5-e7b2-4e17-bcf9-30994a7048f4n%40googlegroups.com.

Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[Jeremy Tan]

On Tue, 13 Sept 2022, 17:00 David Joyner,  wrote:

> Let's play nice here, okay?


Let me explain what I mean in a nicer way. Not defining B_1 looks good on
the surface given the current discussion, but is really a strictly worse
option than defining B_1 = +½ or -½ because then the n = 1 case has to be
special-cased out of formulae where B_1 is normally used.

That B_n for odd n at least 3 is zero may provide computational advantages,
but is a non-trivial fact. It is more parsimonious to put the even, one and
greater-odd instances of the Bernoulli numbers into one bag.

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/CAGYgO94ZEW6gpF-mzeqWbyoP%2BTaKG%3D9gXkVJxPHsJ8_ha_JKjw%40mail.gmail.com.

Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[Dima Pasechnik]

On Tue, Sep 13, 2022 at 10:35 AM Oscar Benjamin
 wrote:
>
> On Mon, 12 Sept 2022 at 22:09, Fredrik Johansson
>  wrote:
> >
> > 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.
>
> I chose the word "natural" carefully because to me it conveys the fact
> that it is a subjective statement rather than a formal one. I assume
> it is formally possible to make infinitely many complex analytic
> functions to interpolate any function on the nonnegative integers (is
> that a named theorem?).

you can always add sin(x)/pi - which vanishes on 0,1,2,..., - to your
interpolant.
So that's an excercise :-)


>
> The question is whether the factor of cos(pi*z) that you've included
> is something that is meaningful for noninteger values of z or
> something included only artifically. Did you have any reason to choose
> it besides fixing bernoulli(1)=-1/2 (which can also be done in
> infinitely many other ways)?
>
> Most mathematical functions will never gain the status of being a
> named function in any context so would defining a complex analytic
> bernoulli_minus(z) = -z*zeta(1-z)*cos(pi*z) have any particular value?
> Any formula involving bernoulli_plus would apply equally to
> bernoulli_minus but with some factors of cos(pi*z) lying around. Would
> any of the formulas have some other factor of cos(pi*z) for those to
> cancel with in order to produce something more "natural"? Would there
> be any value in SymPy, mpmath, Arb, Sage etc implementing such a
> bernoulli_minus?
>
> --
> Oscar
>
> --
> 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/CAHVvXxSXzmOXcNnO3scCZOm7pZG36tGB9G-GEavqQi2hKRq-Xw%40mail.gmail.com.

-- 
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/CAAWYfq1ShHLMK2VBSJGpsHoU7YsZ-sfU9h%2BaUboLoHXFkjETQg%40mail.gmail.com.

Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[Oscar Benjamin]

On Mon, 12 Sept 2022 at 22:09, Fredrik Johansson
 wrote:
>
> 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.

I chose the word "natural" carefully because to me it conveys the fact
that it is a subjective statement rather than a formal one. I assume
it is formally possible to make infinitely many complex analytic
functions to interpolate any function on the nonnegative integers (is
that a named theorem?).

The question is whether the factor of cos(pi*z) that you've included
is something that is meaningful for noninteger values of z or
something included only artifically. Did you have any reason to choose
it besides fixing bernoulli(1)=-1/2 (which can also be done in
infinitely many other ways)?

Most mathematical functions will never gain the status of being a
named function in any context so would defining a complex analytic
bernoulli_minus(z) = -z*zeta(1-z)*cos(pi*z) have any particular value?
Any formula involving bernoulli_plus would apply equally to
bernoulli_minus but with some factors of cos(pi*z) lying around. Would
any of the formulas have some other factor of cos(pi*z) for those to
cancel with in order to produce something more "natural"? Would there
be any value in SymPy, mpmath, Arb, Sage etc implementing such a
bernoulli_minus?

--
Oscar

-- 
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/CAHVvXxSXzmOXcNnO3scCZOm7pZG36tGB9G-GEavqQi2hKRq-Xw%40mail.gmail.com.

Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[David Joyner]

On Tue, Sep 13, 2022 at 3:43 AM Jeremy Tan  wrote:
>
> A simpleton's way of getting out of the problem indeed. PARI/GP's 
> documentation says:
>

Let's play nice here, okay?

> ? ?bernvec
> bernvec(n): returns a vector containing, as rational numbers, the Bernoulli 
> numbers B_0, B_2, ..., B_{2n}.
> ? bernfrac(3)
> %2 = 0
> ? bernfrac(5)
> %3 = 0
>
> So not only B_1 but also B_3, B_5, etc. have values.
>
> Jeremy Tan / Parcly Taxel
>
> On Tuesday, 13 September 2022 at 15:03:05 UTC+8 vdelecroix wrote:
>>
>> PARI/GP actually has a better convention : only even Bernoulli numbers exist
>>
>> ? bernvec(5)
>> %1 = [1, 1/6, -1/30, 1/42, -1/30, 5/66]
>>
>> And the two conventions can be recovered as evaluations of Bernoulli
>> polynomials at 0 and 1 respectively
>>
>> ? [subst(bernpol(n), x, 0) | n <- [1..6]]
>> %2 = [-1/2, 1/6, 0, -1/30, 0, 1/42]
>> ? [subst(bernpol(n), x, 1) | n <- [1..6]]
>> %3 = [1/2, 1/6, 0, -1/30, 0, 1/42]
>>
>> I second Edgar that I don't see much of the point on doing this
>> change. If we had to do any change I would suggest to raise an error
>> when bernoulli(n) is called with n=1 so that nobody could complain
>> about sage convention choices.
>>
>> Vincent
>
> --
> 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/57e2bd6c-98eb-4617-928b-feea43fce978n%40googlegroups.com.

-- 
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/CAEQuuAXRBOF_zM7r0U2ipkfORzQhxg5-dACdJWeqsk7p1xFdng%40mail.gmail.com.

Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[Jeremy Tan]

A simpleton's way of getting out of the problem indeed. PARI/GP's 
documentation says:

? ?bernvec
bernvec(n): returns a vector containing, as rational numbers, the Bernoulli 
numbers B_0, B_2, ..., B_{2n}.
? bernfrac(3)
%2 = 0
? bernfrac(5)
%3 = 0

So not only B_1 but also B_3, B_5, etc. have values.

Jeremy Tan / Parcly Taxel

On Tuesday, 13 September 2022 at 15:03:05 UTC+8 vdelecroix wrote:

> PARI/GP actually has a better convention : only even Bernoulli numbers 
> exist 
>
> ? bernvec(5) 
> %1 = [1, 1/6, -1/30, 1/42, -1/30, 5/66] 
>
> And the two conventions can be recovered as evaluations of Bernoulli 
> polynomials at 0 and 1 respectively 
>
> ? [subst(bernpol(n), x, 0) | n <- [1..6]] 
> %2 = [-1/2, 1/6, 0, -1/30, 0, 1/42] 
> ? [subst(bernpol(n), x, 1) | n <- [1..6]] 
> %3 = [1/2, 1/6, 0, -1/30, 0, 1/42] 
>
> I second Edgar that I don't see much of the point on doing this 
> change. If we had to do any change I would suggest to raise an error 
> when bernoulli(n) is called with n=1 so that nobody could complain 
> about sage convention choices. 
>
> Vincent 
>

-- 
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/57e2bd6c-98eb-4617-928b-feea43fce978n%40googlegroups.com.

Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[Vincent Delecroix]

PARI/GP actually has a better convention : only even Bernoulli numbers exist

? bernvec(5)
%1 = [1, 1/6, -1/30, 1/42, -1/30, 5/66]

And the two conventions can be recovered as evaluations of Bernoulli
polynomials at 0 and 1 respectively

? [subst(bernpol(n), x, 0) | n <- [1..6]]
%2 = [-1/2, 1/6, 0, -1/30, 0, 1/42]
? [subst(bernpol(n), x, 1) | n <- [1..6]]
%3 = [1/2, 1/6, 0, -1/30, 0, 1/42]

I second Edgar that I don't see much of the point on doing this
change. If we had to do any change I would suggest to raise an error
when bernoulli(n) is called with n=1 so that nobody could complain
about sage convention choices.

Vincent

On Tue, 13 Sept 2022 at 04:00, edgardi...@gmail.com
 wrote:
>
> 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 

[sage-devel] Re: On changing Bernoulli(1) to +½

[Jeremy Tan]

On Tuesday, 13 September 2022 at 10:00:20 UTC+8 edgardi...@gmail.com wrote:

> 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.
>

The people and CAS's who use B_1 = -½ are good, but wrong. The central 
thesis of Luschny's manifesto is that B_1 = +½ shows the central place of 
the Bernoulli numbers in all mathematics much better than B_1 = -½. As he 
puts it in the closing paragraphs:

"I believe in the *unity of mathematics* as described by Barry Mazur… In 
any case mathematics is not a bunch of disparate conventions which must be 
maintained in its present form just to protect some mathematicians from a 
possible confusion."

Every general-purpose CAS is an embodiment of said unity of mathematics, 
and should strive to capture – make real – that unity as much as possible. 
Yes, the Four Heavenly Kings (Magma, Maple, Mathematica, Matlab) may 
provide B_1 = -½, but this is SageMath, an open-source *alternative* to all 
of them. We don't have to follow them or any convention.

As well as that, SageMath originally stood for System for Algebra and 
Geometry *Experimentation*. Given the almost excessive number of relations 
between the Bernoulli numbers with B_1 = +½ and other mathematical 
entities, I am confident that a secondary school/high school 
student/undergraduate first introduced to the Bernoulli numbers with B_1 = 
+½, and given SageMath with B_1 = +½, would have a lot more fun than if B_1 
= -½ was initially given instead.

Finally I would like to drop a quip from the manifesto: "My impression is 
that the number of modern authors who use B_1 = +½ is steadily increasing."

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/68f64631-1abb-43d4-91ae-972cc009ce91n%40googlegroups.com.

Re: [sage-devel] Re: On changing Bernoulli(1) to +½

[William Stein]

On Mon, Sep 12, 2022 at 7:00 PM edgardi...@gmail.com
 wrote:
>
> The choice of the sign is arbitrary. So why make this change? What is the 
> benefit?

The answer to that question is what the website

http://luschny.de/math/zeta/The-Bernoulli-Manifesto.html

is all about. I think you have to read that website.   Here's a random
quote from that website that might peak your interest:

"By now, hundreds of books that use "the minus-one-half" convention
have unfortunately been written.  Even the major software systems for
symbolic mathematics have that 20th-century aberration deeply
embedded.  Yet Luschny convinced me that we have all been wrong, and
that it's high time to change back to the correct definition before
the situation gets even worse.  Therefore I changed the definition of
$B_1$ in all printings of The Art of Computer Programming..."

- Donald Knuth




--
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/CACLE5GBOnd-gxNV29EUqKtB3BmBPPizQus%2B_6tkN45ES5oUdng%40mail.gmail.com.

[sage-devel] Re: On changing Bernoulli(1) to +½

[edgardi...@gmail.com]

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 

[sage-devel] Re: On changing Bernoulli(1) to +½

[Fredrik Johansson]

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/1b4bcfca-5200-4514-b082-e03dbab004bcn%40googlegroups.com.