Floating Point Error – Issues in Representation

The do give the expected results. Your expectations are incorrect.

When you type the double-precision literal 2.14656, what you actually get is the closest double-precision value, which is:

2.14656000000000002359001882723532617092132568359375

the println happens to round this when it prints it out (to 17 significant digits), so you see the nice value that you expect.

After the modulus operation (which is exact), the value is:

0.14656000000000002359001882723532617092132568359375

Again, this is rounded when it gets printed, but because there is one less leading digit, the round point is one digit farther to the right, and so you see that trailing 2.

SHOULD fv be equal to original_value exactly? Any precision may be lost?

Yes, if the value of dv did not change in between.

From section Conversion 6.3.1.5 Real Floating types in C99 specs:

1. When a float is promoted to double or long double, or a double is promoted to long double, its value is unchanged.
2. When a double is demoted to float, a long double is demoted to double or float, or a value being represented in greater precision and range than required by its semantic type (see 6.3.1.8) is explicitly converted to its semantic type, if the value being converted can be represented exactly in the new type, it is unchanged. If the value being converted is in the range of values that can be represented but cannot be represented exactly, the result is either the nearest higher or nearest lower representable value, chosen in an implementation-defined manner. If the value being converted is outside the range of values that can be represented, the behavior is undefined

For C++, from section 4.6 aka conv.fpprom (draft used: n337 and I believe similar lines are available in final specs)

A prvalue of type float can be converted to a prvalue of type double. The value is unchanged. This conversion is called floating point promotion.

And section 4.8 aka conv.double

A prvalue of floating point type can be converted to a prvalue of another floating point type. If the source value can be exactly represented in the destination type, the result of the conversion is that exact representation. If the source value is between two adjacent destination values, the result of the conversion is an implementation-defined choice of either of those values. Otherwise, the behavior is undefined. The conversions allowed as floating point promotions are excluded from the set of floating point conversions

So the values should be equal exactly.