our old choice is not working properly at least on VFPv2 in
ARM1136JF-S (it's not preserved across float64->float32 conversions).
Fixes#3745.
R=dave, rsc
CC=golang-dev
https://golang.org/cl/6344078
The previous implementation used to have a O(n) recursion
depth for unbalanced inputs. A test is added to check that a
reasonable amount of bytes is allocated in this case.
Fixes#3807.
R=golang-dev, dsymonds, gri
CC=golang-dev, remy
https://golang.org/cl/6345075
The use of math.Pow for mere squaring can be extremely
slow on soft-float ARM. Even on systems with hardware
floating-point, a speedup in test duration is observed.
On amd64
Before: ok math/rand 2.009s
After: ok math/rand 0.340s
Fixes#3740.
R=dave, golang-dev, r, r
CC=golang-dev
https://golang.org/cl/6348061
The switch at the beginning of the function already ensures n > 1,
so testing for n < 2 is redundant.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/6350051
pkg/math/all_test.go tests Atan (and therefore Asin and Acos) to a
relative accuracy of 4e-16, but the test vector misses values where
the old algorithm was in error by more than that. For example:
x newError oldError
0.414215746 1.41e-16 -4.24e-16
0.414216076 1.41e-16 -4.24e-16
0.414217632 1.41e-16 -4.24e-16
0.414218770 1.41e-16 -4.24e-16
0.414225466 0 -5.65e-16
0.414226244 1.41e-16 -4.24e-16
0.414228756 0 -5.65e-16
0.414235089 0 -5.65e-16
0.414237070 0 -5.65e-16
R=rsc, golang-dev
CC=golang-dev
https://golang.org/cl/6302093
An attempt to profit from CL 6176043 (fix to superpolinomial
runtime of karatsuba multiplication) and determine a better
karatsuba threshold. The result indicates that 32 is still
a reasonable value. Left the threshold as is (== 32), but
made some minor changes to the calibrate code which are
worthwhile saving (use of existing benchmarking code for
better results, better use of package time).
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6260062
Ceil to 4.81 from 20.6 ns/op
Floor to 4.37 from 13.5 ns/op
Trunc to 3.97 from 14.3 ns/op
Also changed three MOVSDs to MOVAPDs in log_amd64.s
R=rsc, golang-dev
CC=golang-dev
https://golang.org/cl/6262048
The documentation says so, but in the case of a normalized
integral Rat, the denominator was a new value. Changed the
internal representation to use an Int to represent the
denominator (with the sign ignored), so a reference to it
can always be returned.
Clarified documentation and added test cases.
Fixes#3521.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6237045
Also: simplified some existing tests.
No support for Rats for now because the precision-preserving
default notation (fractions of the form a/b) is not a valid
JSON value.
Fixes#3657.
R=golang-dev, bradfitz, rsc
CC=golang-dev
https://golang.org/cl/6211079
Replaced /*-style comments with line comments;
there are two many *'s already in those lines.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/5699051
I am making a unilateral decision here. I could also settle for returning 0,
as long it's documented, but I argue that it's equivalent to an index
out of bounds.
Fixes#2892.
R=golang-dev, dsymonds, rsc
CC=golang-dev
https://golang.org/cl/5676079
go/doc: move Examples to go/ast
cmd/go: use go/doc to read examples
src/pkg: update examples to use new convention
This is to make whole file examples more readable. When presented as a
complete function, preceding an Example with its output is confusing.
The new convention is to put the expected output in the final comment
of the example, preceded by the string "output:" (case insensitive).
An idiomatic example looks like this:
// This example demonstrates Foo by doing bar and quux.
func ExampleFoo() {
// example body that does bar and quux
// Output:
// example output
}
R=rsc, gri
CC=golang-dev
https://golang.org/cl/5673053
This is a minimal API extension, it makes it possible
to implement missing Int functionality externally w/o
compromising efficiency. It is the hope that this will
reduce the number of feature requests going directly
into the big package.
Also: Fixed some naming inconsistencies: The receiver
is only called z when it is also the result.
R=golang-dev, agl
CC=golang-dev
https://golang.org/cl/5607055
Consequently, remove many package Makefiles,
and shorten the few that remain.
gomake becomes 'go tool make'.
Turn off test phases of run.bash that do not work,
flagged with $BROKEN. Future CLs will restore these,
but this seemed like a big enough CL already.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5601057
The bitLen function currently shifts out blocks of 8 bits at a time.
This change replaces this sorta-linear algorithm with a log(N)
one (shift out 16 bits, then 8, then 4, then 2, then 1).
I left the start of it linear at 16 bits at a time so that
the function continues to work with 32 or 64 bit values
without any funkiness.
The algorithm is similar to several of the nlz ("number of
leading zeros") algorithms from "Hacker's Delight" or the
"bit twiddling hacks" pages.
Doesn't make a big difference to the existing benchmarks, but
I'm using the code in a different context that calls bitLen
much more often, so it seemed worthwhile making the existing
codebase faster so that it's a better building block.
Microbenchmark results on a 64-bit Macbook Pro using 6g from weekly.2012-01-20:
benchmark old ns/op new ns/op delta
big.BenchmarkBitLen0 4 6 +50.12%
big.BenchmarkBitLen1 4 6 +33.91%
big.BenchmarkBitLen2 6 6 +3.05%
big.BenchmarkBitLen3 7 6 -19.05%
big.BenchmarkBitLen4 9 6 -30.19%
big.BenchmarkBitLen5 11 6 -42.23%
big.BenchmarkBitLen8 16 6 -61.78%
big.BenchmarkBitLen9 5 6 +18.29%
big.BenchmarkBitLen16 18 7 -60.99%
big.BenchmarkBitLen17 7 6 -4.64%
big.BenchmarkBitLen31 19 7 -62.49%
On an ARM machine (with the previous weekly):
benchmark old ns/op new ns/op delta
big.BenchmarkBitLen0 37 50 +36.56%
big.BenchmarkBitLen1 59 51 -13.69%
big.BenchmarkBitLen2 74 59 -20.40%
big.BenchmarkBitLen3 92 60 -34.89%
big.BenchmarkBitLen4 110 59 -46.09%
big.BenchmarkBitLen5 127 60 -52.68%
big.BenchmarkBitLen8 181 59 -67.24%
big.BenchmarkBitLen9 78 60 -23.05%
big.BenchmarkBitLen16 199 69 -65.13%
big.BenchmarkBitLen17 91 70 -23.17%
big.BenchmarkBitLen31 210 95 -54.43%
R=golang-dev, dave, edsrzf, gri
CC=golang-dev
https://golang.org/cl/5570044
TestNonStandardNormalValues runs 1.5s,
the change reduces it to 0.2s in short mode.
The problem is with slow machines, emulators and dynamic tools.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5540065
