[Bug]: toUnit can't be accurate when used with big integers

[sarahdayan]

Is there an existing issue for this?

• I have searched the existing issues

Current behavior

Function toUnit currently returns a number, whatever the amount type is.

// ...
const d1 = dinero({ amount: 4545, currency: USD });
const d2 = dineroBigint({ amount: 4545n, currency: USD });
const d3 = dineroBigjs({ amount: new Big(4545), currency: USD });

toUnit(d1); // 45.45
toUnit(d2); // 45.45
toUnit(d3); // 45.45

To do so, Dinero.js uses the toNumber function exposed on the calculator to cast the generic amount into a number, then retrieve the unit format and return it.

The problem is that number isn't always fit to represent the unit format accurately.

For example, if the user has one of the following objects to represent amount $ 10000000000000000.50:

// ...

const d = dineroBigint({ amount: 1000000000000000050n, currency: USD });
const d = dineroBigjs({ amount: new Big(1000000000000000050n), currency: USD });

Then toUnit can't format it correctly because this number can't be safely casted into a number.

A side-effect is that this inaccurate number is passed on to toFormat, which transformer function uses toUnit to expose the pre-formatted amount.

Expected behavior

The function toUnit should return an accurate amount.

Steps to reproduce

https://codesandbox.io/s/fervent-paper-flsvt?file=/main.js

Version

v2.0.0-alpha.6

Environment

All environments

Code of Conduct

• I agree to follow this project's Code of Conduct

[sarahdayan]

The solution that appears the best to me right now is to stop relying on a decimal notation (whether it's a float or a stringified float) and instead use a data structure such as an object or a tuple that splits between the major and minor part. For example, for the following object:

const d = dinero({ amount: 4555, currency: USD });

Instead of returning 45.55, toUnit would return [45, 55] or { major: 45, minor: 55 }.

The reasoning is that, beyond IEEE 754 inaccuracies with floats that can't be represented accurately within 64 bits, the decimal notation is purely a formatting concept. In the context of Dinero.js, it's a flawed one because it assumes everything is base 10, while Dinero.js supports different bases. The results are accurately converted to base 10 (e.g., 9 obols (ancient drachma, base 6) are by default returned as 1.5) but this doesn't make sense from the beginning to pick such a representation. The decimal representation is common, but it isn't a domain concept that has authority over all possible monetary values.

With a tuple or object, users get an accurate representation of the major/minor split. They're free to represent them the way they want afterwards.

Questions

Moving towards returning such a representation raises questions:

• What data structure should it use? A plain object/tuple? A value object?
• Rounding modes are coupled to numbers right now because they happen in toUnit (which currently returns numbers). Should they be re-evaluated for generic usage? Do they make sense with non-decimal currencies? Do they only make sense on floats? Does they make sense in toUnit? Should they apply when transforming to a smaller scale instead?
• If users can see different unit levels, should they be able to provide intermediary bases (e.g., when dealing with currencies with multiple subdivisions, such as the old British pound)?
• Should there be a "data structure to stringified float" helper to ease the usage in toFormat, given that the most common usage will still be decimal currencies? Should the data structure expose it directly for convenience (e.g., x.toString())?