On Thu, 14 Nov 2024 10:04:59 +0100 David Brown via Gcc <gcc@gcc.gnu.org> wrote:
> No. This is - or at least appears to be - missing critical thinking. You are explaining this to someone who designed research databases and who implemented quantitative models that ran on them. You're entitled to your opinion, of course. I thought you were scratching your head to understand how x == 0 might be a useful test, not preparing to explain to me how to do my job of 17 years. > you are not completely sure that you have full control over the data Does the programmer breathe who has full control over input? Errors occur. Any analyst will tell you 80% of the work is ensuring the accuracy of inputs. Using SQL COALESCE to convert a NULL to 0 is a perfectly clear and dependable way to represent it. I'm not saying it's always done, or the best way. I'm saying it's deterministic, which is good enough. > And the programmer should know that testing for floating > point /equality/, even comparing to 0.0, is a questionable choice of > strategy. What's "questionable" about it? If 0 was assigned, 0 is what it is. If 1 was assigned, 1 is what it is. Every 32-bit integer, and more, is likewise accurately stored in a C double. > will not have to wonder why the programmer is using risky > code techniques. I would say fgetc(3) is risky if you don't know what you're doing, and float equality is not, if you do. I would also say that, if you were right, equality would not be a valid operator for floating point in C. I get it. I can imagine suspecting a dodgy comparison and, in lieu of better tools, using -Wfloat-equal to surface for inspection all floating-point equality tests. I'm just not willing to say all such uses are risky, ill-defined, or na. --jkl
