Thanks, Rob,

As the behavior is as in "C", the behavior is as it should be.  I also
understand that "1" is a closer representation than 0.9999 should the
number be 0.99999, though it's a choice as it diverges from string-type
formats.  Regardless of whether the choice was right or wrong, it is
immaterial in my view, as any change would confuse those familiar with the
current behavior.

I do think the documentation I cited above could be clearer, and without
difficulty.  The documentation of "precision" leads one to believe that
additional digits will be printed, leaving one with the impression those
digits will be as they are in the float, and not rounded.

Thanks for the response.  My view of the issue hasn't really changed given
the responses.  I'm simply considering how this might be easier for others,
as I now understand the behavior.  That's all.

D.



On Mon, Oct 10, 2022 at 4:23 PM Rob Pike <r...@golang.org> wrote:

> This behavior is how floating-point math works, which is not best
> addressed in the documentation for the formatted I/O library. We see may
> comments from people new to floating point who argue that there are bugs in
> Go's arithmetic, but it's invariably a lack of familiarity with
> the—admittedly rather tricky—properties of imprecise arithmetic.
>
> -rob
>
>
> On Tue, Oct 11, 2022 at 9:01 AM Dante Castagnoli <
> dante.castagn...@gmail.com> wrote:
>
>> Thanks!
>>
>> It's not lost, though.  It shows up with the %g form.
>>
>> Knowing about %g, my issue is not extant, but others might hit it.  I'm
>> relatively new to floating point issues, and I saw numbers showing up as
>> integers, and it took a while to sort out what was going on, is all.
>>
>> As the behavior matches "c", I would suggest at minimum making the
>> documentation clearer.
>>
>> https://go.dev/play/p/WBlf3jltimr
>>
>> On Monday, October 10, 2022 at 10:27:00 AM UTC-7 Brian Candler wrote:
>>
>>> Whilst Go handles constants with arbitrary precision AFAIK, precision is
>>> lost once values are assigned to a float64 variable (or passed as an
>>> argument to a function).  There are only 53 bits of precision in the
>>> "mantissa".
>>>
>>> For more info, you might find this helpful:
>>> https://0.30000000000000004.com/
>>>
>>> On Monday, 10 October 2022 at 17:48:56 UTC+1 dante.ca...@gmail.com
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm wondering what folks think about the behavior of %f and precision.
>>>>
>>>> The go fmt documentation states:
>>>> > For floating-point values, width sets the minimum width of the field
>>>> and precision sets the number of places after the decimal,
>>>>
>>>> What I discovered is there is rounding going on in %f as shown below.
>>>>
>>>> https://go.dev/play/p/23AfRtwOqcD
>>>>
>>>> I found this behavior as I'm converting floats to integers, and was
>>>> testing fine regions between digits, and experienced the behavior.   I
>>>> didn't expect it.
>>>>
>>>> I expected the behavior of printing "n" characters of a string.
>>>> However, I note that "c" behaves the same way:
>>>>
>>>> $ cat math.c
>>>> #include<stdio.h>
>>>> int main(int argc, char *argv[]) {
>>>>         printf("%0.3f\n", 0.9999999999);
>>>> }
>>>> $ ./math
>>>> 1.000
>>>> $
>>>>
>>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/4a15ac2c-e30d-4d6e-be8f-251996fb01cen%40googlegroups.com
>> <https://groups.google.com/d/msgid/golang-nuts/4a15ac2c-e30d-4d6e-be8f-251996fb01cen%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEaSmXcfd3MO3eRjHkshi%3DMg3G9RrN9rH1B%3DSoJVth3BDG5-dg%40mail.gmail.com.

Reply via email to