New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: math: Make -integer special cases for Gamma and Lgamma consistent #24757
Comments
Change https://golang.org/cl/105397 mentions this issue: |
I have suggested these changes here: https://go-review.googlesource.com/#/c/go/+/105397 |
The behavior cannot be changed if it's not a bug. |
@cznic It is a bug from the point of view of that if I define g == float64(s) * Exp(lg) to evaluate to |
Please specify if that's
Admitted, from the above it's clear I haven't looked at the math background of the problem at all, shame on me. |
I'll try to expand on each of those bullet points:
In a strict mathematical sense,
I've looked at some of the major languages used in scientific computing: Python, Mathematica, Matlab, and C/C++.
To be clear, my preference is for
The change I have pushed implements option 3. However, to be clear, any of the above would be more desirable than the current behavior. Additionally, looking again at the code for q := Abs(x)
p := Floor(q)
if q > 33 {
if x >= 0 {
y1, y2 := stirling(x)
return y1 * y2
}
// Note: x is negative but (checked above) not a negative integer,
// so x must be small enough to be in range for conversion to int64.
// If |x| were >= 2⁶³ it would have to be an integer.
/*<<< This sets the sign to +1 or -1 if based on whether Floor(Abs(x)) is even or odd. >>>*/
if ip := int64(p); ip&1 == 0 {
signgam = -1
}
z := q - p
if z > 0.5 {
p = p + 1
z = q - p
}
z = q * Sin(Pi*z)
/*<<< This returns ±Inf if z is an integer, with the sign decided above. >>>*/
if z == 0 {
return Inf(signgam)
}
(... etc.) See the comments marked by
|
The goal of the Go math package is to follow the C/C++ convention. It also sounds like we do that:
and you wrote:
It sure looks like Go is already matching C/C++. You say that for Lgamma the C/C++ routines return "without any sign information for Gamma" but that's actually not so. There is an external global int Again the goal is to match C/C++, and it looks like we're doing that. Am I missing something? |
@rsc I admittedly missed the
This is also stated in the C++ docs:
Once Do you have any further thoughts, with that in mind? Would you prefer to wait until the C/C++ standard changes and then change the Go standard to continue to match? |
Yes, as a general guideline we want to follow C and POSIX, not lead them. |
Given that we aimed to match C and do match C, closing this. If C changes, we might still choose to leave Go alone, for purposes of maintaining backwards compatibility. |
Straight from the documentation:
Gamma(x)
treatsx = 0
andx = -integer
differently for without proper justification. Presumably it is this way since the sign would depend on whether the negative integer (e.g. -1) is approached from above or below, and there is no way to represent that for non-positive integers except 0 (since Go supports ±0).However,
Lgamma(x)
does not make this distinction and always reports the sign ofGamma(-integer)
to be positive (questionable given the above point about approaching from above or below). https://play.golang.org/p/o-hiBPerYLSI propose that this behaviour is changed to be consistent. Either both
Gamma(-int)
andLgamma(-int)
should returnNaN
or both should return±Inf
. In particular, I propose that the value isInf
and the sign is determined by the sign of the residue, i.e.Res(Gamma, -n) = (-1)**n / n!
.Adopting this convention would make the functions consistent with each other and would provide a justification for the special behaviour chosen. It would also be consistent with the expected sign given by a ratio of Gamma functions, e.g.
Pochhammer(-4, 1) = Gamma(-3)/Gamma(-4) = -4
, which is well defined negative number (see http://www.wolframalpha.com/input/?i=pochhammer(-4,1)). (Note I'm not suggesting the standard library must implement ratios of Gamma functions, but it would be sensible for the signs to be consistent in my opinion).The text was updated successfully, but these errors were encountered: