dik@mcvax.uucp (Dik T. Winter) (11/09/86)
I am confused. On our DG FLOAT'EMAX = FLOAT'SAFE_EMAX, and I hear the
same about Ada/Ed-C on a PC. However, consider the following:
LRM 3.5.7/9 states: The safe numbers have the same number B of mantissa
digits as the model numbers of the type and have an exponent
in the range -E..E where E is implementation-defined and at
least equal to the 4*B of model numbers.
(I think the requirement for the same number of bits is wrong; but that is
not the point.)
LRM 3.5.8 T'SAFE_EMAX Yields the largest exponent value in the binary
canonical form of safe numbers of the base type of T.
(This attribute yields the number E of section 3.5.7).
Although 3.5.7 states that the number E is implementation-defined, from
3.5.8 I read that it should be maximal; hence on a PC SAFE_EMAX should
be 126 (or 127), and EMAX should be 84. Similarly on DG SAFE_EMAX should
be 255.
So what is prevalent, the maximal requirement of 3.5.8 or the implementation-
definedness of 3.5.7?
Consider further:
LRM 4.5.7/7 Whenever the result model interval is undefined, it is highly
desirable that the exception NUMERIC_ERROR be raised if the
impementation cannot produce an actual result that is in the
range of safe numbers.
And it goes on stating there is an attribute MACHINE_OVERFLOWS which is
TRUE if NUMERIC_ERROR is raised in those situations.
Now at least on DG MACHINE_OVERFLOWS is TRUE, but it will not raise
NUMERIC_ERROR for results larger than 2**EMAX and smaller than 2**255;
hence it violates 4.5.7/7. I suspect the same will be true with Ada/Ed
on the PC.
(This also explains my remark on the number of bits; on the PC and on the
DG the mantissa is actually 24 bits, while the model requires 21 bits, so
even with the proper definition of SAFE_EMAX on those machines 4.5.7/7
cannot be satisfied! And this will probably hold for nearly every Ada
implementation produced and to be produced; unless MACHINE_OVERFLOWS is
FALSE in all cases. Correcting this is however much more difficult.)
--
dik t. winter, cwi, amsterdam, nederland
UUCP : {seismo,decvax,philabs,okstate,garfield}!mcvax!dik
or : dik@mcvax.uucp
INTERNET : dik%mcvax.uucp@seismo.css.gov
BITNET/EARN: U00144@HASARA5