toNumber(places?: number)

[stevenvachon]

I think this would reduce this redundant pattern:

const fixedPrecision = FixedPrecision.create({ places: 20 });

Number(fixedPrecision(0.123).mul(4).toFixed(4));

[naoeosavio]

I don't think using .toFixed() is the most correct approach here, since it introduces formatting/stringification semantics.

The expected behavior would be closer to:

x.toNumber(4)

being sugar for something like:

x.round(4).toNumber()

or:

x.scale(4).toNumber()

depending on the intended semantics.

Right now the library separates these concepts:

• scale(places) → rounds to N decimal places and updates the internal scale/context to the new precision.
• round(dp) → rounds to N decimal places while preserving the original context.

So toNumber(4) should probably delegate to one of those operations internally instead of relying on .toFixed(), which is more of a serialization/formatting operation.

[stevenvachon]

😯🤯 Thanks!

[stevenvachon]

Hmm, is this a bug?:

const fixedPrecision = FixedPrecision.create({ places: 20 });

Number(fixedPrecision(499.99999999999994).toFixed(4)); //-> 500

fixedPrecision(499.99999999999994).round(4).toNumber(); //-> 499.99999999999994

[naoeosavio]

Not exactly a bug in round(4) itself — the rounding is actually correct.

const r = fixedPrecision(499.99999999999994).round(4);

r.toString();
// "500.00000000000000000000"

r.raw();
// 50000000000000000000000n

So round(4) already produced the correct internal value.

The issue comes from the current toNumber() implementation:

Number(value) / ctx.SCALENUMBER

With places: 20, the raw bigint:

50000000000000000000000n

is larger than Number.MAX_SAFE_INTEGER, so precision is lost during the bigint → number conversion.

That is why:

fixedPrecision(499.99999999999994).round(4).toNumber()

ends up returning:

499.99999999999994

Meanwhile this works:

Number(fixedPrecision(499.99999999999994).toFixed(4))

because JS parses the already-rounded decimal string "500.0000".

Also, using scale(4) would likely avoid the issue as well, because the internal scaled value becomes much smaller before conversion.

So the real issue is that the current toNumber() path is not handling values larger than Number.MAX_SAFE_INTEGER safely enough.

I'll probably adjust toNumber() to perform a safer conversion strategy for large scaled values.