Stephen Chung

https://github.com/paupino/rust-decimal/blob/master/src/maths.rs#L316-L323 This is where it calculates the `pow` by converting it into `exp`, and this may be the place where it overflows. Since you know the exponent will be

Mul overflows because you have too many significant digits. You can avoid it by trimming down the number of digits.

We can also use different algorithms for different ranges of inputs, picking the best one depending on the actual input values.

> I tried the "normalizing" approach mentioned above (basically, calling `term.normalize_assign()` before / after `checked_mul`) to no avail. You'd need to normalize to a precision that `checked_mul` no longer overflows/underflows.

Since none of the trig functions necessarily maintain precision (or have perfect precision in the first place), it really might actually be better to first convert the `Decimal` to `f64`,...

Yes, IMHO features is one huge mess in Rust right now... It gets worse exponentially when you start having more.

This only ever happens when printing the actual result, and Rust has different formatting rules on displaying arbitrary-length decimal digits (i.e. stopping at the last infinite stream of zeros) vs....

That won't be JSON though... JSON is designed to be plug-in compatible with JavaScript hash object format, and JavaScript always takes a period `.` as decimal delimiter. That would be...

I suppose if we always lose the last digit then we'd be avoiding all the rounding errors... I suspect other libraries might simply restrict the max. number of significant digits...

I may say, if the library only guarantees 28 digits of precision, we should always round the result to 28 digits. The `3.0000000000000000000000000003` in the example above has 29 digits,...