strconv: ftoa bug

[rsc]

not sure what happened or if it is true
http://build.golang.org/log/dd288a49040589c8e89101d9872e6fcbb3a2c0b9

--- FAIL: TestAtofRandom (0.01 seconds)
       atof_test.go:221: number 4.87402195346389e+27 badly parsed as 8865794286000692p+39 (expected 8865794286000691p+39)
       atof_test.go:226: tested 10000 random numbers
FAIL

[alberts]

Comment 1:

Could be related to issue #2894?

[remyoudompheng]

Comment 2:

8865794286000691.5 * 1<<39 is 48740219534638900001133035520 so it is a real issue.

[remyoudompheng]

Comment 3:

Weird. I can't actually reproduce.

[rsc]

Comment 4:

Reproduced.  The failure is in ftoa, which is being used to generate the input for atof.
diff -r 001b807ba435 src/pkg/strconv/ftoa_test.go
--- a/src/pkg/strconv/ftoa_test.go  Wed Feb 08 00:22:38 2012 -0500
+++ b/src/pkg/strconv/ftoa_test.go  Wed Feb 08 08:36:30 2012 -0500
@@ -128,6 +128,9 @@
    // issue #2625.
    {383260575764816448, 'f', 0, "383260575764816448"},
    {383260575764816448, 'g', -1, "3.8326057576481645e+17"},
+
+   // issue #2917.
+   {8865794286000691<<39, 'g', -1, "4.8740219534638897e+27"},
 }
 
 func TestFtoa(t *testing.T) {

[remyoudompheng]

Comment 6:

If x = 8865794286000691<<39, the shortest print of x would be
D = 4.87402195346389e+27 because x < D < halfway < nextafter(x).
The halfway is 48740219534638900001... 
func main() {
      s := strconv.FormatFloat(8865794286000691<<39, 'g', -1, 64)
      fmt.Println(s)
      x, _ := strconv.ParseFloat("4.87402195346389e+27", 64)
      fmt.Println(int64(x / (1 << 39)))
}
prints 
4.87402195346389e+27
8865794286000691
as expected. Do you confirm? These atof/ftoa always make me go nuts.

[rsc]

Comment 7:

I think you are right that I confused myself.  Will take another look later.

[rsc]

Comment 8:

I agree: this is working fine.  The existence of the message
>  number 4.87402195346389e+27 badly parsed as 8865794286000692p+39 (expected
8865794286000691p+39)
suggests that the random number generator generated 8865794286000691p+39 and then
FormatFloat formatted it (correctly) as 4.87402195346389e+27, and then ParseFloat parsed
it (incorrectly) to 8865794286000692p+39.  But of course ParseFloat does not do that if
we just run the obvious code.  I will add this test case to the test suite, just in case
it turns up on some other machine again.  And we can chalk it up to a bad builder until
then.

Owner changed to @rsc.

Status changed to Started.

[rsc]

Comment 9:

This issue was closed by revision f7a3683.

Status changed to Fixed.

[rsc]

Comment 10:

Sure enough, this test case failed on the darwin/386 builder
but not anywhere else.  I wonder if the FPU has the wrong rounding
mode or (more likely) is using 80-bit registers by default.
We fix the control word on Linux; maybe we have to do it on Darwin too.
Will look into it using the actual builder machine.

Status changed to Accepted.

[rsc]

Comment 11:

This issue was closed by revision 1707a99.

Status changed to Fixed.