From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 16 Jul 93 16:44:21 GMT
From: eachus@mitre-bedford.arpa  (Robert I. Eachus)
Subject: Re: Ada generics, numerics, and conversions
Message-ID: <EACHUS.93Jul16114421@spectre.mitre.org>
List-Id: <comp.lang.ada>

In article <1993Jul15.223407.3677@software.org> smithd@software.org (Doug Smith
) writes:

  > I could not find a language note, or LRM reference for the
  > following unusual behavior.  Would anyone like to comment
  > on whether this is a compiler problem, or a language
  > feature :-)

    (Code deleted...)

   The results of executing the program are:
    2147483647
   ** MAIN PROGRAM ABANDONED -- EXCEPTION "numeric_error" RAISED

  > Interestingly enough, I could not find a justification for
  > the exception being raised.  Paragraph 4.6(7) says "...The
  > conversion of a real value to an integer type rounds to the
  > nearest integer..."

  > Well, for my machine, 2147483647 is the nearest integer to
  > 1.0/0.0000000000000000001.  However, it seems inconsistent
  > for the generic form to behave differently than the
  > non-generic form.  This can be a sign of an erroneous
  > program, but I don't see it yet.

     First of all, the nearest integer (small i) to
1.0/0.0000000000000000001 is 10000000000000000000, assuming
Float'MANTISSA >= 45.  The nearest value of the type Standard.Integer
is irrelevant.

     Second, 4.6(2) and 4.6(12) are explict about when
CONSTRAINT_ERROR must be raised on a type conversion which is out of
range.  The permissions in 11.6(6) and 11.6(7) do not really apply,
but, especially given the recent ARG discussions on this issue, I
would hesitate to call any action absent a CONSTRAINT_ERROR or others
handler a bug.

     Integer'IMAGE on the other hand is not required to raise an
exception for a value out of range.  In particular 'IMAGE operates on
the base type, so Positive'IMAGE(-3) should print "-3" and
Integer'IMAGE(10000000000000000000) is allowed by 11.6 to print 
" 10000000000000000000".

     NUMERIC_ERROR can be raised almost anyplace you are dealing with
a value outside the range of the base type, so the second result is
acceptable.  It is the first result which should be questioned, since
printing Integer'LAST is never right.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...