3.5.7 Floating Point Types
For floating point types, the
error bound is specified as a relative precision by giving the required
minimum number of significant decimal digits.
Syntax
Name Resolution Rules
The
requested decimal precision,
which is the minimum number of significant decimal digits required for
the floating point type, is specified by the value of the
expression
given after the reserved word
digits.
This
expression
is expected to be of any integer type.
Legality Rules
Reason: We have added Max_Base_Digits
to package System. It corresponds to the requested decimal precision
of
root_real. System.Max_Digits corresponds to the maximum value
for Digits that may be specified in the absence of a
real_range_specification,
for upward compatibility. These might not be the same if
root_real
has a base range that does not include ± 10.0**(4*Max_Base_Digits).
A
floating_point_definition
is illegal if the implementation does not support a floating point type
that satisfies the requested decimal precision and range.
Implementation defined: What combinations
of requested decimal precision and range are supported for floating point
types.
Static Semantics
The set of values for a floating point type is the
(infinite) set of rational numbers.
The
machine
numbers of a floating point type are the values of the type that
can be represented exactly in every unconstrained variable of the type.
The base range (see
3.5)
of a floating point type is symmetric around zero, except that it can
include some extra negative values in some implementations.
Implementation Note: For example, if
a 2's complement representation is used for the mantissa rather than
a sign-mantissa or 1's complement representation, then there is usually
one extra negative machine number.
To be honest: If the Signed_Zeros attribute
is True, then minus zero could in a sense be considered a value of the
type. However, for most purposes, minus zero behaves the same as plus
zero.
The
base decimal precision
of a floating point type is the number of decimal digits of precision
representable in objects of the type.
The
safe
range of a floating point type is that part of its base range for
which the accuracy corresponding to the base decimal precision is preserved
by all predefined operations.
Implementation Note: In most cases, the
safe range and base range are the same. However, for some hardware, values
near the boundaries of the base range might result in excessive inaccuracies
or spurious overflows when used with certain predefined operations. For
such hardware, the safe range would omit such values.
A
floating_point_definition
defines a floating point type whose base decimal precision is no less
than the requested decimal precision.
If
a
real_range_specification
is given, the safe range of the floating point type (and hence, also
its base range) includes at least the values of the simple expressions
given in the
real_range_specification.
If a
real_range_specification
is not given, the safe (and base) range of the type includes at least
the values of the range –10.0**(4*D) .. +10.0**(4*D) where D is
the requested decimal precision. [The safe range might include other
values as well. The attributes Safe_First and Safe_Last give the actual
bounds of the safe range.]
To be honest: The conversion mentioned
above is not an
implicit subtype conversion (which is something
that happens at overload resolution, see
4.6),
although it happens implicitly. Therefore, the freezing rules are not
invoked on the type (which is important so that representation items
can be given for the type).
There is a predefined, unconstrained,
floating point subtype named Float[, declared in the visible part of
package Standard].
Dynamic Semantics
Implementation Requirements
In an implementation that supports
floating point types with 6 or more digits of precision, the requested
decimal precision for Float shall be at least 6.
If Long_Float is predefined for
an implementation, then its requested decimal precision shall be at least
11.
Implementation Permissions
An implementation
is allowed to provide additional predefined floating point types[, declared
in the visible part of Standard], whose (unconstrained) first subtypes
have names of the form Short_Float, Long_Float, Short_Short_Float, Long_Long_Float,
etc. Different predefined floating point types are allowed to have the
same base decimal precision. However, the precision of Float should be
no greater than that of Long_Float. Similarly, the precision of Short_Float
(if provided) should be no greater than Float. Corresponding recommendations
apply to any other predefined floating point types. There need not be
a named floating point type corresponding to each distinct base decimal
precision supported by an implementation.
Implementation defined: The predefined
floating point types declared in Standard.
Implementation Advice
An implementation should support
Long_Float in addition to Float if the target machine supports 11 or
more digits of precision. No other named floating point subtypes are
recommended for package Standard. Instead, appropriate named floating
point subtypes should be provided in the library package Interfaces (see
B.2).
Implementation Advice: Long_Float should
be declared in Standard if the target supports 11 or more digits of precision.
No other named float subtypes should be declared in Standard.
Implementation Note: To promote portability,
implementations should explicitly declare the floating point (sub)types
Float and Long_Float in Standard, and leave other predefined float types
anonymous. For implementations that already support Short_Float, etc.,
upward compatibility argues for keeping such declarations in Standard
during the transition period, but perhaps generating a warning on use.
A separate package Interfaces in the predefined environment is available
for pre-declaring types such as Float_32, IEEE_Float_64, etc. See
B.2.
41 If a floating point subtype is unconstrained,
then assignments to variables of the subtype involve only Overflow_Checks,
never Range_Checks.
Examples
Examples of floating
point types and subtypes:
type Coefficient is digits 10 range -1.0 .. 1.0;
type Real is digits 8;
type Mass is digits 7 range 0.0 .. 1.0E35;
subtype Probability is Real range 0.0 .. 1.0; -- a subtype with a smaller range
Inconsistencies With Ada 83
No Range_Checks, only Overflow_Checks,
are performed on variables (or parameters) of an unconstrained floating
point subtype. This is upward compatible for programs that do not raise
Constraint_Error. For those that do raise Constraint_Error, it is possible
that the exception will be raised at a later point, or not at all, if
extended range floating point registers are used to hold the value of
the variable (or parameter).
Reason: This change was felt to be justified
by the possibility of improved performance on machines with extended-range
floating point registers. An implementation need not take advantage of
this relaxation in the range checking; it can hide completely the use
of extended range registers if desired, presumably at some run-time expense.
Wording Changes from Ada 83
Discussion of model numbers is postponed to
3.5.8 and
G.2.
The concept of safe numbers has been replaced by the concept of the safe
range of values. The bounds of the safe range are given by T'Safe_First
.. T'Safe_Last, rather than -T'Safe_Large .. T'Safe_Large, since on some
machines the safe range is not perfectly symmetric. The concept of machine
numbers is new, and is relevant to the definition of Succ and Pred for
floating point numbers.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe