ISO/IEC 11430:1994
(Main)Information technology — Programming languages — Generic package of elementary functions for ADA
Information technology — Programming languages — Generic package of elementary functions for ADA
Technologies de l'information — Langages de programmation — Ensemble générique de fonctions élémentaires pour l'ADA
General Information
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 11430
First edition
1994-12-01
Information technology - Programming
languages - Generic package of
elementary functions for Ada
Technologies de I ’informa tion - Langages de programmation -
Ensemble g&Grique de fonctions &Zmen taires pour I ’Ada
Reference number
ISO/1 EC 11430: 1994(E)
---------------------- Page: 1 ----------------------
ISO/IEC 11430:1994(E)
Page
Contents
V
Foreword .
vi
..........................................
Introduction
1
1 Scope. .
1
.................................
2 Normative reference
1
..................................
3 Functions provided
2
......................................
4 Instantiations
2
5 .
Implernentations
3
6
Exceptions .
4
...............
7 Arguments outside the range of safe numbers
...................... 4
8 Method of specification of functions
.................................. 4
9 Domain definitions
................................... 5
10
Range definitions
............................... 5
11 Accuracy requirements
6
12
Overflow .
6
13 Infinities .
7
14 Underflow .
7
15 Specifications of the functions .
............................ 8
15.1 SQRT - Square root
8
15.2 LOG - Natura1 logarithm .
.............. 9
15.3 LOG - Logarithm to an arbitrary hase
@ ISO/IEC 1994
no part of this publication may be
All rights reserved. Unless otherwise specified,
reproduced or utilized in any ferm or by any means, electronie or mechanical, including
photocopying and microfilm, without Permission in writing from the publisher.
ISO/IEC Copyright Office l Gase postale 56 l CH-1211 Geneve 20 l Switzerland
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
@ ISO/IEC ISO/IEC 11430:1994(E)
...................... 10
15.4 EXP - Exponential function
lI** 11
.................. 10
15.5 - Exponentiation Operator
15.6 SIN - Trigonometrie sine function, natura1 cycle (angle
11
in radians) .
Trigonometrie sine function, arbitrary cycle (angle
15.7 SIN-
............................. 12
in arbitrary units)
15.8 cos - Trigonometrie cosine function, natural cycle (angle
in radians) . 12
15.9 cos - Trigonometrie cosine function, arbitrary cycle (an-
gle in arbitrary units) . 13
15.10 TAN - Trigonometrie tangent function, natura1 cycle (an-
gle in radians) . 14
15.11 TAN - Trigonometrie tangent function, arbitrary cycle
14
(angle in arbitrary units) .
15.12 COT - Trigonometrie cotangent function, natura1 cycle
15
(angle in radians) .
15.13 COT - Trigonometrie cotangent function, arbitrary cvcle
u
........................ 16
(angle in arbitrary units)
- Inverse trigonometric sine function, natura1 CY-
15.14 ARCSIN
cle (angle in radians) . 16
15.15 ARCSIN - Inverse trigonometric sine function, arbitrary
cycle (angle in arbitrary units) . 17
15.16 ARCCOS - Inverse trigonometric cosine function, natura1
cycle (angle in radians) . 18
15.17 ARCCOS - Inverse trigonometric cosine function, arbitrary
cycle (angle in arbitrary units) . 19
15.18 ARCTAN - Inverse trigonometric tangent function, natura1
.........................
cycle (angle in radians) 19
15.19 ARCTAN - Inverse trigonometric tangent function, arbi-
trary cycle (angle in arbitrary units) . 21
15.20 ARCCOT - Inverse trigonometric cotangent function, nat-
ural cycle (angle in radians) . 22
15.21 ARCCOT - Inverse trigonometric cotangent function, ar-
bitrary cycle (angle in arbitrary units) . 24
15.22 SINH - Hyperbolic sine funct)ion . 25
15.23 COSH - Hyperbolic cosine function . 26
15.24 TANH - Hyperbolic tangent function . 27
15.25 COTH - Hyperbolic cotangent function . 27
15.26 ARCSINH - Inverse hyperbolic sine function . 28
ARCCOSH - Inverse hyperbolic cosine function . 28
15.27
15.28 ARCTANH - Inverse hyperbolic tangent function . 29
15.29 ARCCOTH - Inverse hyperbolic cotangent function . 30
Annexes
A Adaspecification for GENERIC-ELEMENTARY-FUNCTIONS . 31
.....
B Adaspecificationfor ELEMENTARY-FUNCTIONS-EXCEPTIONS 32
C Rationale . 33
c.1 History . 33
c.2 Relationship to Ada 9X . 34
c.3 Use of generics . 34
c.4 Range constraints in the generic actual type . 34
c.5 Functions included . 37
C.6 Parameter names of the “**l’ Operator . 37
C.7 Units of angular measure 38
........................
---------------------- Page: 3 ----------------------
ISO/IEC 11430:1994(E) @ ISO/IEC
C.8
Optionality of the CYCLE and BASE Parameters . 38
c.9
Purposes and determination of the accuracy requirements 39
c.10
Role of the range definitions . 41
c.11 Treatment of exceptional conditions
................ 41
c.12 Underflow .
43
c.13 o.o**o.o 44
....................................
c.14 Accommodation of portable implernentations of GENER-
IC,ELEMENTARY-FUNCTIONS . 44
c.15 Role of “signed Zeros” and infinities . 45
C.16 Mathematical constants . 48
D Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
iv
---------------------- Page: 4 ----------------------
@ ISO/IEC ISO/IEC 11430:1994(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the In-
ternational Electrotechnical Commission) form the specialized System for
worldwide standardization. National bodies that are members of ISO or IEC
participat)e in the development of International Standards through technical
committees established by the respective organization to deal with particular
fields of technical activity. ISO and IEC technical committees collaborate
in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the
work.
In the field of information technology, ISO and IEC have established a
joint technical committee, ISO/IEC JTC 1. Draft International Standards
adopted by the joint technical committee are circulated to national bodies
for voting. Publication as an International Standard requires approval by at
least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 11430 was prepared by Joint Technical
CommitlteeISO/IEC JTC 1, 1 n f ormation technology, Subcommittee 22, PTO-
gramming languages, their environments and System Software interfaces.
Annexes A and B form an integral part of this International Standard. An-
nexes C and D are for information only.
V
---------------------- Page: 5 ----------------------
@ ISO/IEC
ISO/IEC 11430:1994(E)
Introduction
The generic package described here is intended to provide the basic math-
ematical routines from which portable, reusable applications tan be built.
This International Standard serves a broad class of applications with reason-
able ease of use, while demanding implernentations that are of high quality,
capable of Validation and also practical given the state of the art.
The two specifications included in this International Standard are presented
as compilable Ada specifications in annexes A and B with explanatory text
in numbered clauses in the main body of text. The explanatory text is
normative, with the exception of the following items:
- in clause 15, examples of common usage of the elementary functions
un er the heading Usage associated with each function); and
( d
notes.
The word “may” as used in this International Standard consistently means
“is allowed to” (or “arc allowed to ”). It is used only to express Permission,
as in the commonly occurring Phrase “an implementation may ”; other words
(such as “tan,” “ could” or “might ”) are used to express ability, possibility,
capacity or consequentiality.
vi
---------------------- Page: 6 ----------------------
ISO/IEC 11430:1994(E)
INTERNATIONAL STANDARD 0 ISO/IEC
Information technology -
Programming languages -
Generic package of elementary functions for Ada
1 Scope
This International Standard defines the specification of a generic package of elementary functions called GENERIC-EL-
EMENTARY,FUNCTIONS and the specification of a package of related exceptions called ELEMENTARY-FUNCTIONS,EXCEP-
TIONS. It does not define the body of the former. No body is required for the latter.
This International Standard specifies certain elementary mathematical functions which are needed to support general
floating-Point usage and to support generic packages for complex arithmetic and complex functions. The functions
were Chosen because of their widespread Utility in various application areas.
This International Standard is applicable to programming environments conforming to ISO 8652:1987.
2 Normative reference
The following Standard contains provisions which, through reference in this text, constitute provisions of this Interna-
tional Standard. At the time of publication, the edition indicated was valid. All Standards are subject to revision, and
Parties to agreements based on this International Standard are encouraged to investigate the possibility of applying
the most recent edition of the Standard indicated below. Members of IEC and ISO maintain registers of currently
valid International Standards.
ISO 8652: 1987, Programming languages - Ada (Endorsement of ANSI Standard 1815A-1983)
3 Functions provided
The following twenty mathematical functions are provided:
II**II
SQRT LOG EXP
SIN cos TAN COT
ARCSIN ARCCOS ARCTAN ARCCOT
SINH COSH TANH COTH
ARCSINH ARCCOSH ARCTANH ARCCOTH
These are the Square root (SQRT), logarithm (LOG) and exponential (EXP) functions and the exponentiation Operator
(**); the trigonometric functions for sine (SIN), cosine (COS), tangent (TAN) and cotgangent (COT) and their inverses
(ARCSIN, ARCCOS, ARCTAN and ARCCOT); and the hyperbolic functions for sine (SINH), cosine (COSH), tangent (TANH)
and cotangent (COTH) togetherwith theirinverses (ARCSINH, ARCCOSH, ARCTANH and ARCCOTH).
1
---------------------- Page: 7 ----------------------
@ ISO/IEC
ISO/IEC 11430:1994(E)
Inst ant iat ions
This International Standard describes a generic package, GENERIC-ELEMENTARY,FUNCTIONS, which the user must in-
stantiate to obtain a package. It has one generic formal Parameter, which is a generic formal type named FLOAT,TYPE.
At instantiation, the user must specify a floating-Point subt,ype as the generic actual paramet,er to be associated with
This type is used as the Parameter and result t!ype
FLOAT,TYPE; it is referred to below as the “generic actual type.”
of the functions contained in the generic package.
Depending on the implementation, the user may or may not be allowed to specify a generic actual type having a range
constraint (see clause 5). If allowed, such a range constraint will have the usual effect of causing CONSTRAINT,ERROR
to be raised when an argument outside the user ’s range is passed in a cal1 to one of the functions, or when one of
the functions attempts to return a value outside the user ’s range. Allowing the generic actual type tlo have a range
constraint also has some implications for implernentors.
In addition to the body of the generic package itself, implernentors may provide (non-generic) library packages that tan
be used just like instantiations of the generic package for the predefined floating-Point types. The name of a package
serving as a replacement for an instantiation of GENERIC-ELEMENTARY,FUNCTIONS for the predefined type FLOAT should
be ELEMENTARY-FUNCTIONS; for LONG,FLOAT and SHORT-FLOAT, the names should be LONG-ELEMENTARY-FUNCTIONS
When such a package is used in an applicatJion in lieu of an
and SHORT-ELEMENTARY-FUNCTIONS, respectively; etc.
instantiation of GENERIC,ELEMENTARY,FUNCTIONS, it shall have the semantics implied by this International St ’andard
for an instantiation of the generic package.
5 Implernentations
Portable implernentations of the body of GENERIC,ELEMENTARY,FUNCTIONS are strongly encouraged. However, imple-
mentations are not required to be portable. In particular, an implementat,ion of this Internat,ional Standard in Ada may
use pragma INTERFACE or other pragmas, unchecked conversion, machine-code insertions or other machine-dependent
techniques as desired.
An implementation may limit the precision it supports (by st,ating an assumed maximum value for SYSTEM .MAX-DIG-
ITS), since portable implernentations would not, in general, be possible otherwise. An implementation is also allowed
to make other reasonable assumptions about the environment in which it is to he used, butl only when necessary in
Order to match algorithms to hardware characteristics in an economical manner. All such limits and assumptions
shall be clearly documented. By convention, an implementation of GENERIC-ELEMENTARY,FUNCTIONS is said not to
conform to this International Standard in any environment in which its limits or assumptions are not satisfied, and
the Standard does not define its behavior in that environment. In effect, this convention delimits the port!ability of
implernentations.
An implementation may impose a restriction that the generic actual type shall not have a range constraint that reduces
If it does impose this restriction, then t!he restriction shall be documented, and the
the range of allowable values.
effects of violating the restriction shall be one of the following:
- Compilation of a unit containing an instantiation of GENERIC-ELEMENTARY,FUNCTIONS is rejected.
- CONSTRAINT-ERROR or PROGRAM-ERROR is raised during the elaboration of an instantiation of GENERIC-ELEMEN-
TARY,FUNCTIONS.
Conversely, if an implementation does not impose the rest,riction, then such a range constraint shall not be allowed,
when included with the user ’s actual type, to interfere wit.11 the internal computatlions of tlhe functions; that is, if the
argument and result are within the range of the type, then the implement,ation shall return tlhe result and shall not
raise an exception (such as CONSTRAINT,ERROR).
An implementation shall function properly in a tasking environment. Apart! from the obvious restriction t ’hat an
implementation of GENERIC-ELEMENTARY,FUNCTIONS shall avoid declaring variables that are global to the functions,
no special constraints are imposed on implernentations. Nothing in this Mernational St#andard requires the use of
such global variables.
2
---------------------- Page: 8 ----------------------
@ ISO/IEC ISO/IEC 11430:1994(E)
Some hardware and their accompanying .4da implernentations have the capability of representing and discriminating
between positively and negatively signed Zeros as a means (for example) of preserving the sign of an infinitesimal
quantity that has underflowed to Zero. Implernentations of GENERIC,ELEMENTARY-FUNCTIONS may exploit that capa-
bility, when available, so as to exhibit continuity in the results of ARCTAN and ARCCOT as certain limits are approached.
At the same time, implernentations in which that capability is unavailable are also allowed. Because a definition of
what comprises the capability of representing and distinguishing signed Zeros is beyond the scope of this International
Standard, implernentations are allowed the freedom not to exploit the capability, even when it is available. This
International Standard does not specify the sign that an implementation exploiting signed Zeros shall give to a zero
result; it does, however, specify that an implementation exploiting signed Zeros shall yield results for ARCTAN and
ARCCOT that depend on the sign of a zero argument. An implementation shall exercise its choice consistently, either
exploiting signed-zero behavior everywhere or nowhere in this package. In addition, an implementation shall document
its behavior with respect to signed Zeros.
6 Exceptions
One exception, ARGUMENT,ERROR, is declared in GENERIC-ELEMENTARY,FUNCTIONS. This exception is raised by a
function in the generic package only when the argument(s) of the function violate one or more of the conditions given
in the function ’s domain definition (see clause 9).
NOTE - These conditions are related only to the mathematical definition of the function and are therefore implementation
independent.
The ARGUMENT,ERROR exception is declared as a renaming of the exception of the same name declared in the EL-
Thus, this exception distinguishes neither between different kinds of
EMENTARY,FUNCTIONS-EXCEPTIONS package.
argument errors, nor between different functions, nor between different instantiations of GENERIC-ELEMENTARY-FUNC-
TIONS. Besides ARGUMENT,ERROR, the only exceptions allowed during a cal1 to a function in GENERIC-ELEMENTA-
RY,FUNCTIONS are predefined exceptions, as follows.
- Virtually any predefined exception is possible during the evaluation of an argument of a function in GENERIC-EL-
EMENTARY,FUNCTIONS. For example, NUMERIC,ERROR, CONSTRAINT,ERROR or even PROGRAM,ERROR could be raised
if an argument has an undefined value; and, as stated in clause 4, if the implementation allows range constraints
in the generic actual type, then CONSTRAINT,ERROR will be raised when the value of an argument lies outside the
range of the user ’s generic actual type. Additionally, STORAGE,ERROR could he raised, e.g. if insufficient storage is
available to perform the call. All these exceptions are raised before the body of the function is entered and therefore
have no bearing on implernentations of GENERIC,ELEMENTARY,FUNCTIONS.
- Also as stated in clause 4, if the implementation allows range constraints in the generic actual type, then
CONSTRAINT-ERROR will be raised when a functionin GENERIC,ELEMENTARY-FUNCTIONS attemptsto return a value
outside the range of the user ’s generic actual type. The exception raised for this reason shall be propagated to the
caller of the function.
- Whenever the arguments of a function are such that a result permitted by the accuracy requirements would
exceed FLOAT,TYPE' SAFE,LARGE in absolute value, as formalized below in clause 12, an implementation may raise
(and shall then propagate to the caller) the exception specified by Ada for signaling Overflow.
- Whenever the arguments of a function are such that the corresponding mathematical function is infinite (see
clause 13), an implementation shall raise and propagate to the caller the exception specified by Ada for signaling
division by Zero.
- Once execution of the body of a function has begun, an implementation may propagate STORAGE,ERROR to
the caller of the function, but only to Signal the exhaustion of storage. Similarly, once execution of the body of a
function has begun, an implementation may propagate PROGRAM,ERROR to the caller of the function, but only to
signalerrors made bythe user of GENERIC,ELEMENTARY-FUNCTIONS.
No exception is allowed during a cal1 to a function in GENERIC,ELEMENTARY-FUNCTIONS except those permitted by
the foregoing rules. In particular, for arguments for which all results satisfying the accuracy requirements remain
3
---------------------- Page: 9 ----------------------
@ ISO/IEC
ISO/IEC 11430:1994(E)
less than or equal to FLOAT,TYPE’ SAFE,LARGE in absolute value, a function shall handle locally an Overflow occurring
during the computation of an intermediate result, if such an Overflow is possible, and shall not propagate an exception
signaling that Overflow to the caller of the function.
The only exceptions allowed during an instantiation of GENERIC-ELEMENTARY,FUNCTIONS, including the execution
are CONSTRAINT,ERROR, PROGRAM,ERROR and
of the optional sequence of Statements in the body of the instance,
The raising of CONSTRAINT,ERROR during instantiation
STORAGE,ERROR, and then only for the reasons given below.
is only allowed when the implementation imposes the restriction that the generic actual type shall not have a range
constraint, and the user violates that restriction (it tan, in fact, be an inescapable consequence of the Violation). The
raising of PROGRAM-ERROR during instantiation is only allowed for the purpose of signaling errors made by the user-for
example, Violation of this Same restriction or of other limitations of the implementation. The raising of STORAGE,ERROR
during instantiation is only allowed for the purpose of signaling the exhaustion of storage.
NOTE - In the Ada Reference Manual, the exception specified for signaling Overflow or division by zero is NUMERIC,ERROR,
but AI-00387 replaces that by CONSTRAINT,ERROR.
7 Arguments outside the range of safe numbers
ISO 8652:1987 fails to define the result safe interval of any basic or predefined Operation of a real subtype when
the absolute value of one of its operands exceeds the largest safe number of the Operand subtype. (The failure to
define a result in this case occurs because no safe interval is defined for the Operand in question.) In Order to avoid
imposing requirements that would, consequently, be more stringent than those of Ada itself, this International Standard
likewise does not define the result of a contained function when the absolute value of one of its arguments exceeds
FLOAT,TYPE ’ SAFE,LARGE. All of the accuracy requirements and other provisions of the following clauses are understood
to be implicitly qualified by the assumption that function arguments are less than or equal to FLOAT,TYPE ’ SAFE-LARGE
in absolute value.
8 Method of specification of functions
Some of the functions have two overloaded forms. For each form of a function covered by this International Standard,
the function is specified by its Parameter and result type Profile, the domain of its argument(s), its range and the
The meaning of, and conventions applicable to, the domain, range and
accuracy required of its implementation.
accuracy specifications are described below.
9 Domain definitions
The specification of each function covered by this International Standard includes, under the heading Domain, a
characterization of the argument values for which the function is mathematically defined. It is expressed by inequalities
or other conditions which the arguments must satisfy to be valid. The Phrase “mathematically unbounded” in a domain
definition indicates that all representable values of the argument are valid. Whenever the arguments fail to satisfy all
the conditions, the implementation shall raise ARGUMENT-ERROR. It shall not raise that exception if all the conditions
are satisfied.
Inability to deliver a result for valid arguments (because the result overflows, for example) shall not raise
ARGUMENT,ERROR, but shall be treated in the Same way that Ada defines for its predefined floating-Point operations
(see clause 12).
NOTE - Unbounded portions of the domains of the functions EXP, “**” SINH and COSH, which are “expansion” functions with
unbounded or semi-unbounded mathematical domains, are unexploitable because the corresponding function values (satisfying
the accuracy requirements) cannot be represented. Their “usable domains,” i.e. the portions of the mathematical domains given
in their domain definitions that are exploitable in the sense that they produce representable results, are given by the notes
accompanying their specifications. Because of permitted variations in implernentations, these usable domains tan only be stated
approximately. In a similar manner, functions such as TAN and COT with periodic “poles” in their domains tan (depending on
the implementation) have small unusable portions of their domains in the vicinities of the poles. Also, range constraints in the
user ’s generic actual type tan, by narrowing a function ’s range, make further portions of the function ’s domain unusable.
4
---------------------- Page: 10 ----------------------
ISO/IEC 11430:1994(E)
@ ISO/IEC
10 Range definitions
The usual mathematical meaning of the “range” of a function is the set of values into which the function maps
the values in its domain. Some of the functions covered by this International Standard (for example, ARCSIN) are
mathematically multivalued, in the sense that a given argument value tan be mapped by the function into many
different result values. By means of range restrictions, this International Standard imposes a uniqueness requirement
011 the results of multivalued functions, thereby reducing them to Single-valued functions.
Same of the functions covered by this International Standard (for example, EXP) have asymptotic behavior for extremely
positive or negative arguments. Although there is no finite argument for which such a function tan mathematically
yield its asymptotic limit, that limit is always included in its range here, and it is an allowed result of the implemented
function, in recognition of the fact that the limit value itself could be closer to the mathematical result than any other
representable value.
The range of each function is shown under the heading Runge in the specifications. Range definitions take the form of
inequalities limiting the function value. An implementation shall not exceed a limit of the range when that limit is a
safe number of FLOAT,TYPE (like 0.0, 1.0 or CYCLE/4.0 for certain values of CYCLE). On the other hand, when a range
limit is not a safe number of FLOAT,TYPE (like 7r or CYCLE/4.0 for certain other values of CYCLE), an implementation
may exceed the range limit, but may not exceed the safe number of FLOAT,TYPE next beyond the range limit in
the direction away from the interior of the range; this is in general the best that tan be expected from a portable
implementation. Effectively, therefore, range definitions have the added effect of imposing accuracy requirements on
implementations above and beyond those presented under the heading Accziracy in the specifications (see clause 11).
hat the range of values of the function is not
The Phrase “mathematically unbounded” in a range definition indicates t
bounded by is not mathematically multivalued.
its mathematical definition. It also implies that the function
NOTE - Unbounded portions of the ranges of the functions SQRT, LOG, ARCSINH and ARCCOSH, which are “contraction” functions
with unbounded or semi-unbounded mathematical ranges, are unreachable because the corresponding arguments cannot be
represented. Their “reachable ranges,” i.e. the portions of the mathematical ranges given in their range definitions that are
reachable through appropriate arguments, are given by the notes accompanying their specifications. Because of permitted
variations in implernentations, these reachable ranges tan only be stated approximately. Also, range constraints in the user ’s
generic actual type tan, by narrowing a function ’s domain, make further portions of the function ’s range unreachable.
11
Accuracy requirements
Because they are implemented on digital Computers with only finite precision, t,he functions provided in this generic
package tan, at best, only approximate the corresponding mathematically defined functions.
The accuracy requirements contained in this International Standard define the latitude that implernentations are
allowed in approximating the intended precise mathematical result with float,ing-Point computatlions. Accuracy re-
quirements of two kinds are stated under the heading Accuracy in the specifications. Addit,ionally, range definitions
stated under the heading Runge impose requirements that constrain tlhe values ilnl~lelllentatiolls may yield, so the
range definitions are another Source of accuracy requirements (in that contest, the precise meaning of a range limit
that is not a safe number of FLOAT-TYPE is discussed in clause 10). Every result) yielded by a function is subject to
all of the function ’s applicable accuracy requirements, except in the one case described in clause 14. In that case,
the result will satisfy a small absolute error requirement in lieu of tlhe other accuracy requirements defined for the
function.
The first kind of accuracy requirement used under the heading Accuracy in the specifications is a bound on the relative
error in the computed value of the function, which shall hold (except as provided by the rules in clauses 12 and 14) for
all arguments satisfying the conditions in the domain definition, providing the mathematical result is nonzero. For a
given function f, the relative error Te(X) in a computed result F(X) at the argument X is defined in the usual way,
FF) - f(X)
Te(X) =
f(X)
providing the mathematical result f(X) is finite and nonzero. (The relative error is not defined when the mathematical
result is infinite or Zero.) For each function, the bound on the relative error is identified under the heading Accuracy
as its maximum relative error.
5
---------------------- Page: 11 ----------------------
@ ISO/IEC
ISO/IEC 11430:1994(E)
The second kind of accuracy requirement used under the heading Accumcy in the specifications is a Stipulation, in
the form of an equality, that the implementation sh
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.