Closed ian-wazowski closed 3 years ago
Thank you for raising this!
I saw you noticed on a previous commit I fixed the error in the order FSM to allow PENDING_CANCEL
-> PARTIALLY_FILLED
.
Could you please provide a code snippet where you assign the quantity for the order?
I think there is a loophole in the value object validation where a user can pass any value str
or Decimal
into a Price
or Quantity
without a precision specified - which will result in something like Decimal('1.005000000000000000104083409')
.
Even if this is truncated on the exchange side to 1.0050
etc, the quantity remaining will still be 000000000000000000104083409
after all fills have come back from the exchange.
The two options we have to solve this from what I can see are either:
value
(currently a precision is only enforced for floating point types).Thank you for raising this!
I saw you noticed on a previous commit I fixed the error in the order FSM to allow
PENDING_CANCEL
->PARTIALLY_FILLED
.Could you please provide a code snippet where you assign the quantity for the order?
Thank you! Excellent work!
I think there is a loophole in the value object validation where a user can pass any value
str
orDecimal
into aPrice
orQuantity
without a precision specified - which will result in something likeDecimal('1.005000000000000000104083409')
.Even if this is truncated on the exchange side to
1.0050
etc, the quantity remaining will still be000000000000000000104083409
after all fills have come back from the exchange.The two options we have to solve this from what I can see are either:
- Your above suggestion.
- Requiring a precision be passed into every value object regardless of the type for the
value
(currently a precision is only enforced for floating point types).
Entering precision for all quantities seems to be a more accurate and predictable solution for this solution. When developing adapters, I have to take a closer look. Thank you.
I'm leaning towards making precision a required argument for Price
and Quantity
although will have more of a think and consult some others. As you say it leads to more predictable outcomes, and doesn't rely on a user passing in a valid string or decimal value rounded to the correct precision for the instrument.
It also avoids this sort of epsilon comparison which is more appropriate for floating point arithmetic.
Attaching this link for an extreme yet readable deep dive into the subject too 😀
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
I welcome any further thoughts from yourself or others.
The precision is now explicit as a required argument for Price
and Quantity
types, so this bug should be resolved.
See release notes for 1.119.0
for more details.
As you can see, the exchange said the order was exactly filled but
Order.apply(event)
did not indicate that it was filled.I think there is floating point issue(we adapted Decimal Class massively as you know). Every time we add, subtract or converting type(float to double etc), we get a very small floating point error(a number less than 1e-10 or more), and because of this small decimal point, orders that should be marked as 'filled' are makerd as 'partial filled'.
To solve this, I would like to suggest adding a very small(no effect on PnL) margin( It is to set the lower limit mathematically.) when checking the order quantity as shown below It seems to happen inevitably when trading forex.
Any thoughts?