Just reading through intsets and decided to knock out a few TODOs.
Change-Id: I677dbcc5ff934fbe0f0af09a4741e708a893f8db
Reviewed-on: https://go-review.googlesource.com/2733
Reviewed-by: Alan Donovan <adonovan@google.com>
Fixes various problems reported by go vet.
Change-Id: I12a6fdba8f911b21805d8e42903f8f6a5033790a
Reviewed-on: https://go-review.googlesource.com/2163
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Rewrite performed with this command:
sed -i '' 's_code.google.com/p/go\._golang.org/x/_g' \
$(grep -lr 'code.google.com/p/go.' *)
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/170920043
Also:
- increase sparsity of sets in benchmarks.
- removed TODO in forEach. Subword masks had no benefit.
- minor cleanup.
LGTM=crawshaw
R=crawshaw
CC=golang-codereviews
https://golang.org/cl/103470049
This consistently yields better performance with go/pointer.
Also: return int not word from ntz().
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/97570044
(I forgot about this when we added support for negative elements generally.)
We use floating point for negative numbers. The order of the
output is reversed from the previous (little-endian) behaviour
since it makes for more readable floating point.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/95570043
This is both easier to read and 25% shorter (helpful when
using String() as a map key for interning sets).
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/96370045
intsets.Sparse is a sparse bit vector. It uses space proportional
to the number of elements, not the maximum element (as is the case for a dense bit vector).
A forthcoming CL will make use of it in go/pointer, where it reduces
solve time by 78%. A similar representation is used for Andersen's
analysis in gcc and LLVM.
+ Tests.
LGTM=sameer, crawshaw, gri
R=gri
CC=crawshaw, golang-codereviews, sameer
https://golang.org/cl/10837043
