Try looking at the output of this instead

    double totalCost = 3.91, amountPaid = 4.00;
        double totalChange;

        totalChange = ((amountPaid - totalCost) * 100);
        System.out.println(totalChange);

You'll see it isn't 9, and the cast to int truncates it to 8, as you
were seeing originally.

The problem is that you can't use floating point arithmetic (doubles) to
do precise arithmetic. If possible then you should try using fixed point
arithmetic. e.g.

    int totalCost = 391, amountPaid = 400;
    int totalChange;

    totalChange = amountPaid - totalCost;
    System.out.println(totalChange);

James

Never ever perform money calculation using floating point.
First solution : use BigDecimal and BigInteger (which are slower, as
mentioned before).
Second solution (used in all our banking applications) : specify the
amounts in "smallest currency unit" (cents for $, pence for pounds), and
associate a "small unit number" with each currency (if you need to
manage several currencies), which specifies the number of small units
needed for GUI.
For instance, for $, calculations are made in cents, and display is done
with amount/100 $  and amount%100 cents (small unit number = 2)

As has been said, this is due to roundoff error.

If you want to know *why* roundoff error occurs, it helps to know how
primitive floating-point numbers are stored internally.  Skipping over
the details, the numbers in your example are stored with the following
bit patterns (shown in hex):

          s exp mantissa
   3.91   0 400 F47AE147AE148
   4.0    0 401 0000000000000

Notice that 3.91 can't be represented exactly.  The mantissa is a
repeating fraction, with repeating part 47AE1 that's rounded up at the
end to 48.  The internal version of the number is slightly larger than
3.91.

There is no infallible way to deal with this error, since numbers must
always be stored with a finite number of bits.  How you deal with it
depends on what you're trying to do.

Financial programs usually adhere to a set of conventions that ensure
that a calculation is *fair*, in the sense that it's always done in the
same way.  But this isn't always the same as *accurate*.  Credit card
companies and gas stations will always round up, for example.

Storing money amounts in smaller units (e.g. cents or mils instead of
dollars) hides the problem for addition and subtraction, but not for
anything more complicated (compound interest or statistical analysis).

BigDecimal is overkill unless you need more than 15 decimal digits of
precision.  It's also extremely limited.  There's no pow() method, for
example, so no interest calculations.  And the scaling and rounding of
BigDecimals isn't really any easier or less error-prone than the correct
use of primitive floating-point types.

- Ernie                                  http://home.comcast.net/~erniew