From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!mcvax!dik
From: dik@mcvax.uucp (Dik T. Winter)
Newsgroups: comp.lang.ada
Subject: floating point attributes revisited
Message-ID: <318@zuring.mcvax.UUCP>
Date: Sat, 8-Nov-86 17:15:41 EST
Article-I.D.: zuring.318
Posted: Sat Nov  8 17:15:41 1986
Date-Received: Wed, 12-Nov-86 01:06:34 EST
Organization: CWI, Amsterdam
Apparently-To: rnews@mcvax
List-Id: <comp.lang.ada>

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