Re: Errata for IEEE 754-2008 -- precision 1

[Michel Hack <hack@xxxxxxxxxxxxxx>]

Vincent LefÛvre replied:
> I did not consider taking the parity of the exponent into account,
> and I think this is useless in practice.  AFAIK, the only advantage
> of such a choice would be to balance round-up with round-down, as
> you said.  But this is a nice feature only for arithmetic formats.
> For output, this is not needed and would be a bit awkward, IMHO.

Well, 754-2008 does not say anything about binary output -- only
about decimal and hexadecimal.  Does MPFR support binary strings?

I thought that the issue of binary precision 1 did occur in the
arithmetic context of mpfr (as a degenerate case perhaps), which
was dealt with by bounding the precision to 2 from below.

> And if a user really wants to define an arithmetic format in precision 1,
> this is probably because more precision is not needed and in such a case,
> the user probably doesn't care about the balance between round-up and
> round-down (which would occur only in a few cases: the halfway cases).

Right -- and so I don't think it is a problem to leave the corrected
rule in 4.3.1 alone:  when both bounding values of an exact midpoint
have an odd last (and only) digit, round away from zero.

The only reason I brought it up is because Vincent wrote, in his first
post on the subject:
>    ... I suggest that one should consider the exponent of the
>    value that is closer to 0, then consider the significands

He did indeed not mention exponent parity, and I actually misunderstood
what he meant in that sentence (and still do, but never mind).

Since the reason given in 1985 for round-to-nearest-even was to
balance round-up with round-down, I figured that the case of binary
precision 1 needed to be examined in this light too, for completeness.
I don't think we should do anything about it however.


Here is a serious follow-up question: if we take the position that FP
values follow a more-or-less logarithmic distribution, what was the
rationale for "balancing" rounding up or down for linear-exact midpoints?
Given that logarithmically-exact midpoints are close to but below the
linear-exact midpoints, and almost never an exact result (the exceptions
being the square-root operation and perhaps some elementary functions),
why is round-half-up considered unbalanced?  I presume that there are
statistical studies that show an effect, but is that due to assumptions
on the input distribution that are in conflict with actual floating-point
representations?

One possible answer is that those exact midpoints are not really exact --
they only appear to be exact because the input operands were rounded by
earlier operations. They really represent one-ulp intervals centered on
an exact midpoint, and so should randomly be rounded up or down.  Since
for any reasonable precision the logarithmic midpoint is extremely close
to the linear midpoint, any 50% rule may do, and parity is the easiest
one.  A truly exact linear midpoint should be rounded up -- and a true
pedant might insist that the rounding rule take the current Inexact flag
into account (shudder!).

Perhaps Prof. Kahan, or Herman Rubin of Purdue, might chime in.

Michel.
---Sent: 2009-04-01 04:33:38 UTC