4 ms·
But while trying to store a 64-bit integer in double the exact value can be lost (see picture 1). I've seen that first hand. In fact, I wrote code to fix it. T
by 16s 14y ago
But while trying to store a 64-bit integer in double the exact value can be lost (see picture 1).
I've seen that first hand. In fact, I wrote code to fix it. The guy who wrote the code, still did not get it... 64 bits is 64 bits he said, right... well yes, but that's not the issue here. When you have an int that is say 56 bits in size and you put it in a double that is 64 bits... see what happens:
#include <iostream>
#include <boost/integer.hpp>
int main()
{
boost::uint64_t too_big = 72057594037927936;
double wont_fit = too_big;
std::cout << too_big << "\n";
std::cout << wont_fit << "\n";
return 0;
}
./a.out
72057594037927936
7.20576e+16
The maddening part about this is that it's hit or miss. Smaller numbers fit just fine:
#include <iostream>
#include <boost/integer.hpp>
int main()
{
boost::uint64_t not_too_big = 281234;
double will_fit = not_too_big;
std::cout << not_too_big << "\n";
std::cout << will_fit << "\n";
return 0;
}
./a.out
281234
281234
Finding and fixing bugs like this will cause ulcers.
- Arelius 14y ago> 64 bits is 64 bits he said, right... well yes That's the problem right there. 64 bits is not always 64 bits. While a 64 bit int gives you a 64 bit number (Actually a 63 bit number and a 1 bit sign flag). An IEEE double precision float only gives you a 52 bit number, and a separate 11 bit number as an exponent. So the problem is that declaring that 64 bits is 64 bits is actually precisely the issue here.
- MichaelSalib 14y agoActually a 63 bit number and a 1 bit sign flag Not true. Modern architectures use 2s-complement rather than an explicit sign bit to represent integers. If you use a sign bit, there are two different zeros (positive and negative) but the range of positive numbers is exactly as large as the range of negative numbers. With 2s-complement, there's only one zero and the range of negative numbers is larger (by one) than the range for positive numbers.
- dschatz 14y agoIn 2s complement, the most significant bit is the sign bit. In fact all valid C integer representations have a sign bit.
- cube13 14y agoSigned integer representations. Unsigned ints do not, and you're given the full range of the integer as valid data.
- dschatz 14y agoYes you're right. I should have been more specific that all signed integers have a sign bit.
- to3m 14y agoI think his point is that changing a sign bit doesn't affect the absolute value, just its sign. A sign bit has no value itself - it's just a flag. If the representation has a sign bit, you'd have a negative zero. But the top bit in 2s complement has a value - it's just a negative one (that's large enough to make any value with it set negative). That's not a sign bit! If you change it, the absolute value most definitely changes, and quite substantially.
- MichaelSalib 14y agoThis is wrong. Take an integer value x. Flip the sign bit. Do you now have the value -x? On a 2s complement architecture, you do not. In 2s complement, you have to flip all the bits and add one to get -x.
- dschatz 14y agoSign bit means one bit represents the sign of the integer which is the case with the most significant bit in 2s complement. If you flip the sign bit, the sign changes. It does not mean that if you flip the sign, the value is negated.
- 14y ago
- thwest 14y agoYour first example works just fine with increased output precision. https://ideone.com/GtMDit https://ideone.com/GtMDit A slightly larger number shows the discrepancy: https://ideone.com/WPtpX4 https://ideone.com/WPtpX4
- peripetylabs 14y agoOne way to avoid loss of precision in the conversion is to check if the number of digits in the integer is larger than the constant DBL_DIG (defined in <cfloat>) -- numbers with less digits than that constant can be safely converted to the 'double' type and back.
- thwest 14y agoNote that DBL_DIG is the number of decimal digits that can be a 9. If the max integral value storable in a double is 4,000,000, DBL_DIG would only be 6. It is a conservative limit.