✨ FixedMathLib: expWadDown()

[recmo]

Description

Describe the changes made in your pull request here.

Checklist

Ensure you completed all of the steps below before submitting your pull request:

• Ran dapp snapshot?
• Ran npm run lint?
• Ran forge test?
• Ran dapp test?

Pull requests with an incomplete checklist will be thrown out.

[recmo]

CC @transmissions11

[transmissions11]

amazing already

[recmo]

Hmm... that should have been a ~10 gas reduction.

[recmo]

Can't inline the variables z and w because they both get used twice. That's the scheme basically, you need more variables and additions, but in return you have fewer multiplies. Multiplies are more expensive, so it may be worthwhile.

[transmissions11]

yup... thought maybe this would save some but looks like the optimizer was smart enough in the first place

[recmo]

We can always go back to the original formula for q, but somehow I feel that removing a multiply should save us something :D.

I have a similar scheme for p that also removes a mul:

int256 y = x      +     1346386616545796478920950773328;
y = (y * x >> 96) +    57155421227552351082224309758442;
int256 p = y + x  -    94201549194550492254356042504812;
p = (p * y >> 96) + 28719021644029726153956944680412240;
p = p * x         + (4385272521454847904632057985693276 << 96);

but that one somehow ends up costing 1 gas more than the plain formula in my local tests.

[transmissions11]

the scheme for p saves gas in my tests!

[transmissions11]

want me to commit? seems like the scheme for p and the original formula for q is the fastest

[recmo]

lol! In my repo it's exact opposite! Yeah, go a head an use whatever works best. But I wonder what's going on though.

[recmo]

This actually annoys me quite a bit.

[recmo]

People know a^0 = 1 from their algebra class, and might write contracts that depends on fp.mul(x, fp.exp(0)) == x. Would be nice if this held.

Easy fix is to add 1 wei to the output. Can probably do that at zero extra gas by adding to the constant term of the p polynomial. It should not hurt the accuracy of other values much. Let me fiddle with this.

[transmissions11]

Hmm that will give the effect of rounding up in some areas I believe

[transmissions11]

lmk adding to the constant term works without impacting the other vars

another way thats only a couple extra opcodes would be doing

assembly {
	r := add(r, iszero(x))
}

right at the end

[transmissions11]

is it optimizer run related? we use 1m in here

[transmissions11]

should we add a comment about using knuth's method here?

[recmo]

Sure, it's the first method from page 491. He mentions a second one which has one fewer addition, but leaves the details as an exercise. I haven't bother to do that exercise yet :)

[transmissions11]

btw how hard would it be to implement a rounding up version of this? looks like this impl truncates (which is great but i'd like to have both a floor and ceil version)

[recmo]

btw how hard would it be to implement a rounding up version of this? looks like this impl truncates (which is great but i'd like to have both a floor and ceil version)

This should work (assuming we fix the exp(0) = 1 issue):

function expCeil(int256 x) returns (int256) {
   if (x == 0) return 1e18; // ceil(exp(0)) = floor(exp(0)) = 1
   return expFloor(x) + 1;
}

[recmo]

But I don't think it is guaranteed to return the truncated / floor result. For larger input values it doesn't have the precision required to do accurate rounding.

It also doesn't make sense to increase the precision for large inputs, because the input itself is only accurate up to 1e-18.

[transmissions11]

But I don't think it is guaranteed to return the truncated / floor result. For larger input values it doesn't have the precision required to do accurate rounding.

oh hmm yea maybe just got lucky with the test cases i used