Nature of the number format doesn't allow for certain numbers to be exact. Ignoring the exponent and sign bits of a float or double and just look at the bits for the actual number (sign and exponent are integer like so nothing fancy there.) So lets say in the case of 3; or for just the number .3 since 3, 30, 300, .03 is just a power of .3; how will it be encoded in the float/double. (Note there is a slight difference between how a float and double are encoded but in general the idea is the same.)

For integers each bit is a power of 2
Bit Value
1 2
2 4
3 8
...
N 2^N

To get the total value of the int you add them up. Similarly with floats but the values are represented differently.

Bit Value
1 1/2
2 1/4
3 1/8
...
N 1/N^2

So (first number is bit value) .3 = 0*1/2 + 1*1/4 + 0*1/8 + 0*1/16 + 1*1/32 + 1*1/64 ... In the end the value is very very near to .3 but may end up being actually .299999[some numbers] or .300000[some numbers]. This also can add to some grief because you may have a threshold or precalculated number, that is very accurate, and you compare that with a nasty calculation which may be less accurate due to the earlier point about precision and or other calculations that continue to propagate the errors of numbers that can't be exactly represented and the two numbers may be a bit off. This is where you may end up adding some fuzzy logic to say, eehh, close enough.

E.G.:
/* This will fail at times.*/
if (doubleValue == 0) {...}
/* This will be a bit better.*/
if (FABS(doubleValue) < SOME_SMALL_DOUBLE_CLOSE_TO_ZERO) {...}

Also when converting to an integer, you need to be aware that 2.9999 will translate to 2 while 3.00001 will translate to 3. You may need to do some rounding to get the right 'integer' value from the float/double.

Weee, fun with floating point types.