Printing a float with high precision is incorrect

[abgros]

Zig Version

0.14.0-dev.3047+3a4bb47fe

Steps to Reproduce and Observed Behavior

Run the following:

const std = @import("std");

pub fn main() void {
    const a: f64 = 0.1;
    const b: f64 = 0.2;
    std.debug.print("{d:.52}\n", .{a + b});
}

The result is 0.3000000000000000400000000000000000000000000000000000 which doesn't make any sense. It looks like Zig has clipped everything past the first 4.

Expected Behavior

The correct result is 0.3000000000000000444089209850062616169452667236328125, which is the exact value of the float with bit pattern 0x3fd3333333333334. This result can be confirmed in other programming languages, such as JavaScript and Python.

(0.1 + 0.2).toFixed(52)

print("{:.52f}".format(0.1 + 0.2))

[fardragon]

The result is 0.3000000000000000400000000000000000000000000000000000 which doesn't make any sense. It looks like Zig has clipped everything past the first 4.

0.30000000000000004 is the shortest decimal representation for 0.3000000000000000444089209850062616169452667236328125, looks like it just calculates that and then appends enough 0s to match the requested precision. It's of course not what one would expect but it makes some ™ sense

[tiehuis]

I mentioned this briefly in #19484. The current behavior is as noted in that we 0-pad beyond the shorted representation.

We use ryu for the algorithm. This has a fixed-precision mode implemented that works as you would expect but only for f64, it also requires a lot of tables (~104k) to implement. I would have concerns about the 128-bit implementation as I suspect this would be impractical and would need to use a better encoding to facilitate this without unnecessary binary bloat.

[tiehuis]

Note possible other methods (different algorithms) which can facilitate this with much smaller table sizes: #1299 (comment)

[abgros]

Also previously caused some confusion on Reddit: https://www.reddit.com/r/Zig/comments/1evk53p/weird_math_floating_point_error/