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

Status
Withdrawn
Publication Date
30-Nov-1994
Withdrawal Date
30-Nov-1994
Current Stage
9599 - Withdrawal of International Standard
Start Date
28-Sep-2000
Completion Date
28-Sep-2000
Ref Project

Buy Standard

Standard
ISO/IEC 11430:1994 - Information technology -- Programming languages -- Generic package of elementary functions for ADA
English language
50 pages
sale 15% off
Preview
sale 15% off
Preview

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
Foreword .............................................
..........................................
Introduction
1 Scope.. ..........................................
.................................
2 Normative reference
..................................
3 Functions provided
......................................
4 Instantiations
5 ....................................
Implernentations
Exceptions ........................................
...............
7 Arguments outside the range of safe numbers
...................... 4
8 Method of specification of functions
.................................. 4
9 Domain definitions
................................... 5
Range definitions
............................... 5
11 Accuracy requirements
Overflow ..........................................
13 Infinities ..........................................
14 Underflow .........................................
15 Specifications of the functions ..........................
............................ 8
15.1 SQRT - Square root
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
---------------------- 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
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
(angle in arbitrary units) ........................
15.12 COT - Trigonometrie cotangent function, natura1 cycle
(angle in radians) ..............................
15.13 COT - Trigonometrie cotangent function, arbitrary cvcle
........................ 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 ...................................
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

---------------------- 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.
---------------------- 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.
---------------------- 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).

---------------------- 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.
---------------------- 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

---------------------- 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.

---------------------- 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.

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.
---------------------- 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.