never store currency in a float

Another one of those oft-ignored rules for safe programming. You have a program that works in dollars and cents, say. The most natural mapping of the world to your program's variables is to store dollars in real numbers. So it would seem you'd want stuff like this:

  double price = 0.10;      /* Price is 10 cents */

But it's probably an academic issue anyway. And just in case it isn't, we're storing it in double precision. Let's just write the rest of a loop to check it, shall we?

  double sum;
  int i;

  for(i=0; i<100000; i++)
    sum += price;

When you're doing computations on money, you literally can't afford to lose money in the cracks in your program. And this is precisely what happens if you use floating point math to keep track of money.

The solutions exist and are well known. Pick one:

1. Use BCD floating point, or some other decimal floating point representation. This can accurately represent any decimal fraction, so you don't lose money. Mainframes often support decimal floating point in hardware; "modern" machines don't, but it's possible to build (or buy!) a library and use it.

   But you can still lose money due to cancellation when your calculation involves more digits that the accuracy of your representation.

2. Use some integer representation to count cents (or ha'pennies, if using). You still have to make sure you write 2 digits to the right of the decimal point (the integer division and modulo operations are your friends here), but you know you're not losing small sums.

   You still have to make sure your integers are large enough to hold any sum you may have in your calculations. Or you can use a bigint package. This can be really simple, as you're never going to multiply 2 bigints (since typically only money needs to be a bigint), and in any case your bigints are quite small (32 digits are far more than enough for any sums of money...).