I have written a tool to verify Printf calls, and although it's not
ready to be reviewed yet it's already uncovered a spate of problems
in the repository. I'm sending this CL to break the changes into
pieces; as the tool improves it will find more, I'm sure.
R=rsc
CC=golang-dev
https://golang.org/cl/3427043
Fixed:
* SetString calls in bitwise tests
* Aliasing problem with self bitwise test
* One test case that was just flat out wrong
* Slice panics in nat.or and nat.xor
* Aliasing problems in Int.And, Int.AndNot, Int.Or, Int.Xor
Fixes#1007.
R=gri
CC=golang-dev
https://golang.org/cl/1895049
- sign to determine if a value is < 0, == 0, > 0
- abs to compute absolute value
- Rat.IsInt to test if a rational number is representable as an integer
R=rsc
CC=golang-dev
https://golang.org/cl/1761042
* Allow an exponent part. This is necessary for exp/eval.
* Fix a bug for input that had no numbers after the decimal.
* In Int.SetString, allow a leading + sign.
* In Int.SetString, error if the input is "-" with no number.
* In nat.scan, normalize the resulting nat.
R=gri
CC=golang-dev
https://golang.org/cl/1733045
ModInverse is just a small wrapper around GcdInt, but it's nice to
have in order to be clear about what one is doing in other code.
R=gri, agl1
CC=golang-dev
https://golang.org/cl/1244045
- implemented setWord, use it where setUint64 is wrong
- divLarge: use fast mulWW, divWW; implemented mulWW, divWW
- better assembly code for addMulVVW
R=rsc
CC=golang-dev
https://golang.org/cl/1258042
- support for binary prefix 0b (to match fmt.Format)
- renamed nat.new -> nat.setUint64 for consistency
- more tests
R=r
CC=golang-dev
https://golang.org/cl/1233041
- removed last argument (n) from all core arithmetic routines;
instead, use the length of the result
- simplified nat.make implementation and chose a better capacity
for new values, removed a TODO in the process
Changing the constant e from 1 (old) to 4 (new) improved
pidigits -s -n 10000 by ~9% (on a 3.06GHz Intel Core 2 Duo):
user 0m3.882s (old)
user 0m3.549s (new)
R=rsc
CC=golang-dev
https://golang.org/cl/1133043
- no need to make copies in cases of aliases
- removed deprecated internal shift functions
- minor unrelated simplifications
This change improves pidigits -s -n10000 by almost 20%:
user 0m6.156s (old)
user 0m4.999s (new)
(pidigits -s -n20000 goes from ~25s to ~19s)
R=rsc
CC=golang-dev
https://golang.org/cl/1149041
- renamed Len -> BitLen, simplified implementation
- renamed old Div, Mod, DivMod -> Que, Rem, QuoRem
- implemented Div, Mod, DivMod (Euclidian definition, more
useful in a mathematical context)
- fixed a bug in Exp (-0 was possible)
- added extra tests to check normalized results everywhere
- uniformly set Int.neg flag at the end of computations
- minor cosmetic cleanups
- ran all tests
R=rsc
CC=golang-dev
https://golang.org/cl/1091041
- fixed a couple of bugs in the process
(shift right was incorrect for negative numbers)
- added more tests and made some tests more robust
- changed pidigits back to using shifts to multiply
by 2 instead of add
This improves pidigit -s -n 10000 by approx. 5%:
user 0m6.496s (old)
user 0m6.156s (new)
R=rsc
CC=golang-dev
https://golang.org/cl/963044
This results in an improvement of > 35% for the existing Mul benchmark
using the same karatsuba threshold, and an improvement of > 50% with
a slightly higher threshold (32 instead of 30):
big.BenchmarkMul 500 6731846 ns/op (old alg.)
big.BenchmarkMul 500 4351122 ns/op (new alg.)
big.BenchmarkMul 500 3133782 ns/op (new alg., new theshold)
Also:
- tweaked calibrate.go, use same benchmark as for Mul benchmark
R=rsc
CC=golang-dev
https://golang.org/cl/1037041
Plus:
- calibration "test" - include in tests with gotest -calibrate
- basic Mul benchmark
- extra multiplication tests
- various cleanups
This change improves multiplication speed of numbers >= 30 words
in length (current threshold; found empirically with calibrate):
The multiplication benchmark (multiplication of a variety of long numbers)
improves by ~35%, individual multiplies can be significantly faster.
gotest -benchmarks=Mul
big.BenchmarkMul 500 6829290 ns/op (w/ Karatsuba)
big.BenchmarkMul 100 10600760 ns/op
There's no impact on pidigits for -n=10000 or -n=20000
because the operands are are too small.
R=rsc
CC=golang-dev
https://golang.org/cl/1004042
There was a bug in makeN that caused lots of unnecessary
allocations. Fixing this exposed a few bugs in other
functions which worked when makeN allocated a new slice, but
failed when it simply resized an existing slice. The result
is a pretty big performance improvement. When running
pidigits, here were the numbers I got on amd64:
Before this change:
pidigits 10000
gcc -O2 pidigits.c -lgmp 2.09u 0.02s 2.11r
gc pidigits 12.68u 0.04s 12.72r
gc_B pidigits 12.71u 0.03s 12.75r
After:
pidigits 10000
gcc -O2 pidigits.c -lgmp 2.09u 0.00s 2.10r
gc pidigits 6.82u 0.00s 6.85r
gc_B pidigits 6.55u 0.01s 6.59r
R=rsc, gri
CC=golang-dev
https://golang.org/cl/953042
