I think you should re-read that article you sent out, as it describes a different situation as the one presented here. It's kind of a frequent misconception am

I think you should re-read that article you sent out, as it describes a different situation as the one presented here. It's kind of a frequent misconception among kind-of-informed programmers that floating points are always "inaccurate" without fully understanding why. Your linked article is mostly describing floating point arithmetic where due to various reasons (order of operations, etc) it's hard to compare arithmetic results due to precision loss. In this case though, you have a float assigned to a constant (1.3f) that is then compared with 1.3f again. There is no arithmetic done, and in fact, 1.3f has a non-ambiguous binary representation (it's the binary float point number that's closest to 1.3, a decimal number). Doing something along the lines of "1.3f == 1.3f" should always return true. The issue here is just the annoying issue of intermediate 80-bit representation vs 32-bit storage which isn't an intrinsic issue of floating point, but rather a language/platform oddity. As the article described this isn't actually an issue under x86-64 since compiled code don't use 80-bit intermediate representation there. Another similar issue is reading/printing float point numbers out. It's a tricky thing to do, but there are lots of research done on it (e.g. see "dtoa" by David Gay) such that you can actually accurately print out floating point numbers and read them back and get the same binary representation.