Extend fixedpoint library to support negative numbers

[dpaiton]

Several motivators for this:

• The max.rs function notes a desire to have negative number support in the fixedpoint math library. With this support the max long & short logic could be simplified.

  • This logic applies in many other places, for example targeted_long delvtech/hyperdrive#882, targeted_short delvtech/hyperdrive-rs#21, and calculate_update_liquidity delvtech/hyperdrive#934.

• It would likely be required in order to support state transitions delvtech/hyperdrive-rs#39, which then could greatly improve simulation speeds on the python side.

• This would also make the rust fixedpoint library feature complete (enough) with our fixedpointmath python lib, which means we can swap the entire library from being python-native to python-wrapped-rust, which should improve speed and confidence in parity between python and solidity (thanks to the cross-platform fuzz testing between rust and solidity). If nothing else it will impress people a lot.

[dpaiton]

Tasks:

• Change the FixedPoint struct to I256 instead of U256
• Change try_from type import err
• Change hardcoded u256 in to_scaled_string
• Check bounds in exp.
• Change conversions to and from FixedPoint to properly handle negative values
• Verify that remaining math fns are fine
• Write negative tests

[jalextowle]

I thought about this more last night, and I came away with a slightly different perspective on this. From a priorities standpoint, I see this as a “Nice to Have.” I don’t see this as a blocker for implementing targeted likings or other features, and I wouldn’t consider this to be as urgent as those features. I’m happy to talk through how we deal with negative numbers in the other optimization flows. It’s easier than it sounds, and we’ve gotten quite far without this kind of thing.

I say all this, but if implementing this were super quick (like a few hours), I’d say go for it. I’m skeptical that it will be that easy since we need to preserve 1:1 parity with solidity’s fixed point numbers, which also wrap “uint256” and don’t support negative numbers.

[dpaiton]

This makes sense to me. I agree with your assessment that the tech debt is acceptable. Let's delay for now.

After an initial survey of the problem, I think it would be relatively easy to make the conversion if you're willing to live with the loss of range (just go straight to signed). I'm not sure that we really need the uint range, so lets consider this when we pick the task back up. The amount of work increases significantly if we're going to keep the internal representation uint but still support signed operations. It's also worth noting that the present implementation of Hyperdrive and FixedPoint jump back-and-forth between i256 and u256 so I think in the end we don't have that big range anyways.

[dpaiton]

resolved by #186