I noticed Ecotale represents money using double. That’s risky long-term because double is binary floating-point, so many decimal values (like 0.01 / 0.1) can’t be represented exactly. Over time, rounding errors accumulate and you can get drifting balances (cents “disappearing” or “appearing”), inconsistent calculations, or checks like balance >= price failing unexpectedly. With lots of transactions, taxes, discounts, or interest, this becomes a real integrity problem.
Best practice for currency is usually:
long in minor units (e.g., cents) and only format to decimals for display, or
BigDecimal (and DECIMAL in DB) with a fixed scale and explicit rounding rules
Would you be willing to change this (or add an optional mode with a migration path) to long/BigDecimal?
Thanks
I noticed Ecotale represents money using double. That’s risky long-term because double is binary floating-point, so many decimal values (like 0.01 / 0.1) can’t be represented exactly. Over time, rounding errors accumulate and you can get drifting balances (cents “disappearing” or “appearing”), inconsistent calculations, or checks like balance >= price failing unexpectedly. With lots of transactions, taxes, discounts, or interest, this becomes a real integrity problem.
Best practice for currency is usually:
long in minor units (e.g., cents) and only format to decimals for display, or
BigDecimal (and DECIMAL in DB) with a fixed scale and explicit rounding rules
Would you be willing to change this (or add an optional mode with a migration path) to long/BigDecimal?
Thanks