Hi!

What is exactly what one would expect.

The reason is simply that most floats cannot be precisely
represented as binary floats. They will always be represented by the
nearest float that can.
Floating point operations on binary hardware are always approximations.
If you need precision, use integer arithmetics.

Regards,

    Phil

The short answer is what Phil said.

The long answer:

<http://docs.sun.com/source/806-3568/ncg_goldberg.html>

If you are in a loop, where you will be increasing or decreasing a
number by a fixed step size, a better method is to retain the initial
number (e0 = 1.0), and the number of iterations (n = 2), and subtract the step
size (delta = 0.05) times the number of iterations from the original number:

e = e0 - n*delta;

Instead of

e -= delta;

You will still have truncation error, but it will not be cumulative - you
start off fresh with each iteration.

- Kurt

The reason is that your teacher is incompetent. You should sue for fraud
and breach of contract.

If you are not learning from a teacher, your textbook is incompetently
written. Burn it and get another.

If it weren't for machine arithmetics, I'd have expected 0.9,
not 0.85 , after subtracting twice 0.05 from 1.0   :-)

Anyway,  if you always subtract steps of 0.05, you had better
start with an   int e=100;  and  subtract 5 from that.
where you need the floating point value, you just divide
e/100.0   ( don't forget the .0 to 100, or you'll get integer
division)