LabWindows/CVI
Accuracy problem with atof
Solved!
Well, it could be that it isn't an exact representation then 
Won't I have put my foot in my mouth then.
The online IEEE 754 calculator I was citing does show it as an exact representation of 39.998, but if they have the displayed value getting rounded by a formatter somewhere along the line then that's a problem. Or maybe the one you're citing is getting it wrong.
The ultimate answer is to look at the double value's bit pattern and sum the powers of two with an arbitrary precision arithmetic tool (like Maple) and see what the actual decimal value is that's being represented.
It remains curious, though, that if you put the "view" of the CVI view variable window to "memory" and the format to "doubles" you get 39.998 , not the value displayed by hovering the cursor or looking at the view variable window.
Menchar
The reason the memory window shows 39.998 is because it only has 14 digits of precision in the UI. (Yeah, there are 15 digits to the right of the decimal point, but that's because it's showing it as 3.9...E1, instead of 39.9...E0). If you experiment with the precision of a numeric control in the CVI UI Editor, for example, you'll find that the cutoff is 15. With 14 and lower it shows it as 39.99800000000000, which makes sense. But with 15 and higher all those zeros disappear. So this is really a UI issue, not a floating point representation issue.
I hadn't noticed your link before. You're right, that website does show it as 39.998000000000000. I counted the digits and there are 15, so something is off there. They're losing a digit of precision somewhere, I'm not sure why. The hex value is the same in both websites.
I tested with MSVC and it also shows the inexact value:
Luis
I think doubles are 16 significant decimal digits only when the leading digit is a 1 (or some other, similar constraint), and are 15 digits otherwise.
The calculator I was using is implemented with Java Script so it's possible there's a formatting issue that they don't understand.
Yup, the hex values are the same. It's not hard to figure it out when you look at the binary value - the exponent is 2 to the 5th power is 32 times the mantissa (or significand as IEEE 754 calls it) which according to the calculator the decimal equivalent is 1.2499375000000000 which if you multiply it out by hand is exactly 39.998.
So, if that site has an error, it's in the decimal equivalent of the significand - it's not really 1.2499375, its been rounded. Now I'm going to add up all of the fractional binary and nail this down .... well, maybe not 
Menchar
