0

I have read a bit about floating-point promotion. I know that it doesn't apply on binary arithmetic operations, only on e.g. overload resolution. But why?

The C++ standard guarantees that double must be at least as precise as float [basic.fundamental.8] and the floating point promotion is required to keep the value unchanged [conv.fpprom]. Yet this question makes it very clear that it does not happen. Stroustrup, 4th edition has the subject even errata-ed (here, Chapter 10, p. 267).

However, I cannot see any reason why the promotion cannot be done in usual arithmetic conversions [expr.10], even if all prerequisites are met. Is there any?

The latest C++14 working draft can be found here, the final version is purchase-only.

Community
  • 1
  • 1
Jakub Zaverka
  • 8,816
  • 3
  • 32
  • 48

2 Answers2

1

Converting a float to a double costs something, and it's likely more expensive than a short to int conversion (it needs several shifts and bit combining operations). And unlike e.g. short, the float type is considered something on which the processor can operate directly (just like it can on int).

Given the facts obove, why should floating-point promotion happen when it's not necessary? That is, if you're adding two floats, why convert them to double, add them, and then convert them back to float?(1)

Note that a floating-point promotion will indeed happen when you're adding mixed arguments (e.g. a float + double), by the very ruling in C++14 [expr] you're referring to.

  • (10.3) Otherwise, if either operand is double, the other shall be converted to double.

As per [conv.fpprom], this conversion from float to double is carried out by floating point promotion.

(1) Of course, it is perfectly possible this will happen internally if the processor cannot operate on floats directly, and [expr].12 explicitly allows that. But that very paragraph says

the types are not changed thereby.

Angew is no longer proud of SO
  • 167,307
  • 17
  • 350
  • 455
  • Thank you for your answer. I am having trouble finding out where exactly is floating-point promotion allowed in [expr]. All I can find is conversion (10.3). Under IEEE 754 this is lossless, but perhaps some other floating-point implementation can distinguish between promotion and conversion. – Jakub Zaverka Aug 15 '16 at 12:58
  • @JakubZaverka But converting a `float` to a `double` **is** a *floating point promotion.* Refer to 4.6 – Angew is no longer proud of SO Aug 15 '16 at 13:04
  • Oh I get it now, the conversion is done by promotion. I thought these are two separate operations that cannot be mixed together. – Jakub Zaverka Aug 15 '16 at 13:08
1

It does!

I don't know what you call "work", but the scope of definition for floating-point promotion and usual arithmetic conversions is different.

  1. usual arithmetic conversions : Apply to binary operators that expect operands of arithmetic or enumeration type.
  2. floating-point promotion : Apply to prvalues of type float.

Some expressions, like a + b qualify for both, while 1.0f qualify only as a prvalue.

The standard you linked says (about usual arithmetic conversions)

(10.3) if either operand is double, the other shall be converted to double
...
(10.5) — Otherwise, the integral promotions shall be performed on both operands

It doesn't restrict how the other operand is converted to double, so I would assume that double + float follow the floating-point promotion rule.

UmNyobe
  • 22,539
  • 9
  • 61
  • 90
  • Thanks. I thought that the distinction had to be made because of the difference between promotion and conversion. But if double is at least as precise as float, then indeed the conversion can also be lossless. – Jakub Zaverka Aug 15 '16 at 13:02