2.13.1

This version adds the possibility to specify the rounding method for multiply() and divide(), and also fixes a bug with the divideAndRound() function when the divisor is negative.

More details from @gidonkatten’s PR (see #13):

The default behaviour for the multiply and divide operations was to ROUND_HALF. Added the possibility to specify whether to ROUND_UP or ROUND_DOWN. Rounding down is especially important as that is the typical behaviour in smart contract opcodes (EVM and non-EVM alike).

Also fixed a bug in the divideAndRound function (which is called by many operations) when the divisor is negative. E.g. divideAndRound(-15n, 2n)) and divideAndRound(15n, -2n) yielded different results.

Thanks @gidonkatten 🙏

2.12.0

This version fixes the typing of toNumber() and toString() by allowing their second parameter to be optional, in line with their behavior and documentation.

See #12 for details.

Thanks @nbran 🙏

2.11.0

This version exports the Numberish type.

See #9 for details.

Thanks @desoss 🙏

2.10.0

This version fixes an issue where projects using Node16 or NodeNext moduleResolution in their TypeScript projects were not able to resolve the types.

See #7 for details.

Thanks @ryangoree!

2.9.0

This version adds toString(), which works like toNumber():

let value = [123456789000000000000000n, 18];

toString(value); // "123456.789"
toString(value, 1); // "123456.8"

Thanks to @DannyDelott for suggesting this! 🙏

2.8.1

API changes:

• format(): now has a signDisplay option, which allows to control how to display the sign for the number. It follows the same rules as the Intl.NumberFormat() signDisplay option.

Bug fixes:

• Fixes an issue with the format() function where the sign was missing from negative numbers with a whole part equal to 0.

Internal changes:

• formatSign(): (internal) returns a number sign.
• toParts(): (internal) the whole part is now always positive. This is to make its behavior consistent: before this change, the sign was only removed when the value of the whole part was 0.

2.7.0

dnum now tolerates numbers that convert into strings using the exponential notation, thanks to from-exponential.

This change goes in the opposite direction than 2.6.1 regarding how numbers with precision loss are handled. The reasoning is that using Number is always prone to precision loss no matter what, and strings or bigints should be preferred to avoid such issues.

dnum.from(10 ** 21)

// 2.6.1 throws:  "The passed number lost its precision: 1e+21. Please use a string, BigInt or Dnum value instead."
// 2.7.0 returns [1000000000000000000000n, 0)

Thanks to @greg-schrammel 🤗

2.6.1

This version adds a specific error message when the passed number gets converted to the scientific notation, making it lose its precision. Thanks @greg-schrammel for spotting this 🙏

dnum.from(10 ** 21)

// Error before 2.6.1: "Incorrect number: 1e+21."
// Error since 2.6.1:  "The passed number lost its precision: 1e+21. Please use a string, BigInt or Dnum value instead."

2.6.0

This version fixes a bug where compare() could return incorrect values.

It also adds the cmp() alias for compare().

2.5.0

With this release, trailingZeros + digits take precedence over the number of decimals, even when digits > decimals.

See #2 (comment) for more details.

Thanks @devnomic 🙏