solidity exp() differs from javascript sdk exp()

[antoniopgs]

With the same input, the exp() function in solidity returns different outputs from the exp() function in the javascript SDK.

See image below:

Is this a bug? Or am I doing something wrong?

[PaulRBerg]

Hey! Thanks for opening this discussion. This is not a bug.

If you were to use TypeScript instead of JavaScript, you would have seen that you cannot pass JavaScript numbers directly. You can only pass Ethers BigNumbers to the PRBMath functions:

https://github.com/paulrberg/prb-math/blob/e33a042e4d1673fe9b333830b75c4765ccf3f5f2/src/functions.ts#L27-L30

JavaScript numbers are notoriously unreliable. Instead, what I recommend doing is to use my library evm-bn to convert stringified values to Ethers BigNumbers:

import { toBn } from "evm-bn";

log(exp(toBn("3174150177198", 18)).toString());

Note: I am not sure why you wanted to raise to power "3174150177198". Raising e to that power gives you a stupendously large number, which doesn't fit in uint256 (the raw Ethereum type used by PRBMath). You would get an overflow error in Solidity.

[antoniopgs]

I'm using evm-bn.

My exponent is of type PRBMath.UD60x18 and has a value of 3174150177198 (meaning 0,000003174150177198).

I arrive at said exponent by doing a mul() of two other PRBMath.UD60x18 values (both in Solidity and Javascript).

[PaulRBerg]

Oh, wait, I see what you mean now. Though FYI you're not using evm-bn in the JavaScript code snippet shared in the original post.

See my answer below.

[PaulRBerg]

Assuming that you used evm-bn, and the intention was to raise to power 0.000003174150177198 (3174150177198 in Solidity), then the behavior you're observing is completely expected.

It is not possible (or just very difficult) to have exact parity between mathematical functions implemented in different programming languages. And in our case, we are confronted with two very different languages: Solidity and JavaScript.

If you're writing Hardhat tests, you shouldn't check for exact equality between outputs. Instead, you should use an assertion such as Waffle's closeTo, or the one I wrote for PRBMath itself, the near assertion.

It might be instructive to take a look at the tests I have written for exp:

https://github.com/paulrberg/prb-math/blob/e33a042e4d1673fe9b333830b75c4765ccf3f5f2/test/contracts/prbMathUd60x18/pure/exp.test.ts#L33-L58

And:

https://github.com/paulrberg/prb-math/blob/e33a042e4d1673fe9b333830b75c4765ccf3f5f2/test/ts/functions/exp.test.ts#L29-L37

[PaulRBerg]

Happy to help! As a side note - I recommend taking a look at Foundry and my Foundry Template (sorry for the shameless plug!)

Testing your smart contracts in the same language as the one in which you write them gives much better security guarantees, and avoids situations like this one (discrepancies between mathematical function implementations across languages).

FWIW, PRBMath v3 will be tested with Foundry!

[antoniopgs]

Hahaha was just about to reply "maybe I'll switch to Foundry".

Thanks for the template! I'll check it out.
Awesome, I'll be waiting for v3 then.

Thank you for your time.

[antoniopgs]

Happy to help! As a side note - I recommend taking a look at Foundry and my Foundry Template (sorry for the shameless plug!)

I'm taking a look at your Foundry Template...
Do the PRBTest assertions support checking equality between two PRBMath.UD60x18 values directly (without doing .value)?

[PaulRBerg]

@antoniopgs this is a very good question that would be worth it to ask in the PRBTest Discussions!

I have an answer ready for you, but I would rather post it there.

[antoniopgs]

Posted.