feat: make fixed point flexible

[mustermeiszer]

Description

This is a non breaking change of our fixed point integer logic. It allows to use our logic with variable decimals. This is especially useful for places where we want to reduce the max decimals compared to 27 decimals.

While 27 decimals are great for interest calculation in some place they are limiting to the maximum value that can be represented. I.e. roughly 1 billion in the 27 decimal case.

Changes and Descriptions

• change struct Rate to struct FixedU128<const DIV: u128>
• create type Rate = FixedU128<DECIMAL_27>

Checklist:

• I have added Rust doc comments to structs, enums, traits and functions
• I have made corresponding changes to the documentation
• I have performed a self-review of my code
• I have added tests that prove my fix is effective or that my feature works

[lemunozm]

I like the generalization!

A note about maintaining our fixed_point file: I think this can be a sucurity issue in the way that we are not merging updates in this section from Substrate. What if tomorrow Substrate fixes an issue in the fixed point multiplication or similar? How can we receive these changes and update accordinly? Is there no way to reuse the Substrate FixedU128 type and add the rounding capabilities on top of that type?
Adding traits as extensions or wrapping the FixedU128 from Substrate internally should work.

I mean, I think there is two things here.

1. We need a Rate with 27 decimals for accruing interest. (This could lead to having our own type)
2. We need rounding capabilities. (This not need a new type)

So for a Rate with rounding capabilities with 18 decimals, I think we could use the Substrate FixedU128 because using the FixedPointNumberExtension it inherents to those capabilities.

[lemunozm]

Funny name after rename "rate" 😆

[lemunozm]

Knowing that the purpose of this is accruing rates. I would call it AccrualRate or something similar to denote in its name the purpose and avoid confusion

[lemunozm]

Then, it can be a "normal" Rate, a Ratio, or a simple number with decimals I guess

[lemunozm]

What if I want to hold negative numbers? i.e. Right now, I'm using a FixedI128 for rewards without this rounding capabilities.

[wischli]

Code changes LGTM. Let's hope all tests succeed.

There are bunch of undesired replacements of rate to FixedU128 in the comments, e.g.

• Substrate --> SubstFixedU128.
• Saturates --> ~SatuFixedU128s`

[wischli]

Out of curiosity, where is this expected to be used?

[lemunozm]

When you want to express an absolute number value with decimals. Ratio should represent instead a proportion of a value. Both are represented in the same way and are the same.

Maybe these "aliases" could be moved to our runtime definition, because they are how we are using them.

[mustermeiszer]

I am not keen on moving them now as this means adapting all imports of Rate. Lets do in a follow up if wanted.

[mustermeiszer]

A note about maintaining our fixed_point file: I think this can be a sucurity issue in the way that we are not merging updates in this section from Substrate. What if tomorrow Substrate fixes an issue in the fixed point multiplication or similar? How can we receive these changes and update accordinly? Is there no way to reuse the Substrate FixedU128 type and add the rounding capabilities on top of that type?

I do not think this will be an issue. We are using the core methods which are not provided by the trait but by the arithmetics of Substrate. If they fix something there, we will receive the change.

The problem with rounding is not solvable by that as checked_from_rational and checked_mul_int are the core problems here and we must override them to get the right stuff.

[mustermeiszer]

@wischli and @lemunozm udpated all

[lemunozm]

The problem with rounding is not solvable by that as checked_from_rational and checked_mul_int are the core problems here and we must override them to get the right stuff.

And we could not create a FixedU128(sp_runtime::FixedU128) that implements FixedPointNumber calling the inner fixed rate except for checked_from_rational and checked_mul_int methods where we add our custom logic?

[wischli]

Thanks, LGTM!

[mustermeiszer]

And we could not create a FixedU128(sp_runtime::FixedU128) that implements FixedPointNumber calling the inner fixed rate except for checked_from_rational and checked_mul_int methods where we add our custom logic?

Do not see the advantage. We are essentialy doing just that ^^

[lemunozm]

The advantage I see is we are less error-prone in our code. Instead of adding simple calculations by us, we call the underlying type to do it. But it's true that the layer is quite quite slim 👍🏻, so maybe not needed. Ideally should be Substrate who maintains all this 😞

[lemunozm]

LGTM!