bsip38: update rounding
This commit is contained in:
parent
f817f1d886
commit
961b7162f5
1 changed files with 54 additions and 6 deletions
60
bsip-0038.md
60
bsip-0038.md
|
@ -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).
|
||||||
|
|
Loading…
Reference in a new issue