| Age | Commit message (Collapse) | Author |
|---|
|
As part of #42026, these helpers from io/ioutil were moved to os.
(ioutil.TempFile and TempDir became os.CreateTemp and MkdirTemp.)
Update the Go tree to use the preferred names.
As usual, code compiled with the Go 1.4 bootstrap toolchain
and code vendored from other sources is excluded.
ReadDir changes are in a separate CL, because they are not a
simple search and replace.
For #42026.
Change-Id: If318df0216d57e95ea0c4093b89f65e5b0ababb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/266365
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
This is a partial revert of https://go-review.googlesource.com/c/go/+/248219
because we found that a non-trivial amount of code erroneously calls
ParseFloat(s, 10) or even ParseFloat(s, 0) and expects it to work --
before that change was merged, ParseFloat accepted a bitSize of
anything other than 32 or 64 to mean 64 (and ParseComplex was similar).
So revert that behavior to avoid breaking people's code, and add tests
for this.
I may add a vet check to flag ParseFloat(s, not_32_or_64) in a later
change.
See #42297 for more details.
Change-Id: I4bc0156bd74f67a39d5561b6e5fde3f2d20bd622
Reviewed-on: https://go-review.googlesource.com/c/go/+/267319
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
In ParseComplex, the "size" passed to parseFloatPrefix should be 64 for
complex128, not 128. It still works because of how parseFloatPrefix
is forgiving about the size if it's not 32, but worth fixing anyway.
Make ParseComplex and ParseFloat return a bit size error for anything
other than 128 or 64 (for ParseComplex), or 64 or 32 (for ParseFloat).
Add "InvalidBitSize" tests for these cases.
Add tests for ParseComplex with bitSize==64: this is done in a similar
way to how the ParseFloat 32-bit tests work, re-using the tests for the
larger bit size.
Add tests for FormatComplex -- there were none before.
Fixes #40706
Change-Id: I16ddd546e5237207cc3b8c2181dd708eca42b04f
Reviewed-on: https://go-review.googlesource.com/c/go/+/248219
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Minux Ma <minux@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
In many cases, it is not necessary to parse long
decimal mantissas entirely to produce the correctly
rounded floating-point number. It is enough to parse
the short, rounded lower and upper bounds and in most cases
they round to the same floating point number because uint64
can hold 19 digits.
Previously this case was handled by the extFloat code path
(Grisu3 algorithm).
name old time/op new time/op delta
Atof64Big-4 1.07µs ± 2% 0.11µs ± 2% -89.61% (p=0.000 n=10+9)
Atof64RandomLongFloats-4 8.03µs ± 2% 0.14µs ± 7% -98.24% (p=0.000 n=10+10)
Atof32RandomLong-4 760ns ± 1% 156ns ± 0% -79.46% (p=0.000 n=10+8)
Benchmarks versus extFloat:
name old time/op new time/op delta
Atof64Big-4 121ns ± 3% 111ns ± 2% -7.93% (p=0.000 n=10+9)
Atof64RandomLongFloats-4 144ns ± 1% 142ns ± 7% ~ (p=0.167 n=10+10)
Atof32RandomLong-4 129ns ± 1% 156ns ± 0% +21.12% (p=0.000 n=10+8)
Change-Id: Id734b8c11e74b49a444fda67ee72870ae9422e60
Reviewed-on: https://go-review.googlesource.com/c/go/+/264677
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
|
|
Prior to this commit, strconv.ParseFloat (known in C as atof) takes the
first of four algorithms to succeed: atof64exact, eiselLemire64,
extFloat, fallback. The Eisel-Lemire implementation is a recent addition
but, now that it exists, the extFloat implementation (based on the
algorithm used by https://github.com/google/double-conversion) is
largely redundant. This Go program:
func parseOneMillionFloats(bitSize int, normallyDistributed bool) {
rng := rand.New(rand.NewSource(1))
for i := 0; i < 1_000_000; {
x := 0.0
if normallyDistributed {
x = rng.NormFloat64()
} else if bitSize == 32 {
x = float64(math.Float32frombits(rng.Uint32()))
} else {
x = math.Float64frombits(
uint64(rng.Uint32())<<32 | uint64(rng.Uint32()))
}
if math.IsInf(x, 0) {
continue
}
s := strconv.FormatFloat(x, 'g', -1, bitSize)
strconv.ParseFloat(s, bitSize)
i++
}
}
triggers the four algorithms by these percentages:
bitSize=32, normallyDistributed=false
07.4274% atof32exact
91.2982% eiselLemire32
00.8673% extFloat
00.0269% fallback
bitSize=32, normallyDistributed=true
27.6356% atof32exact
72.3641% eiselLemire32
00.0003% extFloat
00.0000% fallback
bitSize=64, normallyDistributed=false
01.2076% atof64exact
98.6216% eiselLemire64
00.1081% extFloat
00.0130% fallback
bitSize=64, normallyDistributed=true
24.8826% atof64exact
75.1174% eiselLemire64
00.0000% extFloat
00.0000% fallback
This commit removes the extfloat.go atof code (but keeps the extfloat.go
ftoa code for now), reducing the number of atof algorithms from 4 to 3.
The benchmarks (below) show some regressions but these are arguably
largely artificial situations.
Atof*RandomBits generates uniformly distributed uint32/uint64 values and
reinterprets the bits as float32/float64 values. The change in headline
numbers (arithmetic means) are primarily due to relatively large changes
for relatively rare cases.
Atof64Big parses a hard-coded "123456789123456789123456789".
name old time/op new time/op delta
Atof64Decimal-4 47.1ns ± 1% 47.4ns ± 2% ~ (p=0.516 n=5+5)
Atof64Float-4 56.4ns ± 1% 55.9ns ± 2% ~ (p=0.206 n=5+5)
Atof64FloatExp-4 68.8ns ± 0% 68.7ns ± 1% ~ (p=0.516 n=5+5)
Atof64Big-4 157ns ± 2% 1528ns ± 2% +875.99% (p=0.008 n=5+5)
Atof64RandomBits-4 156ns ± 1% 186ns ± 1% +19.49% (p=0.008 n=5+5)
Atof64RandomFloats-4 144ns ± 0% 143ns ± 1% ~ (p=0.365 n=5+5)
Atof32Decimal-4 47.6ns ± 1% 47.5ns ± 2% ~ (p=0.714 n=5+5)
Atof32Float-4 54.3ns ± 2% 54.1ns ± 1% ~ (p=0.532 n=5+5)
Atof32FloatExp-4 75.2ns ± 1% 75.7ns ± 3% ~ (p=0.794 n=5+5)
Atof32Random-4 108ns ± 1% 120ns ± 1% +10.54% (p=0.008 n=5+5)
Fixes #36657
Change-Id: Id3c4e1700f969f885b580be54c8892b4fe042a79
Reviewed-on: https://go-review.googlesource.com/c/go/+/264518
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Nigel Tao <nigeltao@golang.org>
|
|
This does for ParseFloat(etc, 32) what commit a2eb53c571 did for
ParseFloat(etc, 64).
name old time/op new time/op delta
Atof32Decimal-4 48.3ns ± 4% 48.8ns ± 2% ~ (p=0.548 n=5+5)
Atof32Float-4 56.2ns ± 5% 54.7ns ± 3% ~ (p=0.246 n=5+5)
Atof32FloatExp-4 104ns ± 0% 76ns ± 2% -27.19% (p=0.008 n=5+5)
Atof32Random-4 142ns ± 2% 109ns ± 1% -23.07% (p=0.008 n=5+5)
Change-Id: I6ee5a2f2d791d4fe3028f1d40aca96400120fda0
Reviewed-on: https://go-review.googlesource.com/c/go/+/264517
Trust: Nigel Tao <nigeltao@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
This grows the exp10 range for which the Eisel-Lemire algorithm applies
from [-307, +288] to [-348, +347], roughly equivalent to the existing
powersOfTen table in extfloat.go (which uses a different algorithm).
name old time/op new time/op delta
Atof64Decimal-4 48.4ns ± 1% 48.7ns ± 3% ~ (p=0.698 n=5+5)
Atof64Float-4 57.9ns ± 1% 58.1ns ± 2% ~ (p=0.873 n=5+5)
Atof64FloatExp-4 71.8ns ± 2% 72.2ns ± 2% ~ (p=0.730 n=5+5)
Atof64Big-4 165ns ± 1% 164ns ± 1% ~ (p=0.635 n=5+5)
Atof64RandomBits-4 165ns ± 1% 165ns ± 6% ~ (p=0.143 n=5+5)
Atof64RandomFloats-4 147ns ± 2% 147ns ± 1% ~ (p=0.857 n=5+5)
Change-Id: Idf7dc5297db6db2bd9e0bd4cb0e55e021916fa43
Reviewed-on: https://go-review.googlesource.com/c/go/+/264139
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Nigel Tao <nigeltao@golang.org>
|
|
This is somewhat academic (and no tests failed before this commit),
since func atof64 only calls func eiselLemire when func atof64exact
fails, and func atof64exact doesn't fail when parsing positive or
negative zeroes. But it's still worth fixing.
Change-Id: Ibe6ef4c8fd96827673b711d5456003fbc447e39c
Reviewed-on: https://go-review.googlesource.com/c/go/+/264140
Trust: Nigel Tao <nigeltao@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Also fix BenchmarkAtof64Random* to initialize the test data when none
of the TestAtof* tests are run.
Passing "go test -test.count=5 -test.run=xxx -test.bench=Atof64" on to
benchstat:
name old time/op new time/op delta
Atof64Decimal-4 47.9ns ± 0% 48.3ns ± 1% ~ (p=0.238 n=4+5)
Atof64Float-4 58.3ns ± 3% 57.7ns ± 0% ~ (p=0.151 n=5+5)
Atof64FloatExp-4 107ns ± 0% 71ns ± 1% -33.89% (p=0.016 n=4+5)
Atof64Big-4 163ns ± 0% 166ns ± 2% ~ (p=0.159 n=4+5)
Atof64RandomBits-4 299ns ± 1% 166ns ± 1% -44.41% (p=0.008 n=5+5)
Atof64RandomFloats-4 188ns ± 1% 144ns ± 0% -23.03% (p=0.008 n=5+5)
The canada.json file from github.com/miloyip/nativejson-benchmark is
full of geospatial coordinates (i.e. numbers). With this program:
src, _ := ioutil.ReadFile("canada.json")
for i := 0; i < 5; i++ {
now := time.Now()
for j := 0; j < 10; j++ {
dst := interface{}(nil)
if err := json.Unmarshal(src, &dst); err != nil {
log.Fatal(err)
}
}
fmt.Println(time.Since(now))
}
Median of the 5 printed numbers, lower is better.
Before: 760.819549ms
After: 702.651646ms
Ratio: 1.08x
The new detailedPowersOfTen table weighs in at 596 * 16 = 9536 bytes,
but some of that weight gain can be clawed back, in a follow-up commit,
that folds in the existing powersOfTen table in extfloat.go.
RELNOTE=yes
Change-Id: I3953110deaa1f5f6941e88e8417c4665b649ed80
Reviewed-on: https://go-review.googlesource.com/c/go/+/260858
Run-TryBot: Nigel Tao <nigeltao@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Nigel Tao <nigeltao@golang.org>
|
|
Fixes #40755
Change-Id: I14b3977317994095db8ae1bd873c174641209356
Reviewed-on: https://go-review.googlesource.com/c/go/+/248765
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
The recently added function parseFloatPrefix tested the entire
string for correct placement of separators rather than just the
consumed part. The 4-char fix is in readFloat (atof.go:303).
Added more tests. Also added some white space for nicer
grouping of the test cases.
While at it, removed the need for calling testing.Run.
Fixes #38962.
Change-Id: Ifce84f362bb4ede559103f8d535556d3de9325f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/233017
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Adds two functions to deal with complex numbers:
* FormatComplex
* ParseComplex
ParseComplex accepts complex numbers in this format: N+Ni
Fixes #36771
Change-Id: Id184dc9e277e5fa01a714ad656a88255ead05085
GitHub-Last-Rev: 036a075d36363774a95f6000b7c4098896474744
GitHub-Pull-Request: golang/go#36815
Reviewed-on: https://go-review.googlesource.com/c/go/+/216617
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
parseFloatPrefix accepts a string if it has a valid floating-point
number as prefix. Make sure that "infi", "infin", ... etc. are
accepted as valid numbers "inf" with suffix "i", "in", etc. This
is important for parsing complex numbers such as "0+infi".
This change does not affect the correctness of ParseFloat because
ParseFloat rejects strings that contain a suffix after a valid
floating-point number.
Updates #36771.
Change-Id: Ie1693a8ca2f8edf07b57688e0b35751b7100d39d
Reviewed-on: https://go-review.googlesource.com/c/go/+/231237
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
parseFloatPrefix will make it easier to implement ParseComplex.
Verified that there's no relevant performance impact:
Benchmarks run on a "quiet" MacBook Pro, 3.3GHz Dual-Core Intel Core i7,
with 16GB 2133MHz LPDDR3 RAM running macOS 10.15.4.
name old time/op new time/op delta
Atof64Decimal-4 38.2ns ± 4% 38.4ns ± 3% ~ (p=0.802 n=5+5)
Atof64Float-4 41.1ns ± 3% 43.0ns ± 1% +4.77% (p=0.008 n=5+5)
Atof64FloatExp-4 71.9ns ± 3% 70.1ns ± 1% ~ (p=0.063 n=5+5)
Atof64Big-4 124ns ± 5% 119ns ± 0% ~ (p=0.143 n=5+4)
Atof64RandomBits-4 57.2ns ± 1% 55.7ns ± 2% -2.66% (p=0.016 n=4+5)
Atof64RandomFloats-4 56.8ns ± 1% 56.9ns ± 4% ~ (p=0.556 n=4+5)
Atof32Decimal-4 35.4ns ± 5% 35.9ns ± 0% ~ (p=0.127 n=5+5)
Atof32Float-4 39.6ns ± 7% 40.3ns ± 1% ~ (p=0.135 n=5+5)
Atof32FloatExp-4 73.7ns ± 7% 71.9ns ± 0% ~ (p=0.175 n=5+4)
Atof32Random-4 103ns ± 6% 98ns ± 2% -5.03% (p=0.008 n=5+5)
Updates #36771.
Change-Id: I8ff66b582ae8b468d89c9ffc35c569c735cf0341
Reviewed-on: https://go-review.googlesource.com/c/go/+/230737
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
IntSize is an untyped constant that does not need explicit conversion.
Annotating IntSize as an int and running github.com/mdempsky/unconvert
reveals these two cases.
Fixes #38682.
Change-Id: I014646b7457ddcde32474810153229dcf0c269c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/230306
Run-TryBot: Akhil Indurti <aindurti@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Change-Id: I6f006ba72e1711ba2a24cd71552855ad88284eec
Reviewed-on: https://go-review.googlesource.com/c/go/+/227797
Reviewed-by: Rémy Oudompheng <remyoudompheng@gmail.com>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
|
|
Instead use string(r) where r has type rune.
This is in preparation for a vet warning for string(i).
Updates #32479
Change-Id: Ic205269bba1bd41723950219ecfb67ce17a7aa79
Reviewed-on: https://go-review.googlesource.com/c/go/+/220844
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Akhil Indurti <aindurti@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Toshihiro Shiino <shiino.toshihiro@gmail.com>
|
|
Fixes #36778
Change-Id: I3c4ce100fc219bda0ff1d7a086c2309ed695691d
Reviewed-on: https://go-review.googlesource.com/c/go/+/216478
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
|
Apply the suggestions made in the too-late review of
golang.org/cl/137215
to move the comments to a separate line and use proper
punctuation.
Change-Id: If2b4e5ce8af8c78fa51280d5c87c852a76dae459
Reviewed-on: https://go-review.googlesource.com/c/go/+/206125
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
This does not include an upgrade of golang.org/x/net.
This is optional and best done as a separate CL.
Change-Id: Ifecc3fb6e3b7fe026b4ddefbe637186a3445b0bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/204658
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
Updates #30322
This change adds the Unwrap method to NumError. NumError is the only custom error type of the strconv that has a nested exported error.
Change-Id: I8774886348880365a83f72a1d106276def27dffe
GitHub-Last-Rev: 712f3df8842f48f988cebfc527476781a7cf7140
GitHub-Pull-Request: golang/go#34213
Reviewed-on: https://go-review.googlesource.com/c/go/+/194563
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Run underscore validation only if we have seen underscores.
Some performance results on my laptop:
name old time/op new time/op delta
Atof64Decimal-12 30.5ns ± 0% 23.8ns ± 0% -22.02% (p=0.016 n=5+4)
Atof64Float-12 39.0ns ± 0% 28.7ns ± 0% -26.39% (p=0.002 n=6+6)
Atof64FloatExp-12 64.4ns ± 1% 54.4ns ± 1% -15.65% (p=0.002 n=6+6)
Atof64Big-12 115ns ± 1% 87ns ± 1% -24.45% (p=0.002 n=6+6)
Atof64RandomBits-12 187ns ±14% 156ns ±19% -16.46% (p=0.032 n=6+6)
Atof64RandomFloats-12 126ns ± 0% 105ns ± 1% -16.65% (p=0.000 n=6+5)
Atof32Decimal-12 32.0ns ± 1% 24.0ns ± 1% -24.97% (p=0.002 n=6+6)
Atof32Float-12 37.1ns ± 1% 27.0ns ± 1% -27.42% (p=0.002 n=6+6)
Atof32FloatExp-12 68.4ns ± 1% 54.2ns ± 1% -20.77% (p=0.002 n=6+6)
Atof32Random-12 92.0ns ± 1% 77.4ns ± 0% -15.81% (p=0.000 n=6+5)
ParseInt/Pos/7bit-12 19.4ns ± 1% 13.8ns ±10% -28.94% (p=0.002 n=6+6)
ParseInt/Pos/26bit-12 29.1ns ± 1% 19.8ns ± 2% -31.92% (p=0.002 n=6+6)
ParseInt/Pos/31bit-12 33.1ns ± 0% 22.3ns ± 3% -32.62% (p=0.004 n=5+6)
ParseInt/Pos/56bit-12 47.8ns ± 1% 30.7ns ± 1% -35.78% (p=0.004 n=6+5)
ParseInt/Pos/63bit-12 51.9ns ± 1% 33.4ns ± 2% -35.49% (p=0.002 n=6+6)
ParseInt/Neg/7bit-12 18.5ns ± 4% 13.4ns ± 3% -27.88% (p=0.002 n=6+6)
ParseInt/Neg/26bit-12 28.4ns ± 3% 19.7ns ± 3% -30.38% (p=0.002 n=6+6)
ParseInt/Neg/31bit-12 31.9ns ± 1% 21.8ns ± 2% -31.56% (p=0.002 n=6+6)
ParseInt/Neg/56bit-12 46.2ns ± 0% 30.6ns ± 1% -33.73% (p=0.004 n=5+6)
ParseInt/Neg/63bit-12 50.2ns ± 1% 33.2ns ± 1% -33.96% (p=0.002 n=6+6)
Fixes #33330
Change-Id: I119da66457c2fbaf6e88bb90cf56417a16df8f0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/187957
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Followon from a review comment in https://golang.org/cl/191078
Change-Id: If115b2ae0df5e5cb9babd60802947ddb687d56c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/191219
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Fixes #33750.
Updates #31197.
Change-Id: I26f63cef57e5f0eec85b84554c82f6d47b4f41a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/191078
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
In addition to the example that was added in 203b80ab, mention these
special cases in the doc comment. This change also adjusts the example
to include "+Inf", as it was not otherwise mentioned that the plus
symbol may be present.
Fix #30990
Change-Id: I97d66f4aff6a17a6ccc0ee2e7f32e39ae91ae454
Reviewed-on: https://go-review.googlesource.com/c/go/+/179738
Reviewed-by: Alex Miasoedov <msoedov@gmail.com>
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Float formatting uses a multiprecision fallback path where Grisu3
algorithm fails. This has a bug during the rounding phase: the
difference between the decimal value and the upper bound is examined
byte-by-byte and doesn't properly handle the case where the first
divergence has a difference of 1.
For instance (using an example from #29491), for the number
498484681984085570, roundShortest examines the three decimal values:
lower: 498484681984085536
d: 498484681984085568
upper: 498484681984085600
After examining the 16th digit, we know that rounding d up will fall
within the bounds unless all remaining digits of d are 9 and all
remaining digits of upper are 0:
d: ...855xx
upper: ...856xx
However, the loop forgets that d and upper have already diverged and
then on the next iteration sees that the 17th digit of d is actually
lower than the 17th digit of upper and decides that we still can't round
up:
d: ...8556x
upper: ...8560x
Thus the original value is incorrectly rounded down to
498484681984085560 instead of the closer (and equally short)
498484681984085570.
Thanks to Brian Kessler for diagnosing this bug.
Fix it by remembering when we've seen divergence in previous digits.
This CL also fixes another bug in the same loop: for some inputs, the
decimal value d or the lower bound may have fewer digits than the upper
bound, yet the iteration through the digits starts at i=0 for each of
them. For instance, given the float64 value 1e23, we have
d: 99999999999999991611392
upper: 100000000000000000000000
but the loop starts by comparing '9' to '1' rather than '0' to '1'.
I haven't found any cases where this second bug causes incorrect output
because when the digit comparison fails on the first loop iteration the
upper bound always has more nonzero digits (i.e., the expression
'i+1 < upper.nd' is always true).
Fixes #29491
Change-Id: I58856a7a2e47935ec2f233d9f717ef15c78bb2d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/157697
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rémy Oudompheng <remyoudompheng@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Updates #30990
Change-Id: I968fb13251ab3796328089046a3f0fc5c7eb9df9
Reviewed-on: https://go-review.googlesource.com/c/go/+/174204
Reviewed-by: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
This does *not* update the vendored tables.
A commit updating these tables should follow soon,
Mostly generated running UNICODE_VERSION=11.0.0 in x/text.
Manually updated next.txt file.
Updates golang/go#27945.
Change-Id: I939a01e235aeca898ee9afc99a531e7ad8444e12
Reviewed-on: https://go-review.googlesource.com/c/go/+/154420
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
The byte-at-a-time allocation done quoting strings in appendQuotedWith
grows the output incrementally, which is poor behavior for very large
strings. An easy fix is to make sure the buffer has enough room at
least for an unquoted string.
Add a benchmark with a megabyte of non-ASCII data.
Before: 39 allocations.
After: 7 allocations.
We could do better by doing a lot more work but this seems like a big
result for little effort.
Fixes #31472.
Change-Id: I852139e0a2bd13722c4dd329ded8ae1759abad5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/172677
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
This method was using a handwritten long multiplication of uint64s.
Since implementation of #24813 we can remove it and replace it
by Mul64 from math/bits.
This brings a small speedup for 64-bit platforms.
Benchmarks on Haswell Celeron 2955U.
benchmark old ns/op new ns/op delta
BenchmarkAppendFloat/Decimal-2 127 127 +0.00%
BenchmarkAppendFloat/Float-2 340 317 -6.76%
BenchmarkAppendFloat/Exp-2 258 233 -9.69%
BenchmarkAppendFloat/NegExp-2 256 231 -9.77%
BenchmarkAppendFloat/Big-2 402 375 -6.72%
BenchmarkAppendFloat/BinaryExp-2 113 114 +0.88%
BenchmarkAppendFloat/32Integer-2 125 125 +0.00%
BenchmarkAppendFloat/32ExactFraction-2 274 249 -9.12%
BenchmarkAppendFloat/32Point-2 339 317 -6.49%
BenchmarkAppendFloat/32Exp-2 255 229 -10.20%
BenchmarkAppendFloat/32NegExp-2 254 229 -9.84%
BenchmarkAppendFloat/64Fixed1-2 165 154 -6.67%
BenchmarkAppendFloat/64Fixed2-2 184 176 -4.35%
BenchmarkAppendFloat/64Fixed3-2 168 158 -5.95%
BenchmarkAppendFloat/64Fixed4-2 187 177 -5.35%
BenchmarkAppendFloat/Slowpath64-2 84977 84883 -0.11%
Change-Id: If05784e856289b3b7bf136567882e7ee10234756
Reviewed-on: https://go-review.googlesource.com/c/go/+/157717
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Comparing errors using DeepEqual breaks if frame information
is added as proposed in Issue #29934.
Updates #29934.
Change-Id: I0372883288f974998138f95f6c7c79a60f922a3e
Reviewed-on: https://go-review.googlesource.com/c/162177
Run-TryBot: Marcel van Lohuizen <mpvl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
|
|
This CL modifies ParseInt and ParseUint to recognize
0b and 0o as binary and octal base prefixes when base == 0.
See golang.org/design/19308-number-literals for background.
For #19308.
For #12711.
Change-Id: I8efe067f415aa517bdefbff7e230d3fa1694d530
Reviewed-on: https://go-review.googlesource.com/c/160244
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
|
|
This CL modifies ParseInt, ParseUint, and ParseFloat
to accept digit-separating underscores in their arguments.
For ParseInt and ParseUint, the underscores are only
allowed when base == 0.
See golang.org/design/19308-number-literals for background.
For #28493.
Change-Id: I057ca2539d89314643f591ba8144c3ea7126651c
Reviewed-on: https://go-review.googlesource.com/c/160243
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
This CL updates FormatFloat to format
standard hexadecimal floating-point constants,
using the 'x' and 'X' verbs.
See golang.org/design/19308-number-literals for background.
For #29008.
Change-Id: I540b8f71d492cfdb7c58af533d357a564591f28b
Reviewed-on: https://go-review.googlesource.com/c/160242
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
This CL updates ParseFloat to recognize
standard hexadecimal floating-point constants.
See golang.org/design/19308-number-literals for background.
For #29008.
Change-Id: I45f3b0c36b5d92c0e8a4b35c05443a83d7a6d4b3
Reviewed-on: https://go-review.googlesource.com/c/160241
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Fixes #29461
Change-Id: I5db8bc80e5bd0778dced8471581c67e66853aada
Reviewed-on: https://go-review.googlesource.com/c/155924
Reviewed-by: Rob Pike <r@golang.org>
|
|
Change-Id: I336ad707a85bf0c81b6c2230c90452c0b3b92924
Reviewed-on: https://go-review.googlesource.com/c/155998
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
The compiler can generate better code for shifts bounded to be less than 32
and thereby known to be less than any register width.
See https://golang.org/cl/109776.
Change-Id: I0c4c9f0faafa065fce3c10fd328830deb92f9e38
Reviewed-on: https://go-review.googlesource.com/c/111735
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Change-Id: Ie5b2ef0087dbc7b8191de8c8b4190396631e3c7f
Reviewed-on: https://go-review.googlesource.com/c/137215
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Change-Id: Ic7fce53c6264107c15b127d9c9ca0bec11a888ff
Reviewed-on: https://go-review.googlesource.com/c/138183
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Change-Id: I58ba1f5d5c942d6a345c19df1bca80b63fb5abf5
Reviewed-on: https://go-review.googlesource.com/132777
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
benchmark old ns/op new ns/op delta
BenchmarkUnquoteEasy-4 188 79.5 -57.71%
BenchmarkUnquoteHard-4 653 622 -4.75%
Fixes #23821
Change-Id: I1ebfab1b7f0248fd313de21396e0f8612076aa6d
Reviewed-on: https://go-review.googlesource.com/116755
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Fix the wording in "strconv" and "fmt" to make explicit
that the "g" and "G" formats remove trailing zeroes.
Fixes #25082
Change-Id: I2e2ad0a98d2ea27a3a8a006a0563b366f7a3b71b
Reviewed-on: https://go-review.googlesource.com/127135
Reviewed-by: Rob Pike <r@golang.org>
|
|
Change-Id: I90ba0a6e0c6ccdce16938eed09424308a84fc6fb
GitHub-Last-Rev: 66b6db1a674e6817209a69a7ccd1846d3b0e1900
GitHub-Pull-Request: golang/go#25801
Reviewed-on: https://go-review.googlesource.com/117575
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
The existing implementation panics on malformed input of an empty
string. strconv.Unquote validates the length of the inputs, but calling
UnquoteChar directly with an empty string leads to a panic, so add a
check for length. Also, add a test to go/constant to ensure that
MakeFromLiteral does not panic on malformed input such as
"const x = ''".
Change-Id: I4217e38db48a09a21ec414bbfb3087709da62904
Reviewed-on: https://go-review.googlesource.com/116215
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Each URL was manually verified to ensure it did not serve up incorrect
content.
Change-Id: I4dc846227af95a73ee9a3074d0c379ff0fa955df
Reviewed-on: https://go-review.googlesource.com/115798
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
|
|
Use math/bits.LeadingZeros64 instead of local implementation.
This simplifies code, makes Normalize inlinable and fixes performance regression.
Idea was suggested by Giovanni Bajo in #25298
Performance results below:
Atof64Decimal-6 46.7ns ± 0% 46.7ns ± 0% ~ (all equal)
Atof64Float-6 57.9ns ± 1% 56.9ns ± 0% -1.72% (p=0.000 n=10+9)
Atof64FloatExp-6 163ns ± 0% 123ns ± 0% -24.54% (p=0.002 n=8+10)
Atof64Big-6 222ns ± 1% 185ns ± 1% -16.65% (p=0.000 n=9+10)
Atof64RandomBits-6 155ns ± 2% 154ns ± 3% ~ (p=0.225 n=10+10)
Atof64RandomFloats-6 156ns ± 2% 154ns ± 2% ~ (p=0.124 n=10+9)
Atof32Decimal-6 47.3ns ± 0% 46.7ns ± 0% -1.26% (p=0.000 n=7+9)
Atof32Float-6 51.5ns ± 1% 51.6ns ± 1% ~ (p=0.455 n=10+9)
Atof32FloatExp-6 163ns ± 1% 124ns ± 1% -24.36% (p=0.000 n=10+10)
Atof32Random-6 199ns ± 1% 163ns ± 0% -17.93% (p=0.000 n=10+10)
FormatFloat/Decimal-6 209ns ± 2% 211ns ± 2% ~ (p=0.402 n=10+10)
FormatFloat/Float-6 393ns ± 2% 379ns ± 1% -3.57% (p=0.000 n=10+10)
FormatFloat/Exp-6 333ns ± 2% 321ns ± 1% -3.56% (p=0.000 n=10+9)
FormatFloat/NegExp-6 338ns ± 3% 317ns ± 1% -6.27% (p=0.000 n=10+9)
FormatFloat/Big-6 457ns ± 1% 443ns ± 2% -2.99% (p=0.000 n=9+10)
FormatFloat/BinaryExp-6 230ns ± 2% 232ns ± 2% ~ (p=0.070 n=10+10)
FormatFloat/32Integer-6 209ns ± 2% 211ns ± 1% ~ (p=0.203 n=10+8)
FormatFloat/32ExactFraction-6 330ns ± 2% 319ns ± 1% -3.42% (p=0.000 n=10+10)
FormatFloat/32Point-6 393ns ± 2% 377ns ± 1% -4.15% (p=0.000 n=10+10)
FormatFloat/32Exp-6 331ns ± 2% 318ns ± 2% -4.02% (p=0.000 n=10+10)
FormatFloat/32NegExp-6 327ns ± 2% 315ns ± 2% -3.70% (p=0.000 n=10+10)
FormatFloat/64Fixed1-6 265ns ± 2% 253ns ± 2% -4.38% (p=0.000 n=10+10)
FormatFloat/64Fixed2-6 278ns ± 2% 262ns ± 3% -5.71% (p=0.000 n=10+10)
FormatFloat/64Fixed3-6 271ns ± 2% 260ns ± 2% -4.03% (p=0.000 n=10+10)
FormatFloat/64Fixed4-6 277ns ± 3% 267ns ± 1% -3.55% (p=0.000 n=10+9)
FormatFloat/Slowpath64-6 71.0µs ± 0% 71.0µs ± 0% ~ (p=0.744 n=10+8)
AppendFloat/Decimal-6 100ns ± 1% 100ns ± 0% ~ (p=0.294 n=10+8)
AppendFloat/Float-6 273ns ± 0% 260ns ± 1% -4.87% (p=0.000 n=7+10)
AppendFloat/Exp-6 213ns ± 0% 200ns ± 0% -6.29% (p=0.000 n=8+10)
AppendFloat/NegExp-6 211ns ± 0% 198ns ± 0% -6.16% (p=0.000 n=8+8)
AppendFloat/Big-6 319ns ± 0% 305ns ± 0% -4.31% (p=0.000 n=8+7)
AppendFloat/BinaryExp-6 98.4ns ± 0% 92.9ns ± 0% -5.63% (p=0.000 n=9+8)
AppendFloat/32Integer-6 101ns ± 1% 102ns ± 1% +0.89% (p=0.004 n=10+10)
AppendFloat/32ExactFraction-6 222ns ± 1% 210ns ± 0% -5.28% (p=0.000 n=10+9)
AppendFloat/32Point-6 273ns ± 1% 261ns ± 1% -4.62% (p=0.000 n=10+9)
AppendFloat/32Exp-6 209ns ± 1% 197ns ± 0% -5.56% (p=0.000 n=10+9)
AppendFloat/32NegExp-6 207ns ± 1% 194ns ± 1% -6.18% (p=0.000 n=10+10)
AppendFloat/64Fixed1-6 145ns ± 0% 131ns ± 1% -9.93% (p=0.000 n=9+10)
AppendFloat/64Fixed2-6 160ns ± 0% 146ns ± 0% -8.58% (p=0.000 n=10+8)
AppendFloat/64Fixed3-6 147ns ± 1% 132ns ± 1% -10.25% (p=0.000 n=10+10)
AppendFloat/64Fixed4-6 161ns ± 1% 149ns ± 0% -7.93% (p=0.000 n=10+10)
AppendFloat/Slowpath64-6 70.6µs ± 1% 70.9µs ± 0% +0.37% (p=0.000 n=10+8)
Change-Id: I63bbc40905abd795fbd24743604c790023d11a43
Reviewed-on: https://go-review.googlesource.com/113256
Run-TryBot: Ilya Tocar <ilya.tocar@intel.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Changed the example to convey the intent of the Unquote function
in a more succint way.
Fixes #23693
Change-Id: I49465641d730e70b5af0d47057335af39882bcec
Reviewed-on: https://go-review.googlesource.com/92015
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Use substring of digits for values < 10.
name old time/op new time/op delta
FormatIntSmall/7-4 4.54ns ± 1% 3.70ns ± 1% -18.41% (p=0.000 n=18+17)
FormatIntSmall/42-4 4.54ns ± 1% 4.13ns ± 1% -9.02% (p=0.000 n=16+18)
Change-Id: I0b521b563c13ef88aa2701049fa4a43760e884af
Reviewed-on: https://go-review.googlesource.com/111285
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
The strconv shifts table is 320 bytes (amd64) and is present in
many binaries since integer formatting is very common.
Instead of using a precalculated table with shift amounts
use a bounded bits.TrailingZeros to determine the shift amount
to format numbers in a base that is a power of 2.
amd64:
name old time/op new time/op delta
AppendUint 379ns ± 1% 286ns ± 2% -24.62% (p=0.000 n=20+19)
Change-Id: Ib94d9b033321b41e975868943c7fcd9428c5111e
Reviewed-on: https://go-review.googlesource.com/110478
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
