Open Zeppelin seem to have a subset of the functions here, that only allow for integers rather than optimising for 18 decimal fixed point, but one thing they do have is a rounding direction
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/math/Math.sol#L136
function mulDiv(uint256 x, uint256 y, uint256 denominator, Rounding rounding) internal pure returns (uint256) {
uint256 result = mulDiv(x, y, denominator);
if (rounding == Rounding.Up && mulmod(x, y, denominator) > 0) {
result += 1;
}
return result;
}these rounding directions are important e.g. in ERC4626 that mandates rounding directions as part of the spec depending on whether shares are being minted/burned and how that is being calculated
generally it comes up whenever there's question of token dust that might cause some function to revert or some weird exploit to be possible if senders can get something for nothing
the workaround is to do exactly what OZ does with a wrapper but if it was "native" in the prb-math lib that would be a nicer package downstream
Open Zeppelin seem to have a subset of the functions here, that only allow for integers rather than optimising for 18 decimal fixed point, but one thing they do have is a rounding direction
https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/math/Math.sol#L136
these rounding directions are important e.g. in ERC4626 that mandates rounding directions as part of the spec depending on whether shares are being minted/burned and how that is being calculated
generally it comes up whenever there's question of token dust that might cause some function to revert or some weird exploit to be possible if senders can get something for nothing
the workaround is to do exactly what OZ does with a wrapper but if it was "native" in the prb-math lib that would be a nicer package downstream