Accuracy of Attributes of Generic Formal Types 84-10-01 AI-00285/00 1
!standard 04.10 (04) 84-10-01 AI-00285/00
!class study 84-10-01 (provisional classification)
!status received 84-10-01
!topic Accuracy of Attributes of Generic Formal Types
!summary 84-10-01
!question 84-10-01
!recommendation 84-10-01
!wording 84-10-01
!discussion 84-10-01
!appendix 84-10-01
******************************************************************************
!section 04.10 (04) Software Leverage, Inc. 84-01-30 83-00427
!version 1983
!topic Accuracy of Attributes of Generic Formal Types
Since attributes of generic formal types aren't static, the accuracy required
for their evaluation is given by 4.10(4): "The accuracy of the evaluation of a
universal expression of type universal_real is at least as good as that of the
most accurate predefined floating point type supported by the implementation,
apart from universal_real itself."
This makes it very difficult to portably use generic fixed point types. To
illustrate this, assume we wished to completely sidestep issues of accuracy by
converting from the fixed point representation to integer values:
type LONGEST_INTEGER is SYSTEM.MIN_INT..SYSTEM.MAX_INT;
-- Assume that, for any fixed point subtype T,
-- SYSTEM.MIN_INT*T'SMALL <= T'BASE'FIRST
-- and T'BASE'LAST <= SYSTEM.MAX_INT*T'SMALL.
...
function CONVERT(X: T) return LONGEST_INTEGER is
begin
return LONGEST_INTEGER(X/(T'FIRST*INTEGER'(0) + T'SMALL));
-- X/T'SMALL is ambiguous, because T'SMALL must be converted to
-- some fixed point type, and which one isn't determined.
-- X/T'(T'SMALL) isn't ambiguous, but will raise CONSTRAINT_ERROR
-- if the range of T doesn't include T'SMALL.
-- The above is a trick to arrange that only conversions to T'BASE
-- are done; fortunately the model number interval of the left
-- summand is just 0.0.
end CONVERT;
(That such contortions are needed is itself a defect in the language, but this
is left as a topic for future comments.)
Accuracy of Attributes of Generic Formal Types 84-10-01 AI-00285/00 2
This doesn't necessarily accomplish what is desired because (e.g., if T has a
length clause for T'SMALL) T'SMALL may not be a model number of the most
precise floating point type. Therefore the implicit conversion of T'SMALL from
universal_real to T'BASE isn't guaranteed to be accurate (it may even yield
zero if T'SMALL is very small).
This problem was discovered while considering the implementation of
TEXT_IO.FIXED_IO in Ada.
The four attributes which are troublesome are T'SMALL, T'LARGE, T'SAFE_SMALL,
and T'SAFE_LARGE for fixed point types. (There is only a problem for generic
formal types.)
It isn't clear how to minimally fix Ada to remedy this problem. One might
strengthen 4.10(4) to also require exact evaluation for a convertible universal
operand as defined in 4.6(10) if the operand is explicitly or implicitly
converted to a real type (of course, the conversion itself need not be exact).
The next version of Ada ought to resolve this problem.