[sasmithjr]

A decimal built from a number or a string with a nonzero value whose magnitude is below 0.1 rounds at the wrong place:

Expression	.NET	Fable before
Math.Floor(decimal -0.0836)	-1	-0.1
Math.Floor(Decimal.Parse "-0.0000123")	-1	-0.0001
Math.Ceiling(decimal 0.0836)	1	0.1
Math.Round(decimal 0.06)	0	0.1
Math.Round(decimal 0.0836, 2)	0.08	0.084

Decimal literals and arithmetic results aren't affected: Math.Floor(0M - 0.0836M) is -1.

Cause

parse() in lib/big.js strips leading zeros only before the decimal point, so that zero keeps its scale (0.00). For a nonzero value whose magnitude is below 0.1 this also keeps the zeros after the point: -0.0836 is stored as c = [0,8,3,6], e = -1 instead of c = [8,3,6], e = -2. P.round works out where to round from this.e, but rounds a copy, and the copy constructor normalizes. So the precision calculation uses a different exponent from the value being rounded. #4962 fixed the formatting side of the same representation, and 1c02557 worked around it in toFixed.

The same representation made GetHashCode differ between equal decimals, since it hashes c and e directly. As a result, HashSet<decimal> and Dictionary<decimal, _> treated decimal -0.0836 and 0M - 0.0836M as different keys.

Fix

After parse()'s existing rounding step, normalize the value when it has a nonzero digit. Zero is left as is, so 0.00 still keeps its scale. The rounding to Big.DP + 1 digits happens before the normalization, so precision is unchanged.

Testing

• Two test cases in tests/Js/Main/ArithmeticTests.fs: rounding below 0.1 (for decimals from doubles, strings and literals), and hash consistency (GetHashCode, HashSet, Dictionary). Both fail without the fix and pass with it. They also pass on .NET.
• The JavaScript and TypeScript suites pass.

🤖 Generated with Claude Code