-1

In the source text of a C program, do .1 and 0.1 have the same value?

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312
user10139530
  • 47
  • 2
  • Yes, it means `0.1` and the type of `0.1` is `double`. – Weather Vane Aug 10 '18 at 20:28
  • @WeatherVane can i be also float? – user10139530 Aug 10 '18 at 20:29
  • We need a special close reason for yes/no questions. – Eugene Sh. Aug 10 '18 at 20:29
  • No, it is `double`. The value `.1f` is `float`. – Weather Vane Aug 10 '18 at 20:29
  • 1
    @WeatherVane: Well, according to the C standard, `.1` and `0.1` are permitted to be different! Per C 2018 6.4.4.2 5, constants with the same source form must convert to the same internal value, but there is no such rule for constants with different source form. – Eric Postpischil Aug 10 '18 at 20:30
  • @EricPostpischil thank you for that advice, but the plain answer is that `printf("%zu\n", sizeof 0.1);` and `printf("%zu\n", sizeof .1);` both output `8`. However my compiler is not 2018 compliant so can you please post its results as you are up-to-speed in these matters? I see from your answer that in practice, they are the same so no thanks for jumping on me. – Weather Vane Aug 10 '18 at 20:34
  • 1
    @WeatherVane I am not sure what `sizeof` has to do with it.... The cited paragraph means that `0.1 == .1` is not necessarily true. – Eugene Sh. Aug 10 '18 at 20:36
  • 1
    @EugeneSh. it shows they were both converted to `double`. – Weather Vane Aug 10 '18 at 20:37
  • 1
    @WeatherVane Yes, but that standard thing is talking about value, not type. – Eugene Sh. Aug 10 '18 at 20:38
  • I am wondering if we should re-open this if the votes close it initially. It is a simple question, but many, if not most, people familiar with C are likely to incorrectly assert that `.1` and `0.1` are the same. So the question gets at an interesting point. On the other hand, I have not voted up for it myself, and I do not think the question is a good vehicle for this point. – Eric Postpischil Aug 10 '18 at 20:46
  • 1
    @EricPostpischil: I generally upvote any question that generated an answer that I want to upvote. – jxh Aug 10 '18 at 20:49
  • The question should be heavily edited to attract the attention to this point. @user10139530 This is your chance. – Eugene Sh. Aug 10 '18 at 20:49
  • It probably doesn't matter, but I don't see any evidence that the edited question is what @user10139530 was actually asking. – Steve Summit Aug 11 '18 at 10:07

2 Answers2

9

.1 represents one-tenth, the same as 0.1 does. However, due to a lack of strictness in the C standard, .1 and 0.1 do not necessarily convert to the same internal value, per C 2018 6.4.4.2 5. They will be equal in all compilers of reasonable quality. (6.4.4.2 5 says “All floating constants of the same source form shall convert to the same internal format with the same value.” Footnote 77 gives examples of source forms that have the same mathematical values but that do not necessarily convert to the same internal value.)

Floating-point constants in source text are converted to an internal format. Most commonly, a binary-based format is used. Most decimal numerals, including .1, are not exactly representable in binary floating-point. So, when they are converted, the result is rounded (in binary) to a representable value. In typical C implementations, .1 becomes 0.1000000000000000055511151231257827021181583404541015625.

All good compilers will convert .1 and 0.1 to the same value. The reason the C standard is lax about this is that other floating-point literals, involving exponents or many digits, were difficult (in some sense) to convert to binary floating-point with ideal rounding. Historically, there were C implementations that fudged the conversions. The C standard accommodated these implementations by not making strict requirements about handling of floating-point values. (Today, good algorithms are known, and any good compiler ought to convert a floating-point literal to the nearest representable value, with ties to the even low digit, unless the user requests otherwise.)

So, the C standard does not guarantee that .1 and 0.1 have the same value. However, in practice, they will.

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312
  • 1
    This may be *correct* but it does not answer the simple question from a beginner before first blinding OP with science. As asked, the missing `0` is implied and both have the same value, with every compiler ever written. – Weather Vane Aug 10 '18 at 21:35
  • @WeatherVane: It answers the simple question in the first sentence. And it says `.1` and `0.1` are usually equal in the third sentence, the first sentence of the third paragraph, and the last sentence. – Eric Postpischil Aug 10 '18 at 21:43
  • But they are *always* equal. What compiler of any practical use would make them different, and wag a finger at the standard? The example linked by jxh is rather different. As you commented above *"I do not think the question is a good vehicle for this point"*. – Weather Vane Aug 10 '18 at 21:47
  • @WeatherVane Yet if you look at the upvotes, SO clearly values this sort of Standards-thumpery, regardless of whether it has any bearing on the OP's needs. – Steve Summit Aug 10 '18 at 22:10
  • @SteveSummit I appreciate that, however I never expect accuracy from floating point variables, any more than I did from logarithm tables, or from a slide rule, although Eric has called me out on that sort of statement before now, as he likes to! – Weather Vane Aug 10 '18 at 22:39
  • 1
    @SteveSummit: I look at it this way: Many programmers just write code for some specific situation. They do not worry about conforming to the standard precisely, and it suits their purposes. Their code might never be used elsewhere or can be adjusted when it is. Others write for situations where their code is deployed to a billion devices, is compiled in different environments, and will be reused and adapted numerous times in the future. They need to get it right or carefully document the assumptions made. These programmers need clarity about standards and specifications.… – Eric Postpischil Aug 11 '18 at 05:36
  • 1
    … Giving clarity and precision about standards and specifications satisfies both groups, and those in between and elsewhere. Anyone who does not need precision can neglect the extra details. Anyone who does need it has it. But disregarding clarity and precision serves only a subset—and it may serve them poorly, mislead them, and impede their progress to becoming better engineers. I also find the experience of interpreting the standard leads to understanding of how humans and industries operate, how compiler development proceeds. We get better at understanding practical compilers through this. – Eric Postpischil Aug 11 '18 at 05:38
  • 1
    @WeatherVane: jxh showed an example in an actual compiler where [adding a numerically insignificant “0’ did in fact change the value](https://stackoverflow.com/q/16831464/298225). No, we do not have an example where `.1` and `0.1` are different, but we do not want to teach people that numerically non-significant zeros do not change things because we know that, in fact, there are in the real world compilers in which they do change things. – Eric Postpischil Aug 11 '18 at 05:44
  • @EricPostpischil No argument with any of that. – Steve Summit Aug 11 '18 at 10:05
0

Eric's answer is correct if you're just talking about the baseline C standard, which makes basically no guarantees about floating point; 1.0==42.0 is a valid implementation choice. But this is not very helpful.

If you want any reasonable floating point behavior in C, you want an implementation that supports Annex F (the alignment of IEEE floating point semantics with C), an optional part of the standard. You can tell if your implementation supports (or claims to support) Annex F by checking for the predefined macro __STDC_IEC_559__.

Assuming Annex F, the interpretation of floating point literals is not up for grabs, and .1 and 0.1 will necessarily be the same.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • Re “You can tell if your implementation supports…”: Not quite. If `__STDC_IEC_559__`, the implementation claims to support Annex F. If it does not, it is no indication of whether Annex F is supported or not. In particular, an implementation might support a lot of Annex F, including features that a particular programmer cares about in some situation, but falls short in some minor regard and hence cannot define `__STDC_IEC_559__`. Some preprocessor indicators, like that for variable-length arrays, are useful for selecting one set of code or another. But this one may be not as useful as desired. – Eric Postpischil Aug 11 '18 at 05:30
  • @EricPostpischil: None of that is inconsistent with what I wrote. – R.. GitHub STOP HELPING ICE Aug 11 '18 at 13:47
  • 2
    “You can tell if your implementation supports (or claims to support) Annex F by checking for the predefined macro `__STDC_IEC_559__`” is not correct because the C standard only requires that **if** an implementation defines `__STDC_IEC_559__` **then** it conforms. It does not require that **if** an application conforms, **then** it defines `__STDC_IEC_559__`. So you cannot completely tell from this preprocessor symbol. Some C compilers are separate from the standard library implementation, so the compiler cannot define the symbol even if everything it does itself conforms, since it might be… – Eric Postpischil Aug 11 '18 at 20:50
  • … paired with a library that does not conform. If the symbol is not defined, the implementation still might conform. – Eric Postpischil Aug 11 '18 at 20:51
  • @EricPostpischil: The standard makes no distinction between compiler and library; they are both part of "the implementation". GCC and clang both implicitly preinclude `stdc-predef.h` if it exists specifically so that the library can influence predefined macros. You're correct that an implementation might have behavior that conforms in some ways (or even in all ways) to Annex F without defining the macro, but in that case it's not making any promise that it conforms, and it would be unwise to rely on it doing so, so testing for the macro is the right thing to do if you depend on the behavior. – R.. GitHub STOP HELPING ICE Aug 11 '18 at 22:38
  • Unfortunately, one cannot rely on the preprocessor symbol. Consider that IEEE 754 recommends that various transcendental functions be implemented with correct rounding, but **nobody** has implemented these functions with both correct rounding and known bounded run-time. In my view, that is a defect in the IEEE 754 standard. But it means a C implementation which provides very high quality but not completely correctly rounded library routines might choose not to set `__STDC_IEC_559__` even though everything else about the implementation satisfies the standard. Then a program that merely needs… – Eric Postpischil Aug 12 '18 at 05:50
  • … assurances about ordinary arithmetic cannot rely on `__STDC_IEC_559__` to select which source code it uses (or whether to generate an error or warning). The C standard could have improved the situation by providing finer resolution, in the form of multiple symbols specifying degrees or subsets of conformance. – Eric Postpischil Aug 12 '18 at 05:51
  • About "It does not require that if an application conforms, then it defines `__STDC_IEC_559__`": [here](https://stackoverflow.com/q/72143685/1778275) is the rationale-seeking question. – pmor Sep 15 '22 at 19:45