Custom decimal places for specific calculations

[rigelrozanski]

There are some funny rounding errors within distribution (see #4389 (comment))
which are due to inability for two mechanisms to have compatible rounding. If, for the duration of this calculation, we were able to increase the number of decimal places, the rounding inconsistencies should be eliminated.

This would require the ability to initialize a decimal with a custom number of decimal places, and then to convert that decimal to another type decimal with a different number of decimal places when the high-precision calculation was complete.

CC @ValarDragon @cwgoes @alexanderbez

[alexanderbez]

So essentially supporting both arbitrary and fixed precision decimals and being able to go from one to another and also perform calculations on one another?

[rigelrozanski]

Almost, I'm referring to supporting only fixed precision decimals, but allowing custom arbitrary fixed precision to be defined for short-term use (and all the conversions back and forth to be streamlined).

I think we probably want to keep existing more or less decimal as is, but then introduce a flexible decimal type which can interact with the existing decimal type. (obviously we'd want to abstract all common stuff between the two however)

[alexanderbez]

Makes sense 👍

[cwgoes]

This seems like it would work. I wonder if another option is to chain the sequence of multiplications / divisions (which at least in F1 happens all in the same transaction, if we're talking about the same case), treat the number as an arbitrary-precision (but fixed-size, since the inputs were fixed-precision) rational for the duration of the calculation, multiplying the numerator or denominator as integers appropriately, then convert back into a fixed-precision decimal (with a specified rounding direction) at the end.

[rigelrozanski]

So we could use rationals, however the computations can get quite expensive depending on how complex the rationals compound. Back in the day, when we switched from general use of rationals to decimals, we had an enormous performance boost, of course, those rationals were getting quite complex as they would grow in complexity over the blocks... It's not as extreme here because the rationals would be rounded at each transaction, however, they still would grow in complexity over each period within the F1 calculation. All in all, I don't see the advantages of rationals over simply using a few more decimal points to prevent this rounding error (which is it all it would take, Id guess 3 more decimal points would suffice)