#fmt uses wrong default precision for float #1375
Comments
|
Not sure that's a bug.null |
|
The default precision is 6. Looks like the trailing zeros are chopped.
|
|
Additionally it would be nice to write this in a f32, f64 agnostic way, or at least move it from float into two copies in f32, f64. Probably this should wait until we have typeclasses in which case this may better be done using a "float number builder" interface which would be passed to "float::to_str" to build a number of the correct type (alternative would be to use bigints when they get implemented) In general, fmt probably should be rewritten for use with typeclasses so I'd say this ticket should remain on hold until they land but then there's a lot to do here. |
This seems to fix issue rust-lang#1876, and some of the superficial parts of issue rust-lang#1375. The #fmt macro and the to_str functions will round, rather than truncate, floats as strings. Other issues remain, and I wrote more code here than intended, but the following should pass now. ``` fn x() { assert "3.1416" == #fmt["%.4f", 3.14159]; assert "3" == #fmt["%.0f", 3.14159]; assert "99" == #fmt["%.0f", 98.5]; assert "7.0000" == #fmt["%.4f", 6.999999999]; assert "3.141590000" == #fmt["%.9f", 3.14159]; } ```
|
@nikomatsakis Did your first comment indicate that you think we should not follow printf here? If so, I am starting to agree. printf's behavior is not really what I would expect. |
This seems to fix issue #1876, and some of the superficial parts of issue #1375. The #fmt macro and the to_str functions will round, rather than truncate, floats as strings. Other issues remain, and I wrote more code here than intended, but the following should pass now. ``` fn x() { assert "3.1416" == #fmt["%.4f", 3.14159]; assert "3" == #fmt["%.0f", 3.14159]; assert "99" == #fmt["%.0f", 98.5]; assert "7.0000" == #fmt["%.4f", 6.999999999]; assert "3.141590000" == #fmt["%.9f", 3.14159]; } ```
|
Still relevant, although it does handle inf and NaN now. |
|
Sad, but not a milestone blocker. |
|
Not sure I agree that we need to exactly imitate C-style format string defaults, especially since we no longer use C-style format strings and also because we've now actually implemented the ability to specify the precision when printing: print!("{:f}", 100.000000004f64); // 100
print!("{:.9f}", 100.000000004f64); // 100.000000004That first one might be a little worrying... but that's probably a different bug anyway. |
|
cc #6220 |
|
I haven't followed this in a long time and don't know what the status is, but now that we're not explicitly copying printf, if our current behavior is sane, then I think that's just fine. |
|
I agree with @brson that we're different enough from C that I don't think that this matters that much. We have different semantics, but that just means that we have our own semantics. We're not losing functionality, you can still specify precisions that you want. For this reason, I'm going to close this. New bugs can be opened for any shortcomings found in our float formatting code. |
fmt("%f", 5.82) yields "5.82". Other printf's yield "5.820000".
The text was updated successfully, but these errors were encountered: