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
|
||||
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
|
||||
target but not go too far beyond.
|
||||
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
|
||||
target collateral ratio. Which means if `max_debt_to_cover` has no
|
||||
fractional component (e.g. 5.00 as opposed to 5.23), need to plus it by one
|
||||
Satoshi; otherwise, need to round it up.
|
||||
target collateral ratio.
|
||||
|
||||
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
|
||||
result:
|
||||
|
||||
|
@ -124,19 +127,64 @@ result:
|
|||
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
|
||||
calculated as:
|
||||
With `max_debt_to_cover_int` in integer, `max_amount_to_sell_int` in integer
|
||||
can be calculated as:
|
||||
|
||||
```
|
||||
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)
|
||||
```
|
||||
|
||||
### 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 rules about order matching are defined in [BSIP 35](bsip-0035.md).
|
||||
|
|
Loading…
Reference in a new issue