proposal: math: Add Euler-Mascheroni constant

[ijxy]

The Euler-Macheroni, or Euler, constant is used internally in Gamma (to a lesser precision than other constants like Pi, Phi, E) and would be a reasonable addition, without adding any bloat or maintenance, to the standard library. This constant is important and I believe it would be a useful addition, and would also ensure that external libraries using the constant to implement more niche functions have a standard value to depend on.

I would simply add to consts.go:

Euler = 0.57721566490153286060651209008240243104215933593992359880576723 // https://oeis.org/A001620

[ijxy]

I've submitted a change here: https://go-review.googlesource.com/#/c/go/+/105396

[gopherbot]

Change https://golang.org/cl/105396 mentions this issue: math: add the Euler-Mascheroni constant

[ALTree]

cc @rsc @griesemer for decision.

[robpike]

When someone writes math.Euler, I wouldn't immediately think of γ. I know for shorthand it's called Euler's constant but it appears rarely. I'm not opposed to adding it (although I'm not enthusiastic either) but it needs a more evocative name.

[robpike]

Also, please note that it's bad form to send a change before the proposal has been discussed and approved. In this case it's a minor change, but in general it complicates matters and - worse - can split the discussion into two.

[ijxy]

@robpike Sorry for jumping the gun with the change - it was not my intention to complicate things.

If not Euler, what name would you suggest? Would EulerGamma work?

[griesemer]

FWIW. I'm not opposed per se to having another constant here (they are cheap), but I want to raise two points:

1) Why is this particular constant more important than others that we don't have here? I note that at the moment the number of constants is entirely reduced to some very elementary ones (e, pi, phi, their square roots, and then constants for logarithm conversions). Adding almost anything will open the flood gates to adding more. Where do we stop? Is there some specific set of constants that we should have?

2) If we add this, we need to have a better name than what has been proposed so far (but see below).

In summary, I think we should either leave things as they are (it's trivial to define whatever constant in your code); or, alternatively, have a clear plan of what set of constants we will accept, and then perhaps add them all at once, so we have a chance to look at their names collectively.

[rsc]

The ones that are there are there basically because they're defined in C (and we've done the same for the functions, mostly). There are many other constants we could possibly add. It doesn't really seem worth adding them one by one. Do you have a different criteria you are suggesting for what should be in Go's package math's exported constants?

[ijxy]

This seems to suggest that the constants in Go are not identical to those available in C. In particular,

In C, not in Go:

• Pi/2
• Pi/4
• 1/Pi
• 2/Pi
• 2/SqrtPi
• 1/Sqrt2

In Go, not in C:

• Phi
• SqrtPhi

Notably, the EulerGamma constant is absent from both. IMHO Phi is a nice addition; it's an interesting number with significance.

My original reason for suggesting EulerGamma was that it is actually already used in the standard library (in Gamma) and therefore may as well be exported. It is also not easily calculate using standard library functions and constants.

Is there much value to be gained from adding Pi/4 etc? Probably not. Maybe we could add LnPi, LnPhi (and LnEulerGamma if we decide to add EulerGamma) which might save an odd bit of precision over lnPi := math.Log(math.Pi), though I haven't tested this. That these numbers are already easily calculated from standard library constants and functions to high precision is probably sufficient IMO.

I believe a more useful addition would be to add complex128 versions of the package math constants to package cmplx, to save having to define them, e.g. pi := complex(math.Pi, 0), whenever one is using complex numbers.

[griesemer]

In Go it's easy to write Pi/2 and get a compile-time fully accurate representation useable for any runtime floating point precision, which is not necessarily the case in C. This is because we have "precise" (at least 256 bits of precision, and 512 bits in the existing compiler) constants and corresponding accurate constant arithmetic in Go. Thus it makes sense to leave away any constants that can be easily expression in form of fractions.

There's no compile time constant expression evaluation of square roots, so it makes sense to add the respective constant's square roots.

The current set of constants in Go is pretty minimal, and perhaps Phi could have been left away as well.

The question remains: Where do we set the boundaries of what should be added?

[agnivade]

There's no compile time constant expression evaluation of square roots, so it makes sense to add the respective constant's square roots.

We do have SqrtPi and Sqrt2. Or maybe I am missing something ?

To have a fixed criteria of matching with C, we should probably remove Phi as well. But that will be a breaking change. At the same time, if we are to add EulerGamma, this will lead to a slippery slope of people requesting for more constants to be added.

FWIW, I took a look at what constants are there in other programming languages:

• Python is very minimal. https://docs.python.org/3/library/math.html#constants (math.pi, math.e, math.tau)
• MS C++ is more in line with what we have. https://msdn.microsoft.com/en-us/library/4hwaceh6.aspx (E, LOG2E, LOG10E, LN2, LN10, PI, PI_2, PI_4, 1_PI, 2_PI, 2_SQRTPI, SQRT2, SQRT1_2)
• Same with Rust. https://doc.rust-lang.org/std/f64/consts/ (E, FRAC_1_PI, FRAC_1_SQRT_2, FRAC_2_PI, FRAC_2_SQRT_PI, FRAC_PI_2, FRAC_PI_3, FRAC_PI_4, FRAC_PI_6, FRAC_PI_8, LN_2, LN_10, LOG10_E, LOG2_E, PI, SQRT_2)
• And with JS. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math (Math.E, Math.LN2, Math.LN10, Math.LOG2E, Math.LOG10E, Math.PI, Math.SQRT1_2, Math.SQRT2, )

Going into more mathematics focused languages, we get some more esoteric constants added.

• Julia. https://docs.julialang.org/en/stable/stdlib/numbers/#General-Number-Functions-and-Constants-1 (pi, exp(big(1)), euler, catalan, golden ratio)
• Matlab. https://in.mathworks.com/help/symbolic/mupad_ug/mathematical-constants-available-in-mupad.html (e, pi, euler, catalan)

So as of now, we maintain parity with general purpose programming languages. But, if we are to add more, I think Euler and Catalan are 2 top contenders.

My original reason for suggesting EulerGamma was that it is actually already used in the standard library (in Gamma) and therefore may as well be exported.

Fair enough. In the same vein, then I think we should only have exported constants which are actually used in the standard library.

[ijxy]

@agnivade I believe the comment about it making sense to have Sqrt2 and SqrtPi was justifying their inclusion in the std lib (whereas Pi/4 etc aren't necessary due to constants having (essentially) arbitrary precision), not a statement that we don't already have them.

I completely understand the slippery slope argument and I agree that anything in the standard library should be there justifiably.

In the same vein, then I think we should only have exported constants which are actually used in the standard library.

IMO this presents a useful standard for what could (should?) be exported. However, I would probably seek to avoid making any breaking changes such as removing Phi and SqrtPhi.

[agnivade]

I believe the comment about it making sense to have Sqrt2 and SqrtPi was justifying their inclusion in the std lib (whereas Pi/4 etc aren't necessary due to constants having (essentially) arbitrary precision), not a statement that we don't already have them.

Ah, you may be right. I misread that.

[rsc]

I added Phi in Jan 2009. I have no idea why. If a proposal came in today to add it, we probably wouldn't.

I think we should just declare the set of constants finished at this point. The discussion here seems to agree that the Euler gamma is below the bar anyway and that we don't want to have a discussion about each new value.