IEEE Std 754-2008
IEEE Standard for Floating-Point Arithmetic
1.4 Exclusions
1.4.0
This standard does not specify:
― Formats of integers.
― Interpretation of the sign and significand fields of NaNs.
1.5 Programming environment considerations
1.5.0
This standard specifies floating-point arithmetic in two radices, 2 and 10. A programming environment may
conform to this standard in one radix or in both.
This standard does not define all aspects of a conforming programming environment. Such behavior should
be defined by a programming language definition supporting this standard, if available, and otherwise by a
particular implementation. Some programming language specifications might permit some behaviors to be
defined by the implementation.
Language-defined behavior should be defined by a programming language standard supporting this
standard. Then all implementations conforming both to this floating-point standard and to that language
standard behave identically with respect to such language-defined behaviors. Standards for languages
intended to reproduce results exactly on all platforms are expected to specify behavior more tightly than do
standards for languages intended to maximize performance on every platform.
Because this standard requires facilities that are not currently available in common programming languages,
the standards for such languages might not be able to fully conform to this standard if they are no longer
being revised. If the language can be extended by a function library or class or package to provide a
conforming environment, then that extension should define all the language-defined behaviors that would
normally be defined by a language standard.
Implementation-defined behavior is defined by a specific implementation of a specific programming
environment conforming to this standard. Implementations define behaviors not specified by this standard
nor by any relevant programming language standard or programming language extension.
Conformance to this standard is a property of a specific implementation of a specific programming
environment, rather than of a language specification.
However a language standard could also be said to conform to this standard if it were constructed so that
every conforming implementation of that language also conformed automatically to this standard.
1.6 Word usage
1.6.0
In this standard three words are used to differentiate between different levels of requirements and
optionality, as follows:
― may indicates a course of action permissible within the limits of the standard with no implied
preference (“may” means “is permitted to”)
― shall indicates mandatory requirements strictly to be followed in order to conform to the standard
and from which no deviation is permitted (“shall” means “is required to”)
― should indicates that among several possibilities, one is recommended as particularly suitable,
without mentioning or excluding others; or that a certain course of action is preferred but not
necessarily required; or that (in the negative form) a certain course of action is deprecated but not
prohibited (“should” means “is recommended to”).
Further:
― might indicates the possibility of a situation that could occur, with no implication of the likelihood
of that situation (“might” means “could possibly”)
― see followed by a number is a cross-reference to the clause or subclause of this standard identified
by that number
― NOTE introduces text that is informative (that is, is not a requirement of this standard).
2
Copyright © 2008 IEEE. All rights reserved.
Authorized licensed use limited to: Tsinghua University Library. Downloaded on April 09,2010 at 16:53:43 UTC from IEEE Xplore. Restrictions apply.