macOS C: float goes right to zero even though 3/4 = .75

[ghellquist]

Excuse me, but I wrote what I wrote and I didn't write what I didn't write. I wrote that (x + y) * 0.5 is the same as (x + y) / 2 and the same as (x + y) / 2.0 and that is absolutely one hundred percent true. No point claiming that things I didn't write are wrong.

Sorry if you take this personally. My post was not meant as anything else than trying to show some of the small but important details of the c language.

And, yes, if doing mathematics outside of computers ypu are absolutely right. It is exactly the smae value.

But, no, across all the different c compilers and implementations it is not an absolute thruth.

Most systems today run IEEE 754 floating point. And then the results will be the same. It is a rather complicated but interesting exercise to show where in the standards documents this is shown to be the case. Left to the reader. And also a quite interesting exercise to prove that it is correct for a given c compiler reardless of the values of a and b and regardless of all possible optimizations.f

But not all. There are a number of other ways to, still following c specs, implement floating point. One example is on small systems without hardware support for floats. Implementing the full spec of IEEE in software is expensive in run time, and hence you might need to take short cuts. These coukd lead to the three different expressions giving slightly different results and not exactly the same.

Often enough floating point allows you to express the same number in different ways, non-normalized. In IEEE as example there is two zeroes, +0 and -0 which affects some results despite both beeing zero. In a given c float implementation you might elect to allow a float value to show itself as non-normalized. Or you might elect to trade off a bit of precision for more speed.

The whole point is to know your tools and accept that c does not always work exactly as mathematics.

 

[gnasher729]

Thanks for taking the time to post your helpful answers. You both make excellent points in this regard. I hadn't ever considered the point that the order of operation of C isn't always immediately obvious, and that code that prevents someone else from having to double-check what happens first is more friendly and readable (especially for people less experienced with C).

If you write something like

double x = (double) 3 / 4;

there are three questions: What does the code do, what did the author think it would do, and are the two the same? No matter how much experience you have, it doesn't help with questions two and three. And since there are ways to express the intent much less ambigous, either

double x = (double) (3 / 4);

which is a bit unusual but quite clear, or

double x = 3.0 / 4.0;

, I don't even care to learn what the original code does.

double x = 3 / (double) 4;

is also quite clear.

 

[GorillaPaws]

If you write something like

double x = (double) 3 / 4;

there are three questions: What does the code do, what did the author think it would do, and are the two the same? No matter how much experience you have, it doesn't help with questions two and three.

This is another excellent point. Thanks for sharing your wisdom. I truly appreciate it.

 

[subsonix]

And since there are ways to express the intent much less ambigous, either

double x = (double) (3 / 4);

In the context of this discussion I would still question the intent with that code. It's less ambiguous but x will be 0 here since (3/4) is done first and the result is cast to double, 0.0. I would then question if the author intended

double x = (double) 3/4;

since casting the result of the integer division is pointless.