Explicit vs Implicit bounds on range and precision
(Was: Subject: Re: Proposal for a new structure of the standard)
Both Vincent Lefèvre and I have been arguing that entities bounded
only by available resources should be treated as "infinite" sets of
representations, in contrast to representations with bounds derived
from their format.
But then Dan Zuras wrote:
> I would argue against that. The limits of range &
> precision are just as clear as they are with smaller,
> hardware implemented floating-point numbers. It is
> just that in the case of multi-precision intervals
> the user is allowed to choose those limits.
>
> But the limits are there all the same.
Ok, so among format-derived constraints we should include
EXPLICIT bounds on precision and range.
Many systems do have such controls -- but NOT ALL. Some versions of
LISP, and EXEC 2 (a language whose bignum arithmetic I implemented
thirty years ago), do not. The numbers can fill up storage, and if
that is a risk, it is up to the programmer to check the size from
time to time to prevent runwaway storage consumption. By contrast,
Rexx bignum arithmetic (which was implemented partly in reaction to
the one in EXEC 2) does have an explicitly-specifiable limit (with
a default of 9 digits), and the programmer has to raise the limit as
needed, otherwise bignum integers will be turned into floating-point
numbers (with the specified maximum precision, and an exponent with a
large (999999999) but fixed bound (beyond which an overflow exception
would be thrown).
Those old systems may not be candidates for Interval versions, but the
issue should be addressed.
More modern examples might include spigot algorithms for Exact Real
Arithmetic.
If we (as P1788) want to specify "tightest" for all supported formats,
we will have to address this issue, and either rule out unbounded
formats, or require explicit control of the meaning of "tightest".
Even with explicitly bounded formats control of the bounds may be
important in order to control resource consumption, as the needs
may vary from one program section to another.
Michel.
---Sent: 2010-07-14 18:27:55 UTC