Re: 754-2008 extendable precisions
Michel,
I don't think that Vincent's concerns are the same as
yours.
After all Vincent would have a system in which emax is
the same (& quite large) for all precisions beyond some
point. This is permitted under 754-2008.
Your radix conversion issue is much the same for all of
these precisions. I was unaware it scaled so badly into
higher precisions & exponent ranges.
But 754 is written so that base conversion is required
to round correctly. If efficient methods cannot be
found that might be a problem.
BTW, you caused me to review my response to Vincent &
I see now that I failed to address his concern about
rounding issues of sin & cos for large ranges.
This is indeed a difficult problem. Much more difficult
than base conversion as far as I know.
Still, 754 does not require you to provide correctly
rounded or even faithfully rounded transcendentals. It
merely requires them to correctly round IF YOU CLAIM THEM
TO BE CONFORMING. Non-conforming versions are permitted
& even expected outside the scope of the standard with
no ill effect on an otherwise conforming implementation.
But you DO have to get base conversion right.
I hope that clears thing up just a bit.
Yours,
Dan
> Date: Mon, 23 Mar 2009 13:41:38 -0400
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Subject: 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