!standard A.5.1 (00) 97-11-14 AI95-00084/01 !class confirmation 95-08-19 !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 !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).) ****************************************************************