将浮点值舍入为单精度

Question

C and C++ provide floating-point data types of several widths, but they leave precision unspecified. The compiler is free to use idealized arithmetic to simplify expressions, to use double precision in computing an expression over float values, or to use a double-precision register to keep the value of a float variable or common subexpression.

Correct me if I'm wrong ^{is wrong, see edit} , but it's even legal to hoist a float in memory into a double-precision register, so storing a value and then loading it back doesn't necessarily truncate bits.

What is the safest, most portable way to convert a number to a lower precision? Ideally, it should be efficient too, compiling to cvtsd2ss on SSE2. (So, while volatile may be an answer, I'd prefer something better.)

Edit: Summarizing some of the comments and findings…

• Wider precision for intermediate results is always fair game.
• Expression simplification is allowed in C++, and in C given FP_CONTRACT on .
• Using double precision for a single-precision float is not allowed (in C or C++).

However, some compilers (particularly GCC on x86-32) illegally forget some precision conversions.

Edit 2: Some folks are expressing doubt as to the conformance of failing to narrow intermediate results.

• C11 §5.2.4.2.2/9 (same as the C99 ref cited in the answer) is specific about "remove all extra range and precision" because it specifies how other computations may be done in wider precision. Among several conforming alternative precisions is "indeterminable," which to me means no constraint whatsoever.

• C11 §7.12.2 and §6.5/8 defines #pragma STDC FP_CONTRACT on which enables the compiler to use infinite precision where possible.

  The intermediate operations in the contracted expression are evaluated as if to infinite range and precision, while the final operation is rounded to the format determined by the expression evaluation method. A contracted expression might also omit the raising of floating-point exceptions.

• C++14 likewise specifically waives the constraints of finite precision and range on intermediate results. N4567 §5/12:

  The values of the floating operands and the results of floating expressions may be represented in greater precision and range than that required by the type; the types are not changed thereby.

Note that allowing the identity x - x = 0 to simplify a + b - b + c into a + c is not the same as making addition commutative or associative. a + b + c is still not the same as a + c + b or a + (b + c) , when the CPU only provides addition with two addends and a rounded result.

Answer 1

The C99 5.2.4.2.2p8 excplicitly says that

assignment and cast [..] remove all extra range and precision

So, if you want to limit the range and precision to that of a float, just cast to float , or assign to a float variable.

You can even do stuff like (double)((float)d) (with extra parentheses to make sure humans read it correctly), limiting a variable d to float precision and range, then casting it back to double . (A standard C compiler is NOT allowed to optimize that away even if d is a double ; it must limit the precision and range to that of a float .)

I've used this in practical implementations of eg Kahan summation algorithm , where it can be utilized to allow the C compiler to do very aggressive optimization, but without risk of invalidation.

Answer 2

I'm not so sure I share your fear here ... I tried this glorified cast-as-a-function:

float to_float(double x)
{
  return (float) x;
}

when entered into the Compiler Explorer , I get this:

to_float(double):
        push     rbp
        mov      rbp, rsp
        movsd    QWORD PTR [rbp-8], xmm0
        cvtsd2ss xmm0, QWORD PTR [rbp-8]
        pop      rbp
        ret

That seems to generate the requested opcode ( cvtsd2ss ) right away, and I didn't even enter any compiler options to force SSE2 or anything.

I'd say that a cast has to convert to the target type, the compiler isn't free to ignore casts as far as I know.

Can you provide some case where you think the compiler can ignore a cast, that you've seen happen? Perhaps there's undefined behavior of some kind lurking in the code, which makes the compiler take unexpected shortcuts.