How to modify PRB-Math powu to support more decimal places?

[publiuss]

Hello!

We're looking to implement an EMA in Solidity, which requires us to compute

x^y

where:

• x is a floating point number 0.9 < x < 1
• y is a whole number y < (uint32).max

The powu(...) function is perfect for this.

However, it is limited by 18 decimal precision given that x is limited to a 60.18-decimal fixed-point number.

We are trying to modify the powu(...) function to support x as a 42.36-decimal fixed-point number or a 24.54-decimal fixed-point number (or even make it only decimals).

It appears that we can change the number of decimals by modifying the constants here, the constants being SCALE, SCALE_LPOTD and SCALE_INVERSE.

1. Will changing these three variables successfully change the number of decimals in the powu(...) function?
2. If so, how can we compute SCALE_LPOTD and SCALE_INVERSE given SCALE?
3. Are there any gas considerations we should consider when modifying the number of decimals?
4. Given we know x < 1, is there an alternative power function we should use?

Appreciate any help in advance.

[PaulRBerg]

Hello @publiuss, I'm glad that you find my implementation of powu function useful.

1. Unfortunately, I first wrote PRBMath in 2021, and so I can't remember all the places where I assumed that I'm working with 18 decimals exclusively. I really don't know if changing those constants would be enough.
2. Have you seen the NatSpec for those constants? Here they are: SCALE_LPOTD and SCALE_INVERSE.
   • In my case, SCALE_LPOTD is 262144 because that is the largest power of two that divides 1e18
   • It might also be worth it to read Remco Bloemen's article about muldiv, since that's where I sourced the constants from, in the first place.
3. Definitely, but this should be the least of your concerns.
4. I don't know, but you might want to take a look at the staging branch, where I have reimplemented PRBMath with user-defined value types, which should make it easier for you to extract the functions that you need out of PRBMath.

I'm sorry for the vague answers. I designed PRBMath with 18 decimals in mind and I never really thought deeply about other decimal systems.

A related conversation that might be a good read for you is this post on the OpenZeppelin forum: Designing Fixed Point Math in OpenZeppelin Contracts.