!standard A.5.1 (00) 98-06-12 AI95-00084/02
!class confirmation 95-08-19
!status WG9 approved 98-06-12
!status ARG Approved 10-0-1 97-11-14
!status work item 95-08-19
!status received 95-08-19
!priority Low
!difficulty Easy
!subject Questions about Generic_Elementary_Functions
!summary 95-08-19
The accuracy requirements for the "**" function in
Generic_Elementary_Functions, in strict mode, are given in G.2.4(9).
The list of differences between the Ada 83 and Ada 95 versions, given in
A.5.1(48.a-48.h), is complete.
!question 95-08-19
What are the accuracy requirements for the "**" function in
Generic_Elementary_Functions, in strict mode?
Is the list of differences between the Ada 83 and Ada 95 versions,
given in A.5.1(48.a-48.h), complete?
!response 95-08-19
(See summary.)
!appendix 95-08-19
!section A.5.1(00)
!subject Accuracy requirements for "**"
!reference RM95-A.5.1
!reference RM95-G.2.4
!from Keith Thompson 95-08-09
!reference as: 95-5252.a Keith Thompson 95-8-9>>
!discussion
The description of Ada.Numerics.Generic_Elementary_Functions in A.5.1
defers the accuracy requirements to the numerics annex, specifically
to G.2.4. This subsection describes the accuracy requirements for most
of the functions in Generic_Elementary_Functions, but says nothing
about the "**" operator. What are the accuracy requirements for
Generic_Elementary_Functions."**" (in strict mode)?
Should the requirements be defined in terms of the identity
X**Y = Exp(Log(X) * Y)
?
****************************************************************
!section A.5.1(00)
!subject Accuracy requirements for "**"
!reference RM95-A.5.1
!reference RM95-G.2.4
!reference 95-5252.a Keith Thompson 95-8-9
!from Keith Thompson 95-08-10
!reference as: 95-5254.a Keith Thompson 95-8-10>>
!discussion
As John Barnes pointed out in e-mail, the accuracy requirements for
Generic_Elementary_Functions."**" are defined in G.2.4(9).
****************************************************************
!section A.5.1(28)
!subject Generic_Elementary_Functions, changes from Ada 83
!reference RM95-A.5.1(28-33)
!reference AARM95-A.5.1(48.a-48.h)
!from Keith Thompson 95-08-14
!reference as: 95-5255.a Keith Thompson 95-8-14>>
!discussion
Paragraphs 48.a through 48.h in the AARM list the changes in the
semantics of Ada.Numerics.Generic_Elementary_Functions relative to
Generic_Elementary_Functions as defined in ISO/IEC DIS 11430 for Ada 83.
One significant difference is not listed. The Ada 83 version specifies
that Argument_Error is raised for arguments outside the domain defined
for a given function. The Ada 95 version retains this for most invalid
arguments, but specifies Constraint_Error for arguments at (or near)
poles of the mathematical functions.
For example, Log(0.0) is expected to raise Argument_Error in the Ada 83
version, but Constraint_Error in the Ada 95 version.
****************************************************************
!section A.5.1(28)
!subject Generic_Elementary_Functions, changes from Ada 83
!reference RM95-A.5.1(28-33)
!reference AARM95-A.5.1(48.a-48.h)
!from Keith Thompson 95-08-14
!reference as: 95-5256.a Keith Thompson 95-8-14>>
!discussion
I forgot to mention something in my last message. My understanding of the
Ada 83 Generic_Elementary_Functions is based on Draft 1.1 of the standard,
dated 3 October 1989. The actual standard may or may not differ.
****************************************************************
!section A.5.1(28)
!subject Generic_Elementary_Functions, changes from Ada 83
!reference RM95-A.5.1(28-33)
!reference AARM95-A.5.1(48.a-48.h)
!reference 95-5255.a Keith Thompson 95-8-14
!reference 95-5256.a Keith Thompson 95-8-14
!from Ken Dritz 95-8-16
!reference as: 95-5258.a Ken Dritz 95-8-16>>
!discussion
Indeed, the Ada 83 standard for Generic_Elementary_Functions did change
somewhere along the way in the standardization process with regard to the
exception to be raised at poles of the mathematical functions. The behavior in
Ada 95 and the behavior described in ISO/IEC IS 11430:1994 are exactly the
same, with regard to Log(0.0) and the other instances of poles. This is
described in clause 13 ("Infinities") of IS 11430.
The reason for the change was to make the behavior "continuous" as a pole is
neared and eventually reached, Furthermore, it facilitates a future Ada
binding to IEEE arithmetic, which might say, for example, that an infinity
shall be delivered, instead of raising Constraint_Error, whenever the language
specifies the latter in overflow situations, divide-by-zero situations, or at
poles of the elementary functions -- assuming that 'Machine_Overflows is False,
of course. (Note the explicit analogy to division by zero in RM95-A.5.1(28).)
************************************************************