bsip38: update rounding

This commit is contained in:
abitmore 2018-04-17 05:33:08 -04:00
parent f817f1d886
commit 961b7162f5

View file

@ -110,13 +110,16 @@ The result is a rational number as well.
As described in [BSIP 35](bsip-0035.md), at last we need to convert the As described in [BSIP 35](bsip-0035.md), at last we need to convert the
rational numbers to integers, so rounding is involved. rational numbers to integers, so rounding is involved.
### The first round
When calculating maximum debt to cover, the goal is to go over the specified When calculating maximum debt to cover, the goal is to go over the specified
target but not go too far beyond. target but not go too far beyond.
That said, if a short position got matched with a big limit order, after That said, if a short position got matched with a big limit order, after
partially filled, its collateral ratio should be **just** higher than specified partially filled, its collateral ratio should be **just** higher than specified
target collateral ratio. Which means if `max_debt_to_cover` has no target collateral ratio.
fractional component (e.g. 5.00 as opposed to 5.23), need to plus it by one
Satoshi; otherwise, need to round it up. We may calculate like this: if `max_debt_to_cover` has no fractional component
(e.g. 5.00 as opposed to 5.23), plus it by one Satoshi; otherwise, round it up.
An effectively same approach is to round down then add one Satoshi onto the An effectively same approach is to round down then add one Satoshi onto the
result: result:
@ -124,19 +127,64 @@ result:
max_debt_to_cover_int = round_down(max_debt_to_cover) + 1 max_debt_to_cover_int = round_down(max_debt_to_cover) + 1
``` ```
With `max_debt_to_cover_int` in integer, `max_amount_to_sell_int` in integer should be With `max_debt_to_cover_int` in integer, `max_amount_to_sell_int` in integer
calculated as: can be calculated as:
``` ```
max_amount_to_sell_int = round_up(max_debt_to_cover_int / match_price) max_amount_to_sell_int = round_up(max_debt_to_cover_int / match_price)
``` ```
Then adjust `max_debt_to_cover_int` to be more accurate with: It's worth noting that we need to make sure the 2 integers always pair
perfectly, they're either the full collateral amount and full debt
amount, or have:
```
max_amount_to_sell_int == round_up(max_debt_to_cover_int / match_price)
max_debt_to_cover_int == round_down(max_amount_to_sell_int * match_price)
```
For `max_amount_to_sell_int` above, we can adjust `max_debt_to_cover_int` with:
``` ```
max_debt_to_cover_int = round_down(max_amount_to_sell_int * match_price) max_debt_to_cover_int = round_down(max_amount_to_sell_int * match_price)
``` ```
### Review the result
Due to rounding, it's not guaranteed that selling more collateral will
always result in higher collateral ratio on remaining call order.
On one hand, it's not guaranteed that the pair of integers above will
meet the requirements: after covered `max_debt_to_cover_int`, it's possible
that collateral ratio of remaining order is still not higher than `MCR` or
`target_CR`. In this case, the result is not acceptable. Generally, if we search
upwards, we can find a new pair that meets the requirements, or hit the order's
collateral or debt amount.
On the other hand, no matter if the pair above meets the collateral ratio
requirement, it's possible that there exists a smaller pair which meets the
requirement. However, it's not easy to find a perfect pair. If we search
downwards, it's not easy to decide when to stop; if we start from a smaller
pair then search upwards, it's not easy to decide where to start.
### Favor performance over accuracy
Due to the difficulty mentioned above, in this BSIP we allow imperfect results,
and don't describe or enforce how exactly to find better results.
The first implementation should be made with efforts. It will become consensus
after approved by stake holders via voting. It will then be in effect until
changed or replaced with a new BSIP.
Here are some guidelines about implementation.
When searching upwards, usually the real working pair is not far away, but it's
not guaranteed due to rounding. For better performance, it's not good to search
by adding one Satoshi every time. Can use a divergence sequence or other
sublinear-time algorithm, that means it's possible that some good data will be
skipped which may result in impefect result.
## Rounding on Order Matching, and Edge Cases ## Rounding on Order Matching, and Edge Cases
Rounding rules about order matching are defined in [BSIP 35](bsip-0035.md). Rounding rules about order matching are defined in [BSIP 35](bsip-0035.md).