Returning unanticipated results

[its-me-ilia]

Hey, i am trying to use UD60x18 methods for my application but it has been confusing because of lack of docs.

here is the test function

function test() public pure returns (UD60x18) {
    return ud(15).mul(ud(2));
}

pretty simple one, but i get this result in remix IDE

even if i add unwrap() function around calculation and return it as uint256 it still returns same exact output, and if i try to use it with ethers.js it just returns

processing response error

not sure what's wrong here, i tried it with different operators but still the same result.

here is how i import the library in Remix IDE

import "github.com/paulrberg/prb-math/blob/main/src/UD60x18.sol";

Thank you!

[PaulRBerg]

Hi @its-me-ilia, thank you for your question. I am sorry that you didn't find the current state of the docs satisfactory - there are a few examples offered in the README. Might you have missed them?

ud(15).mul(ud(2))

UD60x18 is a fixed-point type with 18 decimals, which means that the values you passed here are actually 0.000000000000000015 and 0.000000000000000002. These numbers are so small that when multiplied together, they yield a number with more than 18 zeroes after the dot, therefore PRBMath gives you the result 0.

Now, what you are perhaps interested in is the toUD60x18 conversion function, which would do the conversion from 15 to 15e18. Personally, I do not use that method because oftentimes I need sub-unitary values. What I usually do is to simply add the e18 suffix, like this:

ud(15e18).mul(ud(2e18));

If you would like to pass a sub-unitary value, you would do this:

ud(0.5e18); // this is 0.5

I know that the DX isn't great, but this is a present inherent limitation of Solidity. It is not currently possible to multiply fixed-point literals, so you always have to pass the e18 suffix manually.

Any feedback on how I could improve the docs/ README would be welcome!

[its-me-ilia]

My apologies, yes you are right there was this e18 part mentioned, thanks for the such a quick answer, indeed e18 part was missing to make it work, now i see that results are returned with 18 zeros and i can just divide it with 10^12 if i want to be left with 6 decimals only, i also run some larger compounding calculation ud(100e18).mul(ud(1e18).add(ud(0.08e18)).powu(1000)) and got this number as a result "265311140756403314450413663161333642116800998597166000", while this is the result from calculator "2.6531114e+35". these two numbers are not equal and i am not sure how the calculation worked exactly that this number is not followed by 18 zeroes as well. can you give me a bit of insight on this as well, or refer me to the explanation, would be awesome. Thanks!

[PaulRBerg]

i can just divide it with 10^12

If the goal is to handle tokens with 6 decimals, you might be interested in my precision scalar technique.

this is the result from calculator "2.6531114e+35"

I can't know what calculator you used, but usually calculators don't display all digits, for brevity reasons. For instance, if you were to use Wolfram Alpha, you would have to click on the "More digits" button to show all digits. Also see the screenshot below.

these two numbers are not equal

As a general comment, you should note that PRBMath is not as exact as other more advanced calculators like Wolfram Alpha or Symbolab. The reason is twofold - PRBMath only has 18 decimals, and there are certain inherent limitations of the EVM that prevent one from running advanced computations.

That said, PRBMath should be sufficiently precise for all intents and purposes. Do let me know if you stumble upon any situation where the lossy precision of PRBMath precludes you from achieving your goal.

[its-me-ilia]

Thank you for the response, i understand now that i can't look for exact precision on numbers this big, but i have one question about your precision scalar technique, as far as i understood from your tweet if i have this calculation for compound interest ud(100e18).mul(ud(1e18).add(ud(0.08e18)).powu(1000)) all i would need to do is ud(100e18).mul(ud(1e18).add(ud(0.08e18)).powu(1000)).div(ud(10**delta)) ? assuming delta is 18-decimals_of_token ? or am i missing something

[PaulRBerg]

I am not sure about your compound interest, it depends upon how it is used in the code base overall. But let me restate the precision scalar idea to make it clearer.

The point is to normalize (a key word) all token amounts to have 18 decimals. So if a user gives you 10 USDC, that's 10^7 units, but you know that USDC has 6 decimals, so you normalize that amount to have 18 decimals (just like all UD60x18) by multiplyingg by 10^12 (generally speaking, the exponent would be 18 - decimals).

This technique has the downside of not being able to support tokens with decimals greater than 18, but, as discussed here, there are few tokens that have so many decimals.