strconv: inaccurate string to float64 conversion ParseFloat

[g7r]

What version of Go are you using (go version)?

$ go version
version go1.13 linux/amd64

Does this issue reproduce with the latest release?

Not sure. But https://play.golang.org/p/izkaZ-XBog5 reproduces the bug.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

Here's the code: https://play.golang.org/p/izkaZ-XBog5

I'm converting string "1090544144181609348835077142190" to float64 with strconv.ParseFloat("1090544144181609348835077142190", 64) and it returns incorrect value.

What did you expect to see?

It is expected that 1090544144181609419040633126912 should be returned as the closest value representable by float64. The difference between string value and correct float64 value is -70205555984722 (see https://www.wolframalpha.com/input/?i=1090544144181609348835077142190-1090544144181609419040633126912)

What did you see instead?

strconv.ParseFloat(...) actually returns 1090544144181609278303144771584. The difference between string value and returned float64 value is 70531932370606 (see https://www.wolframalpha.com/input/?i=1090544144181609348835077142190-1090544144181609278303144771584)

Additional info

Go compiler correctly converts float64 literals to float64 constants, as you can see in Playground example https://play.golang.org/p/izkaZ-XBog5

[randall77]

I can confirm. It seems like the fast path in strconv/atof.go:627, particularly the AssignDecimal call, is to blame. If I turn the optimize flag off, the bug goes away.
This has been an issue since at least 1.11.
@griesemer

[smasher164]

This behavior has existed since go 1, so it wasn't introduced in any recent release. Digging into extfloat now.

[ALTree]

The ParseFloat doc says:

If s is well-formed and near a valid floating-point number, ParseFloat returns the nearest floating-point number rounded using IEEE754 unbiased rounding.

So it appears that it doesn't unconditionally guarantee to always return the closest IEEE754 number... only if the argument is "near a valid floating-point number" (whatever that means). I believe that your number does not qualify as "near a valid floating-point number".

[smasher164]

Also, the CL associated with #15672 solves this.

[andybons]

This has been like this forever. Removing release-blocker label.

[odeke-em]

We didn’t cover much progress on the related CL unfortunately because folks were swamped. I shall move this to the Unplanned milestone given that the parallel issue is in the Unplanned milestone too.

[lemire]

@nigeltao Given your recent work, is this still an issue?

[JoshStrobl]

This is still an issue as of 1.15.3. I'm still losing precision. I have a float string of -0.63571428571428568 and it's getting truncated to -0.6357142857142857, losing 1428568.