We have to make a decision about whether to use int math, or translate the formulas to only use positive intermediate values everywhere (like fernando's implementation)

We might want to have a function that trades until exactly target SER. This is very useful for arbitrage.

it would be VERY NICE if we could emit an individual SWAP event for each token, exchanging it for the correct weighted quantity of poolcoin

In other words, make it very simple to generate exchange events (ie tax events) from event history

evm is dist

load/dispatch by function name etc

try/view/do
cross
ExactInLimitPrice
LimitPriceExactOut
MaxInMinOutLimitPrice

Trader

swap variants

viewSwap, trySwap, and doSwap for each variant

Pooling

Manager

https://github.com/balancer-labs/balancer-core/blob/5abafa84fa1c22d3dd25537605a8444d7f84d6f7/sol/BPool.sol#L133

The power function should use the normalized weight, not the absolute weight. Absolute weights can be huge numbers, if in the exponent I imagine overflows would be inevitable, right?

https://solidity.readthedocs.io/en/v0.5.11/050-breaking-changes.html

1. staticcall exists, and
2. call and staticcall return (bool, bytes) now instead of just (bool)

or, better API for pool-related math

Extend approximation formula for exponents > 1.

current implementation does not implement powers > 1: https://github.com/balancerpro/balance/blob/a6524e8681b09ac901dedd67a2ca812de90642d9/src/math.js#L18

old version: https://github.com/balancerpro/balance/blob/a6524e8681b09ac901dedd67a2ca812de90642d9/src/math.js#L31

formula 11: https://github.com/balancerpro/balance/blob/a6524e8681b09ac901dedd67a2ca812de90642d9/doc/approximation-formula/approximation-formula.pdf

working tests because ratio < 1: https://github.com/balancerpro/balance/blob/a6524e8681b09ac901dedd67a2ca812de90642d9/test/math.js#L39

broken tests because ratio > 1: https://github.com/balancerpro/balance/blob/a6524e8681b09ac901dedd67a2ca812de90642d9/test/math.js#L43

everything else needs to agree with #41

remove BConst and BError constants from BStub

there's no correct way to mutate balances and make 2 calls

should lock around both xfers

you can tell there's a bug from just reading

make a test to catch it

we need to set a limit for base for pow approximation in testing and contract code. the approximation converges for base < 2, but we don't know whether that's the best limit to advertise to users since the error always favors balancer

also use yarn

this is the one function with inconsistent arguments. We should have

ExactInAnyOut(Ti, To, Ai)
AnyInExactOut(Ti, To, Ao)

it will probably simplify the logic quite a bit, and might reveal interesting optimizations

characterize valid points

• 0 < Bi, Wi, Bo, Wo < MAXINT
• Ai < Bi
• Ao < Bo
• 0 <= fee < 1

generate a lot of them and test swapImathExact against solidity implementation

We'd like to have full code coverage. For example, our MaxInMinOut test cases don't error at all. Fine to have separate test ranges for errors to start, but in the end it might be good to have our current ranges to include errors.

if we want our weight range to be 1.0 - 100.0 then a lot of our tests would fail

most tests should pass with simply scaling up the test points weights

would be good to ensure try variants do not modify state in failure conditions

any pool can lock down to joinable state