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
- no empty lines inside empty structs and interfaces
- top-level declarations are separated by a blank line if
a) they are of different kind (e.g. const vs type); or
b) there are documentation comments associated with a
declaration (this is new)
- applied gofmt -w misc src
The actual changes are in go/printer/nodes.go:397-400 (empty structs/interfaces),
and go/printer/printer.go:307-309 (extra line break). The remaining
changes are cleanups w/o changing the existing functionality.
Fixes issue 2570.
R=rsc
CC=golang-dev
https://golang.org/cl/5493057
I was confused by the existence of two portable Hypot
routines in the tree when I cleaned things up, and I made
ARM use the wrong (imprecise) one. Use the right one,
and delete the wrong one.
Fixes arm build.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5485065
This will be nicer to the automatic tools.
It requires a few more assembly stubs
but fewer Go files.
There are a few instances where it looks like
there are new blobs of code, but they are just
being copied out of deleted files.
There is no new code here.
Suppose you have a portable implementation for Sin
and a 386-specific assembly one. The old way to
do this was to write three files
sin_decl.go
func Sin(x float64) float64 // declaration only
sin_386.s
assembly implementation
sin_port.go
func Sin(x float64) float64 { ... } // pure-Go impl
and then link in either sin_decl.go+sin_386.s or
just sin_port.go. The Makefile actually did the magic
of linking in only the _port.go files for those without
assembly and only the _decl.go files for those with
assembly, or at least some of that magic.
The biggest problem with this, beyond being hard
to explain to the build system, is that once you do
explain it to the build system, godoc knows which
of sin_port.go or sin_decl.go are involved on a given
architecture, and it (correctly) ignores the other.
That means you have to put identical doc comments
in both files.
The new approach, which is more like what we did
in the later packages math/big and sync/atomic,
is to have
sin.go
func Sin(x float64) float64 // decl only
func sin(x float64) float64 {...} // pure-Go impl
sin_386.s
// assembly for Sin (ignores sin)
sin_amd64.s
// assembly for Sin: jmp sin
sin_arm.s
// assembly for Sin: jmp sin
Once we abandon Makefiles we can put all the assembly
stubs in one source file, so the number of files will
actually go down.
Chris asked whether the branches cost anything.
Given that they are branching to pure-Go implementations
that are not typically known for their speed, the single
direct branch is not going to be noticeable. That is,
it's on the slow path.
An alternative would have been to preserve the old
"only write assembly files when there's an implementation"
and still have just one copy of the declaration of Sin
(and thus one doc comment) by doing:
sin.go
func Sin(x float64) float64 { return sin(x) }
sin_decl.go
func sin(x float64) float64 // declaration only
sin_386.s
// assembly for sin
sin_port.go
func sin(x float64) float64 { portable code }
In this version everyone would link in sin.go and
then either sin_decl.go+sin_386.s or sin_port.go.
This has an extra function call on all paths, including
the "fast path" to get to assembly, and it triples the
number of Go files involved compared to what I did
in this CL. On the other hand you don't have to
write assembly stubs. After starting down this path
I decided that the assembly stubs were the easier
approach.
As for generating the assembly stubs on the fly, much
of the goal here is to eliminate magic from the build
process, so that zero-configuration tools like goinstall
or the new go tool can handle this package.
R=golang-dev, r, cw, iant, r
CC=golang-dev
https://golang.org/cl/5488057
Acosh, Asinh, Atanh, Ceil, Floor, Trunc, Mod and Remainder affected. These changes add some non-finite arguments and results (and -0.0 results).
R=rsc, golang-dev
CC=golang-dev
https://golang.org/cl/5469046
Max returns +Inf if x or y is +Inf; else it returns NaN if either x or y is NaN. Max(-0, -0) returns -0.
Min returns -Inf if x or y is -Inf; else it returns NaN if either x or y is NaN. Min(+0, -0) returns -0.
Dim(+Inf, +Inf) = NaN, Dim(-Inf, -Inf) = NaN and Dim(NaN, anything) = NaN.
Also, change "conditions" to "cases" for Sin (missed it in previous CL).
R=rsc, dave
CC=golang-dev
https://golang.org/cl/5437137
Sincos via sincos.go is 35.4 ns/op, via sincos_amd64.s is 37.4 ns/op on 2.53 GHz Intel Core 2 Duo (Mac OS X).
R=rsc, golang-dev
CC=golang-dev
https://golang.org/cl/5447045
This change adds the second aspect to the conversion code, the
use of large divisiors (powers of big base) to greatly speed up
the divsion of large numbers. Speedups of 30x are common in the
large cases. Also includes new tests and tuning code for the
key internal parameters.
R=gri
CC=golang-dev
https://golang.org/cl/5438058
No need for creating a new nat each time.
Per Roger Peppe's suggestion; assuming
nat(nil) produces better code than nat{}.
R=rsc
CC=golang-dev
https://golang.org/cl/5375092
Converting from polynomial constants to counted array speeds up Lgamma from 51.3 to 37.7 ns/op. Variables renamed in Gamma to avoid overlap in Lgamma.
R=rsc, golang-dev
CC=golang-dev
https://golang.org/cl/5359045
This contains the files that required handiwork, mostly
Makefiles with updated TARGs, plus the two packages
with modified package names.
html/template/doc.go needs a separate edit pass.
test/fixedbugs/bug358.go is not legal go so gofix fails on it.
R=rsc
CC=golang-dev
https://golang.org/cl/5340050
Having the compiler count the number of array elements speeds up Gamma from 63.7 to 56.6 ns/op.
R=rsc, golang-dev, r
CC=golang-dev
https://golang.org/cl/5362043
This is Go 1 package renaming CL #2.
This one merely moves the source; the import strings will be
changed after the next weekly release.
exp/template/html -> html/template
big -> math/big
cmath -> math/cmplx
rand -> math/rand
syslog -> log/syslog
The only edits are in Makefiles and deps.bash.
Note that this CL moves exp/template/html out of exp. I decided
to do that so all the renamings can be done together, even though
the API (and that of template, for that matter) is still fluid.
R=r, rsc
CC=golang-dev
https://golang.org/cl/5332053
