Why does strconv.FormatFloat with precision -1 round-trip exactly through ParseFloat?

## The signature and the sentinel ``` func FormatFloat(f float64, fmt byte, prec, bitSize int) string func ParseFloat(s string, bitSize int) (float64, error) ``` `prec` is normally a digit count — places after the decimal point for `'f'` and `'e'`, significant digits for `'g'`. The special value **-1** means something categorically different: *use the smallest number of digits necessary to represent the value uniquely*. ## Why "uniquely" implies a round trip A `float64` is one of a finite set of binary values. Each one owns an interval of real numbers that round to it. "Shortest unique" means: emit the shortest decimal string that falls inside this value's interval and inside no neighbour's. `ParseFloat` is a correctly-rounded parser — it returns the float64 nearest to the decimal string. Feed it a string that lies in exactly one float's interval and it must return that float. So for every finite `f`: ``` back, err := strconv.ParseFloat(strconv.FormatFloat(f, 'g', -1, 64), 64) // err == nil and back == f, bit for bit ``` This is a *guarantee*, not a statistical property, and it is why the shortest form is the right choice for any text that a program will read back: JSON fixtures, CSV exports, log lines a parser consumes, golden files in tests. ## Why a fixed precision cannot promise this A fixed precision is a lossy projection. Two different float64 values can format to the same `%.2f` string, and once they do, no parser can recover which one you had. Going the other way, printing *more* digits than necessary is harmless for correctness but not a guarantee you can reason about by eye: 17 significant digits are always enough for float64, but `%.17f` counts places *after the point*, not significant digits, so it prints garbage precision for large magnitudes and nothing at all for tiny ones. `%.17g` does round-trip, at the cost of ugly output like `0.10000000000000001`. Shortest-unique gives you `0.1` and the same guarantee. ## bitSize is about which neighbours matter The last argument to `FormatFloat` is **not** a request to convert the value. `f` is always a `float64`. `bitSize` says which population the string must be unique within: - `64` — unique among float64 values. - `32` — unique among float32 values, i.e. the caller promises `f` was obtained by converting a `float32`, and the shorter string is fine because float32 neighbours are further apart. So a value that came from a `float32` should be formatted with `bitSize` 32: `float64(float32(0.1))` formatted at 64 gives `0.10000000149011612`, formatted at 32 gives `0.1`. Both are correct for their population; using 64 on a float32-derived value prints noise digits that were never measured. `ParseFloat`'s `bitSize` is symmetric: with 32 it rounds to float32 precision and returns the result widened to `float64`, so `float32(v)` is exact. The round-trip pair for float32 data is `ParseFloat(FormatFloat(f, 'g', -1, 32), 32)`. ## Format byte still matters for the shape Precision -1 works with `'f'`, `'e'` and `'g'` alike — it controls how many digits, not which layout. `'g'` is the usual choice because it also picks a compact layout. `'f'` with -1 keeps plain decimal notation and still round-trips, which is handy when a downstream parser dislikes exponents. There is also `'x'`, hexadecimal floating point (`0x1.999999999999ap-04`), which is exact by construction and independent of decimal rounding entirely — useful in tests and bug reports. ## The values that need special handling The infinities format as `+Inf` and `-Inf` and parse back to the same infinities, so they round-trip fine. Negative zero formats as `-0` and parses back with the sign bit set. **NaN is the exception you must code around**: it formats as `NaN` and parses back to a NaN, but `NaN != NaN`, so a test written as `if back != f { fail }` reports a false failure on every NaN. Compare with `math.IsNaN` on both sides instead. Comparing raw bits with `math.Float64bits` is also not right for NaN, because the parsed NaN need not carry the original payload bits. ## Where this shows up in real code `fmt`'s `%v` on a float is `%g` at default precision, which is the same shortest-unique rule — so `fmt.Sprint(f)` is already round-trippable, and `encoding/json` marshals float64 the same way. The moment you reach for `%.2f` or `%.6f` in a path that another program parses, you have chosen a fixed decimal contract, and it is worth being deliberate about it: fine for a currency column whose scale is defined, wrong for a measurement you intend to reconstruct. ## Cost Shortest-unique formatting is not free — it does real work to find the minimal digit string — but it is a well-optimised path in `strconv` and a rounding error you cannot debug costs far more. If a hot loop formats millions of floats, `strconv.AppendFloat` into a reused byte slice avoids the allocation of a fresh string per value.