Open Flipper1509 opened 5 months ago
Hi @Flipper1509
Thanks for the detailed report and attempt at fixing here.
This time in force hasn't really been very thoroughly tested, and seems there's definitely a bug here. I'll look into it.
Hi @cjdsellers , if you're interested - i'd be open to working on this because i want it to work for market on close i've already looked at it a bit.
Absolutely, you'll probably find plenty of commented out code along the paths. Keeping the test coverage up would be ideal too.
Let me know if you need any help.
Absolutely, you'll probably find plenty of commented out code along the paths. Keeping the test coverage up would be ideal too.
Let me know if you need any help.
@cjdsellers Sorry for the slow progress, it took me a minute to get the environment setup but i have that now and a small python file reproducing the scenario above
As I understand it, there are two issues at play here:
1) Equity instruments don't have a price_min and price_max - they are set to None. The simulation exchanges use them to turn the idea of a market order into that of a limit order with a maximum price in the case of a buy or minimum price in the case of a sell. I wanted to ask your guidance on how you think nautilus philosophically should work, for example:
2) The second issue - implement process_auction_book(self, OrderBook book) which is currently unfinished afaict. It looks to me like if the min and mix price issue is fixed we would run into problems here. Currently, the auction market order would be converted to a book order with a super high (or super low for selling) price and added to either the opening or closing book as appropriate. Then if the market state moves to paused for the open or close - we call process_auction_book to do the match. So we'd need to implement process_auction_book - some issues I notice with that are that we'd have to decide how to simulate that match. If we have full inside book or market data we could match against that, other wise we would need to fall back to bar data which may have bid/ask or may only have trades. The bar data may only be daily as well i guess. So this seems non trivial to handle all these cases - part of me wonders the auction choice made should be configured when the market is setup to make it explicit. For me personally, i'd want my orders matched at the auction price the market used if i was backtesting - so i guess that would be whatever the official close was for the day. But that probably shows an equities bias on my part I'm not sure.
Anyway, thanks for reading all that, I just wanted to check in and see if you had any thoughts or direction before i start writing code or if you see mistakes in my understanding of whats going on above.
Hey @fredmonroe
A little more back story here is this was working at one stage, and was disabled to make implementing the Rust order book easier.
I think we should use the max/min for the instrument if available, otherwise fall back to PRICE_MAX
/ PRICE_MIN
.
For the configuration, looks like we have a commented out auction_match_algo
parameter - which could address the auction choice. We have a module auction.py
which looks entirely commented out too.
MarketStatus
is passed to process_status
then this potentially triggers the auction (it just needs to exist in the data stream for the backtest).@limx0 may have some other thoughts on this.
Just adding my 2c also:
For me personally, i'd want my orders matched at the auction price the market used if i was backtesting - so i guess that would be whatever the official close was for the day. But that probably shows an equities bias on my part I'm not sure.
Yep I think this is the direction we want to head.
EOD bar data is definitely not where nautilus shines (one of the main selling points is backtest-live parity, its not clear to me what a live version of a backtest like this looks like), so whatever you see as the simplest solution is that gets this functional would be the preference.
PRs are very much appreciated so happy to assist where we can.
Bug Report
Hello,
I implemented the example strategy from the readme.md, the "minimal EMA Cross strategy example which just uses bar data". Therefore I created an Equity:
I feed EOD datato that strategy:
orders are generated and submitted. A market order (GTD, quantity=1) get filled immediately. That means within the same point in time:
A modified market order(time_in_force=AT_THE_OPEN) should do the trick, as far as I understand, because it should be only in force at the trading session open
Expected Behavior
The market order should get filled as soon as the next bar is processed. It should be filled at the opening price from the next bar.
Actual Behavior
The program aborts:
It seems, that the matching engine tries to access the max_price or the min_price. But those can´t be set :
In nautilus_trader/model/instruments/equity.pyx (line 93) the baseclass gets initialized. But in lines 110 und 111 there is hardcoded max_price=None and min_price=None. No chance to set plausible values there.
Before trying to make those properties setable, I hardcoded a min and a max price in equity.pyx like this:
and recompiled the project. The program won't abort anymore, but with those values none of the AT_THE_OPEN orders get filled at all. GTD Orders behave the same way as before.
So there must be more to get EOD trading handled in the matching_engine the right way...
Unfortunately I'm not able to understand the framework deep enough to be more helpfull than this report, sorry.
Steps to Reproduce the Problem
Specifications
nautilus_trader
version: 1.185.0