[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: roundTiesToEven in precision 1
On 2009-03-25 21:00:49 -2000, Michel Hack wrote:
Yes it is, because rounding has to be defined for output
precision 1. As 754-2008 stands, the definition of correct
rounding is stated precisely in a way that does not cover the
case of precision 1, since it was given in the context of the
basic formats (clause 4.3.1), even though 4.3 mentions that
it also applies to conversions to character strings. So we
were negligent, and I'm glad Vincent Lef?vre discovered this.
FYI, the precision-1 problem in binary is something that has been
known for quite a long time by us, MPFR developers, and that's the
only reason why the minimal precision in MPFR is 2, and not 1 (we
also thought that 1 was not really useful, and that's why we did
not try to fix the problem). But the printf-like functions had to
be implemented at the end of 2007. It is documented that: "In binary
output, the precision is silently increased up to 2 if it equals 1."
but I've recently discovered that there was the same problem in the
other bases. Binary output is specific to MPFR, but we must support
precision 1 for decimal and hexadecimal output because it is in the
ISO C standard (and at the same time, we should support it in other
bases too, including 2).
We could change the last sentence of the "roudTiesToEven"
paragraph of 4.3.1 to read as follows:
...; if the two nearest floating-point numbers bracketing
an unrepresentable infinitely precise result are equally
near, the one with an even least significant digit (before
taking rounding overflow into account) shall be delivered.
I don't think that "rounding overflow" is clear enough (it can
easily be mixed up with the overflow exception). Perhaps "the
possible exponent change due to the rounding"? Perhaps also say
"in precision 1" in the parenthesis to point out that this is
important only in precision 1 (unless there's a footnote with
an example making that clear).
I leave it to the editors to decide whether this merits a footnote
to point out the rare situations where that parenthetic remark
makes a difference, namely precision 1, possible for toCharacter
conversions of clause 5.12, and perhaps for extendable formats of
clause 3.7.
I think that an example in precision 1 may be useful to explain
the problem more clearly.
On second thought, the notion of "rounding overflow" has not been
defined. So perhaps it would be better to write:
...; if the two nearest floating-point numbers bracketing
an unrepresentable infinitely precise result are equally
near, the one with an even least significant digit shall
be delivered; if that is not possible, the one larger in
magnitude shall be delivered.
(Now the guessing is as to when it is impossible to deliver
the one with an even least significant digit!)
Yes, that's the problem. So, see my proposition above.
Vincent actually mentioned taking the exponent into account:
... I suggest that one should consider the exponent of the
value that is closer to 0, then consider the significands
of both bracketing values, and choose the even one. With
the above example, the exponent of b-1 would be chosen,
i.e. 0; then the significands are respectively b-1 and b,
and the result b should be returned since b is even.
I'm not sure I understand this. First of all, b cannot be a value
of a 1-digit significand.
I considered the significand as an integer, without the constraints
on its range (like what has been said above, probably in a better
way).
And, in any case, would 9.5e-2 be rounded in a different direction
than 9.5e1, because the bracketing values are in the opposite order
relative to exponent zero? (Note that this case is only possible
with DFP.)
I don't understand what you mean. They are not in opposite order.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)