Why do these Printfs output different things?

[Vedran Vekic]

https://play.golang.org/p/-gSNqKZlst

[Axel Wagner]

Because the default-format for floats is %g, not %f: https://play.golang.org/p/KZBtA3ZVN3

(documented in the fmt-godoc: https://godoc.org/fmt -- search for "default format")

On Tue, Jan 24, 2017 at 2:00 PM, Vedran Vekic <vedran...@gmail.com> wrote:

https://play.golang.org/p/-gSNqKZlst

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vedran Vekic]

I see. So why does %g produce a different number than %f?

On Tuesday, January 24, 2017 at 2:03:58 PM UTC+1, Axel Wagner wrote:

Because the default-format for floats is %g, not %f: https://play.golang.org/p/KZBtA3ZVN3

(documented in the fmt-godoc: https://godoc.org/fmt -- search for "default format")

On Tue, Jan 24, 2017 at 2:00 PM, Vedran Vekic <vedran...@gmail.com> wrote:

https://play.golang.org/p/-gSNqKZlst

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Axel Wagner]

Hm, after some more consideration, this isn't really a good explanation; %g, in conflict with the documentation, behaves differently then *both* %e and %f in this case: https://play.golang.org/p/LEVTU7r4wX

[Axel Wagner]

FWIW, this is the code used for formatting:

https://golang.org/src/strconv/ftoa.go#L54

I would claim, this difference (and/or its conflict with the documentation) is a bug.

[Vedran Vekic]

Thanks, issue filed.
https://github.com/golang/go/issues/18772

https://play.golang.org/p/-gSNqKZlst

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[howar...@gmail.com]

Actually, the explanation is a little further down in the docs, specifically, this paragraph:

For floating-point values, width sets the minimum width of the field and precision sets the number of places after the decimal, if appropriate, except that for %g/%G precision sets the total number of significant digits. For example, given 12.345 the format %6.3f prints 12.345 while %.3g prints 12.3. The default precision for %e and %f is 6; for %g it is the smallest number of digits necessary to identify the value uniquely.

// These print the same

fmt.Printf("%f\n", a+b)

fmt.Printf("%.6f\n", a+b)

// and these print the same *for this number! - not for all numbers*

fmt.Printf("%g\n", a+b)

fmt.Printf("%.15f\n", a+b) 

So, again, the primary point is that for %g, the *default* precision is the smallest number of digits necessary to identify the value uniquely, *not* a pre-specified value. For 'a' alone, (i.e. 23.61), 

fmt.Printf("%f\n", a) prints '23.610000'

and

        fmt.Printf("%g\n", a) prints '23.61'

So this is documented behavior, just lacking the precision caveat on the bullet point description of %g.