Add mulDiv function that accepts and returns UD60x18 arguments

[ivanvolov]

Description:

Currently, mulDiv only supports uint256 arguments and returns a uint256. While this is useful in many cases, using it in combination with other operations involving UD60x18 types often leads to repeated wrapping and unwrapping. This not only introduces verbosity but also makes the code less readable.

Example (current):

UD60x18 targetCL = ud(mulDiv(TVL.mul(ud(weight)).unwrap(), longLeverage.unwrap(), price.unwrap()));

Proposed Solution:

Add an overloaded version of mulDiv that accepts and returns UD60x18. This would simplify expressions and improve code clarity.

Example (proposed):

UD60x18 targetCL = mulDiv(TVL.mul(ud(weight)), longLeverage, price);

This enhancement would be especially valuable when chaining multiple fixed-point operations, as it helps reduce boilerplate and potential errors.

[PaulRBerg]

Hi @ivanvolov, thanks for your question. Could you please help me understand why you cannot use the mul and div functions, like so? If you did that, your code would be clean:

UD60x18 a = TVL.mul(ud(weight));
UD60x18 b = a.mul(longLeverage);
UD60x18 c = b.div(price);
uint256 result = c.unwrap();

or, more succinctly:

uint256 result = TVL.mul(ud(weight)).mul(longLeverage).div(price).unwrap();

`mulDiv` is an internal component that is by design not meant to be relied upon by end users.

The code in your example doesn't actually use 18-decimal numbers, but this is the very purpose of using `UD60x18` (and catch errors at build time!).

[ivanvolov]

Maybe I'm mistaken, but isn't it always better to use mulDiv if possible to mitigate Phantom overflow, i.e., a situation when the final calculation result would fit into the destination type, while some intermediary calculation overflows.

[PaulRBerg]

No.

Phantom overflow is not an issue with PRBMath because the mul and div functions themselves use 512 bits of precision. You can never get more than 512 bits during an operation, so there's no benefit to using mulDiv directly.

If you truly want a mulDiv abstraction that works with UD60x18, you can implement it by using the mul and div primitives like so:

function myMulDiv(UD60x18 x, UD60x18 y, UD60x18 denominator) pure returns (UD60x18) {
    return x.mul(y).div(denominator);
}

This a thin abstraction and I don't think many users would need it (and it'd also create a little confusion regarding its role vs the native uint256-based mulDiv), so it's unlikely it will get implemented in the library.

[PaulRBerg]

As per a private chat on Telegram, I was wrong when I said:

Phantom overflow is not an issue with PRBMath

Phantom overflow can be an issue when operating with large values near the maximum uint256 value, e.g.

UD60x18 a = ud(type(uint256)-max / 2) ;
UD60x18 b = ud(type(uint256)-max / 2);
UD60x18 c = ud(type(uint256).max);
a.mul(b).div(c); // will revert even if the `mulDiv` wouldn't.

In light of this, I am now in favor of implementing a mulDiv function that takes only UD60x18 as inputs and outputs.

[PaulRBerg]

Created issue to track this: #260