Does the dot in the end of a float suggest lack of precision?

Question

When I debug my software in VS C++ by stepping the code I notice that some float calculations show up as a number with a trailing dot, i.e.:

1232432.

One operation that lead up to this result is this:

float result = pow(10, a * 0.1f) / b

where a is a large negative number around -50 to -100 and b is most often around 1. I read some articles about problem with precision when it comes to floating-points. My question is just if the trailing dot is a Visual-Studio-way of telling me that the precision is very low on this number, i.e. in the variable result. If not, what does it mean?

This came up at work today and I remember that there was a problem for larger numbers so this did to occur every time (and by "this" I mean that trailing dot). But I do remember that it happened when there was seven digits in the number. Here they wright that the precision of floats are seven digits:

C++ Float Division and Precision

Can this be the thing and Visual Studio tells me this by putting a dot in the end?

I THINK I FOUND IT! It says "The mantissa is specified as a sequence of digits followed by a period". What does the mantissa mean? Can this be different on a PC and when running the code on a DSP? Because the thing is that I get different results and the only thing that looks strange to me is this period-thing, since I don't know what it means.

http://msdn.microsoft.com/en-us/library/tfh6f0w2(v=vs.71).aspx

Answer 1

If you're referring to the "sig figs" convention where "4.0" means 4±0.1 and "4.00" means 4±0.01, then no, there's no such concept in float or double. Numbers are always* stored with 24 or 53 significant bits (7.22 or 15.95 decimal digits) regardless of how many are actually "significant".

The trailing dot is just a decimal point without any digits after it (which is a legal C literal). It either means that

• The value is 1232432.0 and they trimed the unnecessary trailing zero, OR
• Everything is being rounded to 7 significant digits (in which case the true value might also be 1232431.5, 1232431.625, 1232431.75, 1232431.875, 1232432.125, 1232432.25, 1232432.375, or 1232432.5.)

The real question is, why are you using float? double is the "normal" floating-point type in C(++), and float a memory-saving optimization.

* Pedants will be quick to point out denormals, x87 80-bit intermediate values, etc.

Answer 2

The precision is not variable, that is simply how VS is formatting it for display. The precision (or lackof) is always constant for a given floating point number.

Answer 3

The MSDN page you linked to talks about the syntax of a floating-point literal in source code. It doesn't define how the number will be displayed by whatever tool you're using. If you print a floating-point number using either printf or std:cout << ..., the language standard specifies how it will be printed.

If you print it in the debugger (which seems to be what you're doing), it will be formatted in whatever way the developers of the debugger decided on.

There are a number of different ways that a given floating-point number can be displayed: 1.0, 1., 10.0E-001, and .1e+1 all mean exactly the same thing. A trailing . does not typically tell you anything about precision. My guess is that the developers of the debugger just used 1232432. rather than 1232432.0 to save space.

If you're seeing the trailing . for some values, and a decimal number with no . at all for others, that sounds like an odd glitch (possibly a bug) in the debugger.

If you're wondering what the actual precision is, for IEEE 32-bit float (the format most computers use these days), the next representable numbers before and after 1232432.0 are 1232431.875 and 1232432.125. (You'll get much better precision using double rather than float.)