对double进行转换是否始终返回相同的值？

Question

Does casting double to float always produce same result, or can there be some "rounding differences"?

For example, is x in

float x = (float)0.123456789d;

always the same value?

What about when casting float to double, and then casting it back to float ie. (float)(double)someFloat ?

Mostly interested in what the results are in C#, but feel free to share if you have knowledge about how this works on other languages.

Answer 1

The results should not be language dependent, unless the language deviates from the IEEE specification.

All floats can be exactly represented as doubles, so the round trip from float to double to float should yield the same value that you started with.

Similarly, casting any double value to float should always yield the same result, but, of course, there are many different double values that would truncate to the same float value.

Answer 2

If you downcast a double to a float , you are losing precision and data. Upcasting a float to a double is a widening conversion; no data is lost if it is then round-tripped...that is, unless you do something to the value prior to downcasting it back to a float.

Floating-point numbers sacrifice precision and accuracy for range . Single-precision floats give you 32-bits of precision; double-precision give you 64-bits. But they can represent values way outside the bounds that the underlying precision would indicate.

C# float and double are IEEE 754 floating point values.

• float is a single-precision IEEE 754 value (32 bits) and consists of a

  • 1-bit sign
  • 8-bit exponent
  • 23-bit mantissa/significand

• double is double-precision IEEE 754 value (64 bits) and consists of a

  • 1-bit sign
  • 11-bit exponent
  • 52-bit mantissa/significand

The effective precision of the mantissa is 1-bit more than its apparent size (floating point magick).

Some CLR floating point resources for you:

• http://csharpindepth.com/Articles/General/FloatingPoint.aspx
• http://www.extremeoptimization.com/resources/Articles/FPDotNetConceptsAndFormats.aspx

This paper is probably the canonical paper on the perils and pitfalls of floating point arithmetic. If you're not a member of the ACM, click the link on the title to find public downloads of the article:

• David Goldberg. 1991. What every computer scientist should know about floating-point arithmetic . ACM Comput. Surv. 23, 1 (March 1991), 5-48. DOI=10.1145/103162.103163 http://doi.acm.org/10.1145/103162.103163

  Abstract
  Floating-point arithmetic is considered as esoteric subject by many people. This is rather surprising, because floating-point is ubiquitous in computer systems: Almost every language has a floating-point datatype; computers from PCs to supercomputers have floating-point accelerators; most compilers will be called upon to compile floating-point algorithms from time to time; and virtually every operating system must respond to floating-point exceptions such as overflow. This paper presents a tutorial on the aspects of floating-point that have a direct impact on designers of computer systems. It begins with background on floating-point representation and rounding error, continues with a discussion of the IEEE floating point standard, and concludes with examples of how computer system builders can better support floating point.

Answer 3

In some cases, the closest float representation to a numeric quantity may differ from the value obtained by rounding the closest double representation to a float . Two such quantities are 12,344,321.4999999991 and 12,345,678.50000000093. The integers above and below both those quantities are precisely representable as float , but the nearest double to each of them has a fractional part of precisely 0.5. Because converting such double values (between 2^23 and 2^24, with a fraction of precisely 0.5) to float will round to the nearest even integer; the compiler will in each case end up rounding away from the value which would have been closer to the original number.

Note that in practice, the compiler seems to parse numbers as double , and then convert to float , so even though 12344321.4999999991f should round to 12344321f, it instead rounds to 12344322f. Likewise 12345678.50000000093f should rounds to 12345679f but rounds to 12345678f, so even in cases where conversion to double and then float loses precision, such conversion loss cannot be avoided by specifying numbers directly as float .

Incidentally, the values 12344321.4999999992f and 12345678.50000000094f are rounded correctly.

Answer 4

Considering that they have different precision, even i you're casting from less precision to wider one (I suppose that is actually your doubt) the result can not be always the same.

Floating point operations, especially casting, are always a subject of truncating/rounding and any other type of approximation .

Answer 5

A double should be able to to exactly hold every possible value of a float. Casting a float to a double should not change the value, and casting back to a float should return the original value, as long as you didn't perform any calculations on the double in the meantime.

Answer 6

Floating-point numbers in C# are stored using the IEEE 754 format (http://en.wikipedia.org/wiki/IEEE_754). This format has two parts: the digits and the exponent. Doubles hold 52 digits, and floats hold 23 digits. The base is 2, not ten. So for your example above (0.123456789), the digits would be 111010110111100110100010101 (the binary representation of 123456789). That's 27 digits, which fits comfortably in a double, but not in a float, so yes, precision would be lost in the round-trip conversion.

On the other hand, if your number was 0.123456, the digits would be 11110001001000000 (17 digits) which fits comfortably in either a float or a decimal, so you would lose no precision in a round-trip cast.