8

Does the C++03 standard guarantee that sufficiently small non-zero integers are represented exactly in double? If not, what about C++11? Note, I am not assuming IEEE compliance here.

I suspect that the answer is no, but I would love to be proved wrong.

When I say sufficiently small, I mean, bounded by some value that can be derived from the guarantees of C++03, and maybe even be calculated from values made available via std::numeric_limits<double>.


EDIT:

It is clear (now that I have checked) that std::numeric_limits<double>::digits is the same thing as DBL_MANT_DIG, and std::numeric_limits<double>::digits10 is the same thing as DBL_DIG, and this is true for both C++03 and C++11.

Further more, C++03 defers to C90, and C++11 defers to C99 with respect to the meaning of DBL_MANT_DIG and DBL_DIG.

Both C90 and C99 states that the minimum allowable value for DBL_DIG is 10, i.e., 10 decimal digits.

The question then is, what does that mean? Does it mean that integers of up to 10 decimal digits are guaranteed to be represented exactly in double?

In that case, what is then the purpose of DECIMAL_DIG in C99, and the following remark in C99 §5.2.4.2.2 / 12?

Conversion from (at least) double to decimal with DECIMAL_DIG digits and back should be the identity function.


Here is what C99 §5.2.4.2.2 / 9 has to say about DBL_DIG:

Number of decimal digits, 'q', such that any floating-point
number with 'q' decimal digits can be rounded into a
floating-point number with 'p' radix 'b' digits and back again
without change to the q decimal digits,

    { p * log10(b)              if 'b' is a power of 10
    {
    { floor((p-1) * log10(b))   otherwise

FLT_DIG   6
DBL_DIG   10
LDBL_DIG  10

I'll be happy if someone can help me unpack this.

Kristian Spangsege
  • 2,903
  • 1
  • 20
  • 43
  • Lots of requirements for floating point types are given in §5.2.4.2.2 of the C99 standard (which is normative in C++03), if anybody cares to decipher it. It might have some kind of guarantee for some integers. – Joseph Mansfield Dec 31 '13 at 00:17
  • What exactly does it mean for C99 to be *normative* in C++03? – Kristian Spangsege Dec 31 '13 at 00:25
  • It means it should be taken as almighty truth whenever referenced! In this case, it is referenced as part of the definition of the `` header. It's basically borrowing from the other standard. – Joseph Mansfield Dec 31 '13 at 01:08
  • @sftrabbit I can see that C99 is mentioned as a *normative reference* in C++03 [intro.refs]. However, C99 is not (at least for the most part) to be considered part of C++03, as is stated in C++03 [intro.scope]. In particular, the `DECIMAL_DIG` macro is not part of C++03. – Kristian Spangsege Dec 31 '13 at 01:31

2 Answers2

7

Well, 3.9.1 [basic.fundamental] paragraph 8 states

... The value representation of floating-point types is implementation-defined. ...

At least, the implementation has to define what representation it uses.

On the other hand, std::numeric_limits<F> defines a couple of members which seem to imply that the representation is some in the form of significand radix exponent:

  • std::numeric_limits<F>::radix: the radix of the exponent
  • std::numeric_limtis<F>::digits: the number of radix digits

I think these statements imply that you can represent integers in the range of 0 ... radix digits - 1 exactly.

Dietmar Kühl
  • 150,225
  • 13
  • 225
  • 380
  • I think the model for these is defined in C99 5.2.4.2.2/2, "A *floating-point number (x)* is defined by the following model: `x = s b^e \sum_{k=1}^{p} f_k b^{-k}`, `e_{min} \leq e \leq e_{max}`" – dyp Dec 31 '13 at 00:19
  • It also depends whether 0 is contained in the range min_exponent.. max_exponent (or more precisely whether a number between 0 and -digits to represent some small integers with is included in this range). Does the standard mandate that? – Pascal Cuoq Dec 31 '13 at 00:22
  • @PascalCuoq: the formula quoted by DyP means that floating point numbers are symmetric (and may have multiple versions of zero as is, e.g., the case for IEEE-754 floating points where the base 2 representation has two zeros and the decimal representation has a couple of hundred zeros). – Dietmar Kühl Dec 31 '13 at 00:27
  • @DietmarKühl My question is not whether 0 is representable as a floating-point number but whether 0 is guaranteed to be in the range **min_exponent..max_exponent**. If it is not, then not all integers in the range 0..radix^digits - 1 are representable exactly. – Pascal Cuoq Dec 31 '13 at 01:01
  • 1
    To illustrate, take min_exponent=100, max_exponent=353 on the one hand, and min_exponent=-353, max_exponent=-100 on the other hand, and other parameters as in IEEE 754 binary32. For each of these two hypothetical binary floating-point systems, it is impossible to represent the number 3. – Pascal Cuoq Dec 31 '13 at 01:05
  • 3
    @PascalCuoq: oh, sorry. Yes, 0 is certainly in the covered range for floating point types: The `min_exponent` is required to be negative and the `max_exponent` is required to be positive. – Dietmar Kühl Dec 31 '13 at 01:23
  • @DietmarKühl: for double IEEE-754 floating points, 2^53 produce ~9007199 billions which is 16 digits, whereas std::numeric_limits::digits10 for double return 15, isn't there any discrepancy ? – Guillaume Paris Jan 16 '14 at 10:27
  • 1
    @Guillaume07: you can only safely round-trip decimal values with up to `...::digits10` digits (i.e., original decimal -> `double` -> restored decimal yields the same value for original decimal and restored decimal). When using more digits the round trip isn't guaranteed to work alrhough it still dies work for some values. – Dietmar Kühl Jan 16 '14 at 11:35
2

From the C standard, "Characteristics of floating types <float.h>", which is normative for C++, I would assume that you can combine FLT_RADIX and FLT_MANT_DIG into useful information: The number of digits in the mantissa and the base in which they are expressed.

For example, for a single-precision IEEE754 float, this would be respectively 2 and 24, so you should be able to store integers of absolute value up to 224.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084