[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: printf("%.0f", 0.5) and round-to-even
From: |
Eric Blake |
Subject: |
Re: printf("%.0f", 0.5) and round-to-even |
Date: |
Tue, 30 Sep 2008 20:03:47 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
Eric Blake <ebb9 <at> byu.net> writes:
> > Does glibc do round-to-even here generally (not just in the one special case
> > you mentioned?) If so, the module name should be called fprintf-gnu,
otherwise
> > fprintf-posix-ext.
>
> Both glibc and the gnulib *printf replacement already round to nearest;
> and cygwin 1.5.x failed enough other tests that the gnulib replacement was
> already selected (as evidenced by the fact that on cygwin, gawk and m4 got
> different results, because only m4 uses gnulib's replacements).
In the case of cygwin, this was a true bug, as opposed to an awkward
specification of implementation-definedness. newlib is documented as
attempting round-to-nearest semantics, and does just fine in most scenarios:
printf("%.2f", .125) => 0.12
printf("%.2f", .375) => 0.38
printf("%.0f", 10.5) => 10
printf("%.0f", 11.5) => 12
It was only failing on corner cases where the potential to round affected the
digit immediately before '.', and I've posted a one-liner patch that will
hopefully make it into cygwin 1.7.0:
http://sourceware.org/ml/newlib/2008/msg00499.html
Are there are any other platforms out there where printf("%.1f",.75) rounds
differently then printf("%.2f",.375)? In other words, is it worth testing that
implementation-defined rounding is at least consistent, even if it doesn't
comply with round-to-nearest? (returning .7 and .38 in the above example
points to a bug; a consistent application should return .7 and .37, or .8
and .38).
>
> I suspect %a is also affected, although in newlib's case, %a goes through
> a different code path than %[efg].
newlib's %a was immune.
--
Eric Blake