5

Can there be a difference in bit-representation between a direct assignment of a floating point literal float x = 3.2f; and a double implicitly converted to a float float x2 = 3.2;?

I.e. is

#define EQUAL(FLOAT_LITERAL)\ FLOAT_LITERAL##f == static_cast<float>(FLOAT_LITERAL) EQUAL(3.2) && EQUAL(55.6200093490) // etc ...

true for all floating point literals?

I ask this question, because clang or gcc do not complain about narrowing conversions if numbers are in the value range of float: Warning is enabled with -Wnarrowing:

float f {3.422222222222222222222222222222246454}; // no warning/ error although it should definitely lose precision float f2 {static_cast<double>(std::numeric_limits<float>::max()) + 1.0}; // no warning/ error float f3 {3.5e38}; // error: narrowing conversion of '3.5e+38' from 'double' to 'float' inside { } [-Wnarrowing]

It is great that the compiler does actual range checks, but is that sufficient?

Improve this question
6
  • You type these two statements into compiler explorer and check. Commented Mar 28, 2019 at 23:15
  • 1
    @Mansoor, thanks for that hint. I don't see how that would help me though, because I am not interested in these specific numbers but in the general rule. Commented Mar 28, 2019 at 23:18
  • I don't expect the instructions to change based on the numeric value of the numbers, for a simple assignment. Commented Mar 28, 2019 at 23:22
  • @Mansoor. I guess I am asking for more insight in what the compiler actually does, since it's no runtime code. I did check with some hand-picked values, but I don't want to type out all possible doubles to be sure. godbolt.org/z/MmY9-H Commented Mar 28, 2019 at 23:36
  • Compiler actions are in general supposed to be indistinguishable from the runtime actions, of course, but I'm not sure how much leeway FP in general has in C++. I know it is laxer than some other languages. Commented Mar 28, 2019 at 23:47

3 Answers 3

Reset to default
5

Assuming IEEE 754, float as 32 bit binary, double as 64 bit binary.

There are decimal fractions that round differently, under IEEE 754 round-to-nearest rules, if converted directly from decimal to float from the result of first converting from decimal to double and then to float.

For example, consider 1.0000000596046447753906250000000000000000000000000001

1.000000059604644775390625 is exactly representable as a double and is exactly half way between 1.0 and 1.00000011920928955078125, the value of the smallest float greater than 1.0. 1.0000000596046447753906250000000000000000000000000001 rounds up to 1.00000011920928955078125 if converted directly, because it is greater than the mid point. If it is first converted to 64 bit, round to nearest takes it to the mid point 1.000000059604644775390625, and then round half even rounds down to 1.0.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Thanks for the explanation! Just for completeness, this is a goldbolt link which verifies your statement: godbolt.org/z/TOXU-V
5

The answer given by Patricia is correct. But we generally don't type such number, so maybe it's not a problem... Unless it happens with some shorter decimal literals?

I have illustrated that once in the comments following that answer Count number of digits after `.` in floating point numbers?

The decimal value 7.038531e-26 is approximately 0x1.5C87FAFFFFFFFCE4F6700...p-21 the nearest double is 0x1.5C87FB0000000p-21 and the nearest float is 0x1.5C87FAp-21.

Note that 0x1.5C87FA0000000p-21 is the nearest double to 7.038530691851209e-26

So yes, there can be a double-rounding problem (round off error twice in the same direction) with a relatively short literal...

float x = 7.038531e-26f; and float y = 7.038531e-26; should be two different numbers if the compiler rounds the literals correctly.

Improve this answer

4 Comments

Nice example, +1. x=0x1.5c87fap-84 y=0x1.5c87fcp-84.
Good work. I considered constructing a short literal, but in the interests of time I went with one I knew would show the problem.
Awesome, thank you! For completeness, this is a godbolt link, which verifies your statement that x and y should be different: godbolt.org/z/Bcp47p
@PatriciaShanahan This example is particularly interesting because that string can be the result of formatting a float in Java - in fact it, and its negation, are the only such numbers. I don't believe your example can; it could be handwritten in source code, but not produced by formatting. So, for example, if you are serialising some data to JSON and then parsing it, it is not entirely safe to handle fields of type float by letting the JSON parser parse it to a double and then casting it to float!
2

Is literal double to float conversion equal to float literal?

Usually yes, but not always equal.

Code to double then to float (vs. code to float) potentially incurs double rounding trouble.

Problem seen with any code value (even possible without a fraction) that is near the half-way case of two adjacent float values.

Occurrence: With random constants and typical float/double: about 1 in 230.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.