Arbitrary number of decimals.

[itsdevbear]

Is it possible to set up things such that this library could be used as 61x17? or 65x13?

From briefly reading through the code, adjusting the SCALE and HALF_SCALE values should be able to accomplish this without throwing the math out of whack?

Is this something that has been explored? @PaulRBerg?

Also haven't forgetting about #51, it's under way.

Cheers,
bera dev

[PaulRBerg]

Hey! Unfortunately, while possible, this would be non-trivial to implement. It's just not some constants that make the library to work with 18 decimals - the library is much more sophisticated than that. For example, the exp2 function uses the 192x64 format internally. Swapping 60x18 for61x17 would mean rewriting line 130 in PRBMathUD60x18.sol.

You may want to read this thread on the OpenZeppelin forum: Designing Fixed Point Math in OpenZeppelin Contracts. The consensus there was clear - fixed-point number of decimals is superior (gives better security and guarantees) and it is easier to maintain.

What do you need arbitrary number of decimals for?

[itsdevbear]

@PaulRBerg I am struggling to figure out a nice clean way to do math when dealing with tokens of different decimal places.

So far I have resorted to padding everything to 18 decimals, and it works well, its just verbose and there is the potential for overflow causing revert with very large numbers (unlikely but in theory possible).

Modified a section of your code to get that part working. I pass in (18 - token.decimals() to pad to 18)

    // Example:
    // input:  (115792089237316195423570985008687907853269984665640564039457_584007911, 9)
    // output: 115792089237316195423570985008687907853269984665640564039457_584007911000000000
    function pad(uint256 x, uint256 num) internal pure returns (uint256 result) {
        uint256 scale = 10**num;
        unchecked {
            if (x > PRBMathUD60x18.MAX_UD60x18 / scale) {
                revert PRBMathUD60x18__FromUintOverflow(x);
            }
            result = x * scale;
        }
    }
    ```

[PaulRBerg]

You're overthinking it - PRBMath (as is) is already solving the problem you're trying to solve.

I have resorted to padding everything to 18 decimals, and it works well

This is exactly what I'm doing too. Take a look at the BalanceSheet contract, specifically at the getHypotheticalAccountLiquidity. More generally, glance through the Hifi monorepo, which is using PRBMath.

There is the potential for overflow causing revert with very large numbers (unlikely but in theory possible).

That's true, but if you're using the PRBMath mul and div functions, you're protected against phantom overflows. That's because I have implemented Remco Bloemen's mathemagical mulDiv.

Modified a section of your code to get that part working

Again, I highly recommend you don't do that. The fact that numbers are formatted with 18 decimals is a fundamental assumption of the way I wrote the library. There be dragons.