Why Float Should Not Be Used for Storing Monetary Values and Better Alternatives

A company building a trading system initially considered using float to store monetary amounts, but discovered that floating‑point arithmetic is approximate and can cause financial loss.

Why float Cannot Be Used for Storing Money

Example code FloatTest.java shows the problem:

public class FloatTest {
    public static void main(String[] args) {
        float f1 = 6.6f;
        float f2 = 1.3f;
        System.out.println(f1 + f2);
    }
}

Output: 7.8999996 , which differs from the exact sum 7.9 .

Computers perform calculations in binary, so every numeric type is first converted to a binary representation.

Binary Calculation of 6.6 + 1.3

Float Underlying Storage

A 32‑bit float consists of a sign bit, an 8‑bit exponent, and a 23‑bit fraction (mantissa).

Binary Conversion

Real numbers are split into an integer part and a fractional part. The integer part is converted to binary in the usual way.

Integer Part: Converting 6 to Binary

Divide by 2

Result

Remainder

6

3

0

3

1

1

1

0

1

Thus 6 becomes 110 in binary.

Fractional Part Conversion

Repeatedly multiply the fraction by 2, taking the integer part as the next binary digit.

Converting 0.6 to Binary

Multiply by 2

Integer Part

New Fraction

0.6 × 2 = 1.2

1

0.2

0.2 × 2 = 0.4

0

0.4

0.4 × 2 = 0.8

0

0.8

0.8 × 2 = 1.6

1

0.6

0.6 × 2 = 1.2

1

0.2

The pattern repeats, giving 0.6 = 0.10011001… and therefore 6.6 = 110.10011001… .

Normalization

Binary numbers are normalized to have a single leading 1 : 1.1010011001 × 2^2 for 6.6 .

Exponent Bias

Bias = 127 (for 8‑bit exponent) + actual exponent. For 6.6 , exponent = 2, so bias = 129 = 10000001 in binary.

Assembling the Float Representation of 6.6

Sign = 0, exponent = 10000001 , mantissa = first 23 bits of the fraction 10100110011001100110011 . The final 32‑bit pattern is 01000000110100110011001100110011 , showing the inherent precision loss.

Summation

Because the mantissa is truncated, adding 6.6 and 1.3 with float yields 7.8999996 instead of the exact 7.9 .

What Types Should Be Used Instead?

Store the amount as an int representing cents, converting to yuan only for display.

Use MySQL DECIMAL(P,D) where P is total precision and D is scale.

column_name decimal(P,D);

Example table creation:

CREATE TABLE `test_decimal` (
  `id` int(11) NOT NULL,
  `amount` decimal(10,2) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

DAO layer (MyBatis) example:

@Repository
public interface TestDecimalDao {
    @Select("select * from test_decimal where id = #{id}")
    TestDecimal getTestDecimal(int id);
}

Test class:

public class TestDecimalDaoTest extends BaseTest {
    @Resource
    private TestDecimalDao testDecimalDao;

    @Test
    public void test() {
        TestDecimal d1 = testDecimalDao.getTestDecimal(1);
        TestDecimal d2 = testDecimalDao.getTestDecimal(2);
        BigDecimal result = d1.getAmount().add(d2.getAmount());
        System.out.println(result.floatValue());
    }
}

The output matches the expected sum 7.9 .

Disadvantages of DECIMAL

Consumes more storage space than floating‑point types for the same range.

Computation with DECIMAL is slower.

Therefore, for most monetary data, using an int (or bigint for larger ranges) to store the smallest currency unit is a more efficient and precise solution.