Takes 3% off my all.bash run time.
For #10571.
Change-Id: I8f00f523d6919e87182d35722a669b0b96b8218b
Reviewed-on: https://go-review.googlesource.com/18087
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Also fix bug reported in CL 17510.
Found during fix of #13515 in CL 17672, but separate from the fix.
Change-Id: I4b1024569a98f5cfd2ebb442ec3d64356164d284
Reviewed-on: https://go-review.googlesource.com/17673
Reviewed-by: Robert Griesemer <gri@golang.org>
Replaced code that substituted 0 for rounded-up 1 with
code to try again. This has minimal effect on the existing
stream of random numbers, but restores uniformity.
Fixes#12290.
Change-Id: Ib68f0b0a4a173339bcd0274cc16509f7b0977de8
Reviewed-on: https://go-review.googlesource.com/17670
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
ˆ (U+02C6) is a circumflex accent, not an exponentiation operator.
In the rest of the source code for this package, exponentation is
written as **, so do the same here.
Change-Id: I107b85be242ab79d152eb8a6fcf3ca2b197d7658
Reviewed-on: https://go-review.googlesource.com/17671
Reviewed-by: Robert Griesemer <gri@golang.org>
Found by github user asukakenji.
Change-Id: I4c76316b69e8a243fb6bf280283f3722e728d853
Reviewed-on: https://go-review.googlesource.com/17641
Reviewed-by: Robert Griesemer <gri@golang.org>
Noticed by cmd/vet.
Expected values array produced by Python instead of Keisan because:
1) Keisan's website calculator is painfully difficult to copy/paste
values into and out of, and
2) after tediously computing e^(vf[i] * 10) - 1 via Keisan I
discovered that Keisan computing vf[i]*10 in a higher precision was
giving substantially different output values.
Also, testing uses "close" instead of "veryclose" because 386's
assembly implementation produces values for some of the test cases
that fail "veryclose". Curiously, Expm1(vf[i]*10) is identical to
Exp(vf[i]*10)-1 on 386, whereas with the portable implementation
they're only "veryclose".
Investigating these questions is left to someone else. I just wanted
to fix the cmd/vet warning.
Fixes#13101.
Change-Id: Ica8f6c267d01aa4cc31f53593e95812746942fbc
Reviewed-on: https://go-review.googlesource.com/16505
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Klaus Post <klauspost@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
The bug number was a typo, and I forgot to switch the implementation
back to if statements after the change from Float64bits in the first
patchset back to branching.
if statements can currently be inlined, but switch cannot (#13071)
Change-Id: I81d0cf64bda69186c3d747a07047f6a694f8fa70
Reviewed-on: https://go-review.googlesource.com/16446
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The compiler can do a fine job, and can also inline it.
From Jeremy Jackins's observation and rsc's recommendation in thread:
"Pure Go math.Abs outperforms assembly version"
https://groups.google.com/forum/#!topic/golang-dev/nP5mWvwAXZo
Updates #13095
Change-Id: I3066f8eaa327bb403173b29791cc8661d7c0532c
Reviewed-on: https://go-review.googlesource.com/16444
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Copy math package CL 12230 to cmplx package.
Change-Id: I3345b782b84b5b98e2b6a60d8774c7e7cede2891
Reviewed-on: https://go-review.googlesource.com/15500
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
As akalin points out in the bug, the comment previously claimed that the
probability that the input is prime given that the function returned
true is 1 - ¼ⁿ. But that's wrong: the correct statement is that the
probability of the function returning false given a composite input is
1 - ¼ⁿ.
This is not nearly as helpful, but at least it's truthful. A number of
other (correct) expressions are suggested on the bug, but I think that
the simplier one is preferable.
This change also notes that the function is not suitable for
adversarial inputs since it's deterministic.
Fixes#12274.
Change-Id: I6a0871d103b126ee5a5a922a8c6993055cb7b1ed
Reviewed-on: https://go-review.googlesource.com/14052
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Good enough for now.
Fixes#11241.
Change-Id: Ieb50809f104d20bcbe14daecac503f72486bec92
Reviewed-on: https://go-review.googlesource.com/15111
Reviewed-by: Alan Donovan <adonovan@google.com>
- more uniform naming
- test sign more deliberately
- remove superfluous test (JSON encoder always uses the JSON marshaler if present)
Change-Id: I37b1e367c01fc8bae1e06adbdb72dd366c08d5ce
Reviewed-on: https://go-review.googlesource.com/15110
Reviewed-by: Alan Donovan <adonovan@google.com>
- moved existing package documentation from nat.go to doc.go
- expanded on it
For #11241.
Change-Id: Ie75a2b0178a8904a4154307a1f5080d7efc5489a
Reviewed-on: https://go-review.googlesource.com/15042
Reviewed-by: Alan Donovan <adonovan@google.com>
Like int/rat/float conversions, move this functionality into separate
implementation and test files.
No implementation changes besides the move.
Change-Id: If19c45f5a72a57b95cbce2329724693ae5a4807d
Reviewed-on: https://go-review.googlesource.com/14997
Reviewed-by: Alan Donovan <adonovan@google.com>
- renamed (nat) itoa to utoa (since that's what it is)
- added (nat) itoa that takes a sign parameter; this helps removing a few string copies
- used buffers instead of string+ in Rat conversions
Change-Id: I6b37a6b39557ae311cafdfe5c4a26e9246bde1a9
Reviewed-on: https://go-review.googlesource.com/14995
Reviewed-by: Alan Donovan <adonovan@google.com>
This makes the Int conversion routines match the respective strconv
and big.Float conversion routines.
Change-Id: I5cfcda1632ee52fe87c5bb75892bdda76cc3af15
Reviewed-on: https://go-review.googlesource.com/14994
Reviewed-by: Alan Donovan <adonovan@google.com>
Current result of DecimalConversion benchmark (for future reference):
BenchmarkDecimalConversion-8 10000 204770 ns/op
Measured on Mac Mini (late 2012) running OS X 10.10.5,
2.3 GHz Intel Core i7, 8 GB 1333 MHz DDR3.
Also: Removed comment suggesting to implement decimal by representing
digits as numbers 0..9 rather than ASCII chars '0'..'9' to avoid
repeated +/-'0' operations. Tried and it appears (per above benchmark)
that the +/-'0' operations are neglibile but the addition conversion
passes around it are not and that it makes things significantly slower.
Change-Id: I6ee033b1172043248093cc5d02abff5fc54c2e7a
Reviewed-on: https://go-review.googlesource.com/14857
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
Enabled all but a handful of disabled Float formatting test cases.
Fixes#10991.
Change-Id: Id18e160e857be2743429a377000e996978015a1a
Reviewed-on: https://go-review.googlesource.com/14850
Reviewed-by: Alan Donovan <adonovan@google.com>
Instead of computing the final adjustment factor as a power of 10,
it's more efficient to split 10**e into 2**e * 5**e . Powers of 2
are trivially added to the Float exponent, and powers of 5 are
smaller and thus faster to compute.
Also, use a table of uint64 values rather than float64 values for
initial power value. uint64 values appear to be faster to convert
to Floats (useful for small exponents).
Added two small benchmarks to confirm that there's no regresssion.
benchmark old ns/op new ns/op delta
BenchmarkParseFloatSmallExp-8 17543 16220 -7.54%
BenchmarkParseFloatLargeExp-8 60865 59996 -1.43%
Change-Id: I3efd7556b023316f86f334137a67fe0c6d52f8ef
Reviewed-on: https://go-review.googlesource.com/14782
Reviewed-by: Alan Donovan <adonovan@google.com>
Add a Read function to Rand which reads random bytes into a buffer.
Fixes#8330
Change-Id: I85b90277b8be9287c6697def8dbefe0029b6ee06
Reviewed-on: https://go-review.googlesource.com/14522
Reviewed-by: Rob Pike <r@golang.org>
Block comments appear after a block in the HTML documentation generated by
godoc. Words like "following" should be avoided.
Change-Id: Iedfad67f4b8b9c84f128b98b9b06fa76919af388
Reviewed-on: https://go-review.googlesource.com/14357
Reviewed-by: Rob Pike <r@golang.org>
For primes which are 3 mod 4, using Tonelli-Shanks is slower
and more complicated than using the identity
a**((p+1)/4) mod p == sqrt(a)
For 2^450-2^225-1 and 2^10860-2^5430-1, which are 3 mod 4:
BenchmarkModSqrt225_TonelliTri 1000 1135375 ns/op
BenchmarkModSqrt225_3Mod4 10000 156009 ns/op
BenchmarkModSqrt5430_Tonelli 1 3448851386 ns/op
BenchmarkModSqrt5430_3Mod4 2 914616710 ns/op
~2.6x to 7x faster.
Fixes#11437 (which is a prime choice of issues to fix)
Change-Id: I813fb29454160483ec29825469e0370d517850c2
Reviewed-on: https://go-review.googlesource.com/11522
Reviewed-by: Adam Langley <agl@golang.org>
Even though the umul/uquo functions expect two valid, finite big.Floats
arguments, SetString was calling them with possibly Inf values, which
resulted in bogus return values.
Replace umul and udiv calls with Mul and Quo calls to fix this. Also,
fix two wrong tests.
See relevant issue on issue tracker for a detailed explanation.
Fixes#11341
Change-Id: Ie35222763a57a2d712a5f5f7baec75cab8189a53
Reviewed-on: https://go-review.googlesource.com/13778
Reviewed-by: Robert Griesemer <gri@golang.org>
This is not a functional change.
Also:
- minor cleanups, better comments
- uniform spelling of noun "zeros" (per OED)
Fixes#11277.
Change-Id: I1726f358ce15907bd2410f646b02cf8b11b919cd
Reviewed-on: https://go-review.googlesource.com/11267
Reviewed-by: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Urge users of math/rand to consider using crypto/rand when doing
security-sensitive work.
Related to issue #11871. While we haven't reached consensus on how
to make the package inherently safer, everyone agrees that the docs
for math/rand can be improved.
Change-Id: I576a312e51b2a3445691da6b277c7b4717173197
Reviewed-on: https://go-review.googlesource.com/12900
Reviewed-by: Rob Pike <r@golang.org>
- Make Log2 exact for powers of two.
- Fix error tolerance function to make tolerance
a function of the correct (expected) value.
Fixes#9066.
Change-Id: I0320a93ce4130deed1c7b7685627d51acb7bc56d
Reviewed-on: https://go-review.googlesource.com/12230
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The previous commit (git 2ae77376) just did golang.org. This one
includes golang.org subdomains like blog, play, and build.
Change-Id: I4469f7b307ae2a12ea89323422044e604c5133ae
Reviewed-on: https://go-review.googlesource.com/12071
Reviewed-by: Rob Pike <r@golang.org>
The one in misc/makerelease/makerelease.go is particularly bad and
probably warrants rotating our keys.
I didn't update old weekly notes, and reverted some changes involving
test code for now, since we're late in the Go 1.5 freeze. Otherwise,
the rest are all auto-generated changes, and all manually reviewed.
Change-Id: Ia2753576ab5d64826a167d259f48a2f50508792d
Reviewed-on: https://go-review.googlesource.com/12048
Reviewed-by: Rob Pike <r@golang.org>
Russ Cox
Robert Griesemer
David Chase
Brad Fitzpatrick
Jingguo Yao
Yao Zhang
Matthew Dempsky
Caleb Spare
David Crawshaw
Charlie Dorian
Damian Gryski
Ilya Tocar
Adam Langley
Spencer Nelson
Alberto Donizetti
Rob Pike
Konstantin Shaposhnikov
David Leon Gil
Tarmigan Casebolt
Andrey Petrov