[BUG] Calculator/InputAmount uses double precision and produces decimal arithmetic errors #768

Bug Description

The transaction amount calculator/input flow uses double-based arithmetic for InputValue, which causes binary floating-point precision errors for common decimal values.

Observed examples:

• 0.1 + 0.2 displays as 0.3000000
• 2.1 + 2.2 displays as 4.3000000
• 10 / 3 displays as 3.33333333

These results are not consistent with expected decimal money math and produce visibly incorrect output in the calculator and amount input sheet.

Relevant implementation:

double get currentAmount =>
    (wholePart + (decimalPart * math.pow(10.0, -decimalLength).toDouble())) *
    (isNegative ? -1 : 1);

factory InputValue.fromDouble(
  double value, {
    int maxNumberOfDecimals = _defaultMaxNumberOfDecimals,
  }) {
    if (value.isInfinite || value.isNaN || value == 0) return zero;

    final int wholePart = value.abs().truncate();

    String rawDecimal = value.toString().split(".").last;

    if (rawDecimal.length > maxNumberOfDecimals) {
      rawDecimal = rawDecimal.substring(0, maxNumberOfDecimals);
    }

    final int decimalPart = int.tryParse(rawDecimal) ?? 0;
    // ...
  }

InputValue add(
  InputValue other, {
    int maxNumberOfDecimals = _defaultMaxNumberOfDecimals,
  }) => InputValue.fromDouble(
    currentAmount + other.currentAmount,
    maxNumberOfDecimals: maxNumberOfDecimals,
  );

The same pattern is used for subtraction, multiplication, and division. Because double cannot represent many decimal fractions exactly, floating-point artifacts are introduced and later converted back into the app’s amount representation.

How to Reproduce

1. Open the transaction amount input sheet or calculator.
2. Enter one of the following calculations:
   • 0.1 + 0.2
   • 2.1 + 2.2
   • 10 / 3
3. Observe that the displayed result contains floating-point artifacts or incorrect precision.
4. Compare the result against expected decimal money arithmetic.

Expected Behavior

Amount calculations should use decimal-accurate arithmetic rather than binary floating-point math.

Example expected results:

• 0.1 + 0.2 should display as 0.3 (or 0.30 depending on display formatting)
• 2.1 + 2.2 should display as 4.3
• Division should follow the app's configured precision and rounding rules without producing floating-point artifacts

For money and calculator input, decimal-safe arithmetic is required.

Operating System

Android

Flow version (version+build number)

0.24.0

Screenshots

Additional Context

This is fundamentally a precision bug in the amount calculator implementation. The root cause is the use of double for money-like decimal arithmetic. That is not suitable for currency calculations because many decimal numbers cannot be represented exactly in binary floating-point.

The recommended fix is to replace the core arithmetic with a decimal-safe implementation, ideally using package:decimal. That would provide precise decimal operations and predictable rounding behavior.

Suggested follow-up:

• Replace double-based math in InputValue with Decimal
• Convert InputValue <-> Decimal at the boundaries
• Add unit tests covering:
  • 0.1 + 0.2 == 0.3
  • 2.1 + 2.2 == 4.3
  • division with configured precision/rounding
  • chained operations and edge cases

A short-term alternative would be a fixed-point integer implementation, but package:decimal is the cleaner and safer long-term fix for money precision.