754-2008 extendable precisions
I gave up fighting this one as I wanted the standard to reach
completion, and the issues were rather subtle, so that without
a realistic usage model at hand, there was insufficient urgency
to address the issues.
Now that Vincent brought up some of the issues related to large
exponent ranges it may be time to revisit this. The issue is
indeed faithful rounding, or even correct rounding, across the
full range of a given format. The problem is that the exponent
range determines the search space for certain mathematical
properties needed to guarantee rounding properties.
Take the case of radix conversion, which is what I'm most familiar
with. Radix conversion is actually required to round correctly at
least up to 10 bits more than the maximum precision of supported
formats, across the entire exponent range. The precision constraint
is the least severe, as techniques for unbounded precision can be
used. But those techniques depend on bounds on Continued Fraction
partial quotients of ratios of radix powers across the exponent
range -- and there is still no known closed formula to derive any
reasonable provably-adequate bound. Probabilistically the problem
is understood, i.e. the probability of hitting a rounding error is
completely negligible unless one deliberately constructs a difficult
case. The techniques for doing this are in fact the same ones used
to search for bounds.
The discussion above is for fast radix conversion with tightly bounded
scratch space (not much more than is required to hold the argument and
the result). If time and space are not constrained, older algorithms
that don't exploit CF theory will round correctly -- but they get slower
as the actual exponent increases, and scratch storage requirements are
MUCH larger than for the CF-bounded versions.
In the context of interval computations I think a case can be made that
trading off range for precision, as opposed to increasing both so as to
preserve the emax/precision constraint, could be very useful. There is
level-index arithmetic for example, which Arnold and Dan argued about
last December. Now, excursion into a large exponent range to avoid
overflow and underflow does not break the constraint: I'm glad that
the constraint is one-way. The question is how to deal with a required
increase in exponent range when doing subcomputations with much higher
precision: it may be necessary to permit library functions to restrict
themselves to a subset of the range. If we can accept that limitation,
carrying the large exponent capability in the format may indeed be ok.
Michel.
Sent: 2009-03-23 18:33:35 UTC