Re: Motion 46: finalise interval literals, amendments
Dmitry Nadezhin wrote:
> So implementation doesn't need to limit length of p/q stream.
> It may document accuracy mode of conversion of interval literal.
I like this approach. Given such a bound on precision, it is sufficient
to convert a bounded number of high-order digits, and to just count the
remaining digits in order to determine the magnitude.
We have to remember that standards should be permissive on input and
strict on output. That way anybody can read anybody else's output,
but is not restricted in what can be handled in a specific context.
I think it is important to support exact rationals, if only to offer
a clear, unambiguous, and radix-independent means to denote commonly
encountered values.
So, at a minimum, rational notation should accept integers up to at
least 2**31-1 or perhaps 2**63-1, in decimal notation. It should
also allow any integer specification of the native environment.
And it should (not shall) require support for unbounded integers.
This is pretty much what we did in 754-2008: decimal character strings
denoting floating-point values can have any length, and should be converted
with correct rounding. The rounding rule should be the standard one, but
may be one (also completely unambiguous) that first rounds correctly in
decimal to a precision of at least M digits, followed by a correct binary
rounding of those M digits, where M >= 3+maxRecoverablePrecision for the
highest supported precision (i.e. 20 if binary64 is the most precise format,
or 39 if binary128 is supported).
Issues of buffer overflow or insufficient memory are of no concern to 1788;
any sensible implementation needs to deal with insufficient resources of
various kinds, and in some environments those may be the only restrictions.
Btw, we never discussed rational output! It is of course not needed if we
have other ways to express intervals exactly (e.g. using hex significands
for binary floating-point inf/sup representations). Suppose however that
an implementation uses exact rationals. We have stated already that this
must be parameterized by a precision bound -- but given such a bound one
can use Continued Fraction expansions to convert between floating-point and
rational representations, so perhaps rational output could be interesting!
---Sent: 2013-07-10 19:56:45 UTC