Improper float formatting

[dave]

Improper float formatting

[dave]

Hey @efritz my fix for this bug just got merged into the fmt package! golang/go@7c7cecc - thanks for reporting it!

[efritz]

Sorry for the late reply - was traveling for a conference. Master version does look like it works with the counterexample perfectly. And I'm very impressed at the speed of which #26363 was authored/prioritized.

I appreciate it.

[dave]

Which version of Go are you using?

[dave]

I don't seem to be able to reproduce this in the latest Go v1.10.3... This test still passes:

func TestFmtPackage(t *testing.T) {
	if fmt.Sprintf("%#v", float64(0.0)) != "0" {
		t.Fatal("fmt package no longer shows float bug")
	}
}

Perhaps you can show me an example that's failing for you? I can add a more defensive condition on that if... something like:

if v == float64(int64(v)) && fmt.Sprintf("%#v", 1.0) == "1" {
     ...
}

... that might work... but I'd like to understand the problem better first and be able to reproduce it myself...

[dave]

I believe the bug in the standard library comes from these lines: here and here. The block in format.go is concerned with adding the decimal point and additional decimals when we're in the sharp mode (e.g. using the # modifier). However, it looks like it didn't take into account the fact that when the v verb is used, the sharp flag is set to false and sharpV is set to true (in print.go).

It looks like this commit changed this behaviour in the last year... but I believe it still works like this in master. From the looks of the description in the commit, %#v was intended to be included in the change, but there's no test case for that... Perhaps @martisch would like to comment on what is expected from fmt.Printf("%#v", float64(0.0))?

[dave]

I'll add a Go issue and see what the consensus is.

[dave]

I've added a more defensive check here and released it as v1.0.1: 1e7350a

[efritz]

Thanks for the quick response! Here's a sample program that displays this issue as it's still present in the most recent commit.

This occurs with both go 9 and 10.

package main

import (
	"bytes"
	"fmt"

	"github.com/dave/jennifer/jen"
)

func main() {
	file := jen.NewFile("example")

	file.Var().Id("x").Op("=").Lit(1e+06)

	buffer := &bytes.Buffer{}
	if err := file.Render(buffer); err != nil {
		panic(err.Error())
	}

	fmt.Println(buffer.String())
}

Specifically, this generates the following output, which can't be formatted by go/format.

package example

var x = 1e+06.0

[dave]

Oh wow, thanks for finding this. I had no idea 1e6 would be a float64. Interesting. But also fmt.Printf("%#v\n", 1000000.0) prints 1e+06, so we have to be more careful. I'll do a proper fix that's even more defensive.

[dave]

OK I think this is better... It takes the formatted value and adds .0 only if it doesn't contain . or e. I've pushed the change and tagged it v1.0.2... Give that a go.

[dave]

I'm pretty sure this is fixed now, so I'm going to close it for now. If there'a any more problems, feel free to re-open. Thanks for reporting it!

[dave]

BTW it looks like my suggestion to fix this behaviour in the standard library fmt package was accepted: golang/go#26363 (won't be fixed until go1.12 though)

[kortschak]

I'm curious about why you don't just emit %T(%#v) as you do for the other types.

[dave]

Could do this but I’d prefer the code to be as clean as possible...

[kortschak]

It's generated. The issue is that the change that has gone in to fmt to fix this has broken tests for Gonum mat in a way that is difficult to fix and impossible to fix nicely.

[dave]

Probably best to point this out over in the issue in the golang repo. I wouldn’t expect a change like this to be entirely consequence free.

[dave]

FYI this project already has a work-around that works with both go 1.11 and master: 94ad458

[kortschak]

I have just done that. Thanks.