-
Notifications
You must be signed in to change notification settings - Fork 18k
proposal: intmath: new package #51563
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
Comments
For the |
Other algorithms that would be nice to have in such package, overflow safe average: return (a >> 2) + (b >> 2) + (a & b & 1) And / or a version that supports variadic input. |
It doesn't seem like this would need to be in the standard library. |
This proposal has been added to the active column of the proposals project |
@rsc A quick search for CeilDiv returned the following links:
As for arithmetic operations that will return an error on overflow instead of doing two's complement wrapping, it is possible that there are existing programs that are currently incorrect and should use the proposed API. |
I would rather have integer arithmetic operators, like Zig's |
@carlmjohnson I don't think it is necessary to add additional operators. With the API func AddIntN(a intn, b intn) (r intn, ok bool);
func AddUintN(a uintn, b uintn) (r uintm, ok bool); the programmer can do package main
import (
"math"
"golang.org/x/exp/imath" // or golang.org/x/exp/math/exact
)
func main() {
var a int32 = math.MaxInt32
var b int32 = 1
// saturating arithmetic
if r, ok := imath.AddInt32(a, b); !ok {
r = math.MaxInt32
}
// panic
if r, ok := imath.AddInt32(a, b); !ok {
panic("a + b overflowed")
}
} |
This still seems like something that should be done as a third-party package before we consider adding it to the standard library. |
Based on the discussion above, this proposal seems like a likely decline. |
(This message is more about a generic
I would say that packages aren't a good indication of a common need here, since a lot of these operations have a common “oneliner” equivalents. Which are, of course, easy to get wrong. A common need for at least Just for the hell of it, I looked up examples of
I could look up some other oneliners a bit later, if such arguments for this proposal or proposal #41157 are at all convincing. |
No change in consensus, so declined. |
In same cases, like pagination, it is necessary to do:
According to http://www.cs.nott.ac.uk/~rcb/G51MPC/slides/NumberLogic.pdf, the code can be optimized to avoid using floating point support:
According to https://stackoverflow.com/questions/17944/how-to-round-up-the-result-of-integer-division, a simplified version exists that avoid a possible overflow:
I have not verified these algorithms. However it should be evident that it is not a trivial problem.
In addition to
CeilDiv
there are also theCeilMod
,FloorDiv
,FloorMod
andAbs
functions.Finally I also propose to add functions so that integer overflow is reported with an error, like
AbsExact
,AddExact
,DivideExact
,MultiplyExact
,NegateExact
,SubtractExact
,CeilDivExact
,FloorDivExact
.These functions accept a signed integer (
int
) as arguments.References
The text was updated successfully, but these errors were encountered: