Goldberg's What Every Computer Scientist Should Know About Floating-Point Arithmetic is a must read and must understand for every software engineer.

Also, it may be useful to read the relevant chapters of the Knuth's The Art of Computer Programming. It may be a bit dense for understanding, but it's good.

It's worth to note that besides the clear difference between the numeric models we learn in school and models employed in our computers, there's yet another one, specific to the design of programming languages...

Let's look at the basic C/C++'s problems with math, the problems with which plagued an incredible amount of existing software.

1. Signed types get promoted to unsigned where necessary and unnecessary. The following condition is always false (it evaluates to 0):
1U -1
Yeah, nice, +1 isn't greater than -1. This is totally brain dead.
Although usually it's not cheap to compare signed and unsigned values, it's possible and I see no point in making the programmer do it in convoluted ways, which he very often (usually?) doesn't for one reason or another (laziness or ignorance) and ends up with a code bug.

2. Suppose our int is 16-bit long and our long is longer than that. Then the following condition is always false as well:
32767 + 1 == 32768
Sweet.
That's because the nums on the LHS will be ints, but the num on the RHS will be long per the language design. And per that same simplistic design there's no provision to avoid the overflow on the LHS when moving it into an lvalue (or comparing it with rvalue) that has more bits, where the overflow will become apparent and likely unwanted.

3. The following is false as well, also due to signed-unsigned conversion:
(-3) % 3U == 0
I'd love to see this produce mathematically more expected results at the expense of extra CPU cycles. Too bad it's not so.

4. Assuming 16-bit ints, the following will be false:
32767 * 2 == 65534
But these will be true:
32767L * 2 == 65534
32767U * 2 == 65534
It is obvious that the product of two 16-bit ints is gonna need 32 bits of storage. It is brain-dead to require the programmer to instruct the compiler to produce the full product and not just the least significant half of its bits or do some other trickery. It's easy to make a mistake here and forget an explicit type conversion to long of one of the multiplicands.

5. The following is also false:
-2 + 1U + 1.0 == -2 + 1.0 + 1U
(A+B)+C is no longer the same as (A+C)+B. Now, that's nice, broken commutativity!

6. Again, assuming 16-bit ints, shifts by 16 or more positions left or right are undefined per the design and in practice you get some funny results as if the shifts were done by count % 16. It would be natural to produce 0 with right shifts by 16 or more (assuming, we're talking unsigned ints, it's a different thing with signed ints) and I'd be OK to get a 0 (or anything defined, e.g. UINT_MAX) when doing the same in the other direction.

Basically, the problem is, in C/C++ a lot of what you learned about arithmetic is no longer true, not just the rational (AKA floating point) numbers. That is, you can't just use whatever you learned at school. You must learn the way the language does the math and you must write your code accordingly, adapting your ideal-world ideas to the brutality of the real computing. C's arithmetic expressions look familiar and seem to make sense to anybody understanding math, but make no mistake, behind this faÁade hides a great deception.

It's possible to explain in part why C/C++ is so goddamn math unfriendly. It's basically a generalized assembler language which must be quite primitive so it's easy to compile it and transform into comparable and primitive instructions of the target CPU. For instance, very few CPUs have comparison and division of a signed and unsigned operand. It is uncommon for CPUs to support shift counts larger than the register size in bits. It's possible to construct such operations, but nobody bothered to back when C was being designed and now it's too late.

Every C/C++ programmer has to learn this the hard way and figure out a way to do in C what an ideal (or almost so) calculator would do w/o any surprises.

For a long time I actually found programming in assembly more transparent and giving more expected results than programming in C. In part I attribute it to the difference between the two: when you learn an assembly language you have to open the CPU manual to see what registers and instructions are there and how they work. In C you don't seem to need to learn how + or * or == work, because they're familiar and you intuitively know how to use them. Unfortunately, these are wrong expectations and assumptions, and wrong expectations and assumptions rarely work well in software engineering. What helps in the case of C/C++ is reading and understanding the language standard. The standard isn't an easy reader. Many usually end up buying books on C/C++. These days there're titles that cover the issues well. But I remember the days when C/C++ books covered this poorly or ignored the topic almost entirely. I hated them and only finally got everything straight in my head when I'd made every possible mistake and written a sufficient amount of very portable C code.

Btw, last time I checked, the C standard was available online for the mere $18 (cheaper than a book on C/C++ you'll pick at your local bookstore). Not knowing how to use your tools correctly is not just bad, it's very bad and wrong. At the same time I wish C/C++ never existed in its current form -- it could've been done better.

@the old rang:

I hate to sound off on that, but it isn't a very simplified way of looking at 0.99999... vs. 1, that's a wrong way of looking at 0.99999... vs. 1. Because the point is that they are literally the same number expressed in two different ways. Not so close as makes no difference, but the exact same number.

I'm an engineer. I know intimately close enough as makes no difference.