Parsing errors with a large number of fractional digits

[mpfaff]

Decimal.parse gives incorrect results with some numbers with a large number of fractional digits.

Here are some examples:

println!("{}", Decimal::from_str(".00000000000000000000000000001").unwrap());
//1

println!("{}", Decimal::from_str(".10000000000000000000000000000").unwrap());
//10000000000000000000000000000

I think this has something to do with the absence of a 0 before the decimal point because when one is present this issue does not occur (as far as my testing has found).

[paupino]

Decimal doesn't have a parse function, however I believe you're using from_str so I'll answer from that perspective.

Good news: this should be fixed in master as part of #456! I'll likely release version 1.20 sometime this week which will include this fix.

e.g. On master this passes:

assert_eq!(Decimal::from_str(".00000000000000000000000000001").unwrap().to_string(), "0.0000000000000000000000000000");
assert_eq!(Decimal::from_str(".10000000000000000000000000000").unwrap().to_string(), "0.1000000000000000000000000000");

Version 1.19 currently fails on these tests returning 1 for the first result.

[mpfaff]

Decimal doesn't have a parse function, however I believe you're using from_str so I'll answer from that perspective.

Yes, my mistake.

[mpfaff]

Perhaps I should open a new issue for this but is it intended that 0.1000000000000000000000000000 is printed instead of just 0.1?

[paupino]

The generation of all of the extra 0s is in fact purposeful - in this particular case it shows that it parsed the number with 28 decimals of precision. This is consistent with the .NET library which admittedly was a heavy inspiration early on: https://dotnetfiddle.net/dpicFO

[paupino]

This should now be formally resolved with the release of 1.20 - tests to confirm that are here:

rust-decimal/tests/decimal_tests.rs

Lines 2896 to 2897 in 6d4c894

	(".00000000000000000000000000001", "0.0000000000000000000000000000"),
	(".10000000000000000000000000000", "0.1000000000000000000000000000"),

.