Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

math/big: ParseFloat loses precision with trailing zeros after decimal #9939

Closed
josharian opened this issue Feb 20, 2015 · 1 comment
Closed
Milestone

Comments

@josharian
Copy link
Contributor

package main

import (
    "fmt"
    "math/big"
)

func main() {
    threes := [...]string{"3", "03", "3.", "3.0", "3.00", "3.000"}

    for _, three := range threes {
        f, b, err := big.ParseFloat(three, 10, 350, big.ToNearestEven)
        fmt.Println(three, f, b, err)
        fmt.Println(f.Format('b', 350))
    }
}

yields

3 3 10 EOF
0p-348
03 3 10 EOF
0p-348
3. 3 10 EOF
0p-348
3.0 3 10 EOF
1720123961992553633708115671476565205597423741876210842803191629540192157066363606052513914832594264915968p-348
3.00 3 10 EOF
1720123961992553633708115671476565205597423741876210842803191629540192157066363606052513914832594264915968p-348
3.000 3 10 EOF
1720123961992553633708115671476565205597423741876210842803191629540192157066363606052513914832594264915968p-348

Something similar is true of gc's constants; see my comments in #7740.

@josharian josharian added this to the Go1.5 milestone Feb 20, 2015
@griesemer
Copy link
Contributor

This issue is unrelated to #7740.

This is simply a bug that crept in after a relaxation of the internal invariant that the mantissa is always at least as long as the precision. The conversion routine was making the assumption that this was still the case.

https://go-review.googlesource.com/5640

@golang golang locked and limited conversation to collaborators Jun 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants