Current location | Thread information | |
![]() ![]() ![]() ![]() ![]() ![]() |
Last Activity 1/2/2025 4:50 PM 3 replies, 952 viewings |
|
|
Printer friendly version |
^ Top | |||
kmcintyre![]() Legend ![]() ![]() ![]() ![]() Posts: 410 Joined: 8/30/2007 Location: Valley Center, CA ![]() |
I have spent the afternoon trying different Trade Plan Entry conditions. What I was going for was a Buy Stop Limit order where the Stop was the H of the signal bar and the limit was the same (at least for now). The concept is that the next bar must confirm the entry by trading above the H of the signal bar, but I want to protect against gaps that might cause me to buy at a price much higher than I intended. (In some cases above my target exit price...) One thing I noticed (a head scratcher) is that I had to set the Time In Force for the Limit condition to 2 bars. The default of 0 allowed the trade to live a long time until price finally fell back to the H of the signal bar. A setting of 1 (which made sense to me seeing as I wanted to give the trade 1 bar after the signal bar to fill or kill) never entered any trades. Only by setting TIF to 2 would I enter trades on the bar after the signal bar, but only if the Stop and Limit where hit within that bar. What am I missing? The second thing I saw was that I was always seeing the Open price being used for the fill price. This always seemed to give my trades an edge. In real life I would expect the fill to be very close to the Stop price. As soon as the order was armed (trading at the STOP) the Limit would also be hit, allowing a fill very close to the Stop/Limit price. Giving me a lower Open price didn't seeem right. Is there a way to force the TP to fill at the Stop price? AFAIK I can't write OL to control the fill price. I can only signal a long or short. It is up to the TP to assign an entry price. Correct? Thanks ![]() | ||
^ Top | |||
Jim Dean![]() Sage ![]() ![]() Posts: 3022 Joined: 9/21/2006 Location: L'ville, GA ![]() |
You'll need to write Barry for answers about how the TP addresses SL orders, etc. There are many idiosyncracies. I've tried to learn them, and work around them. I'm not surprised to hear that the SL logic seems to be confined to both happening on the same bar ... the TP engine has a very "short memory". A possible reason for needed a min of two bars for a SL (or L or SM) order is that the TP paradigm afaik *sets* the threshold while on the signal bar, for implementation on the following bar(s). My guess is that the bar-count starts with the signal bar. But only N staff can confirm that. My experience has been that asking questions like that usually requires a N programmer to answer them ... and sometimes, the answer is "just experiment to find out". Sigh. Also possibly related to the fill-price thing ... quite a while back (8-10 yrs?), due to some user complaints, Hans made a change in how the TP engine deals with some kinds of fills in OT's modelling. It's a complex topic but the bottom line seems to be that *since* OT does not know the sequence of how a bar is formed (ie O-H-L-C vs O-L-H-C, etc), then threshold-crossing logic such as SL, L, SM orders are treated *in the most conservative pattern* (at least, from Hans' POV at the time). That is, the modelling (supposedly) will look at the bar and the order type and will fill at either the worse logical price which conceivably could have happened (depending on how the bar formed in realtime) ... or at some "knee jerk" price (such as O or C). I've never quite figured it out, frankly. On account of that, I've gravitated to the following rules when I create strategies, which do seem to work reliably: 1. Whenever I'm willing to accept it, I use MOO since that is most definitely N's go-to preference in all their platforms, and it's easy to know how it works. 2. If MOO is not viable, then 90% of the other situations I try to handle via Market orders. With a RT feed and plenty of liquidity, then *usually* I can get fills similar to threshold-based Broker SM, L, SL orders by simply doing the logic for the limit order within OLang, to determine when to fire the Mkt order. 3. When I absolutely have to have a threshold-based *Broker* order in place, I stick to SM orders, and use the Orders pane menus to carefully choose the size and type of gap, and the basis price. This seems to work reliably. ... I've been told by N that the menu-based L and SL orders also work reliably. But since it requires RT testing with actual $$, I haven't beaten on that very thoroughly ... I'm confident that the broker handles the orders correctly ... and reasonably confident that OT places the orders with the broker correctly. But I have low confidence that the backtest engine's simulation after the fact will accurately represent the performance (see earlier comments). I hope this helps. I've learned that for some things with OT (or any platform for that matter), I just need to *accept* the foibles of how it works, and use it as-is to best advantage. Sometimes a hard pill to swallow, but comes with the turf. | ||
^ Top | |||
kmcintyre![]() Legend ![]() ![]() ![]() ![]() Posts: 410 Joined: 8/30/2007 Location: Valley Center, CA ![]() |
Jim Thanks for the reply. Good info! If I understand correctly, I could run my strategy RT, monitor the current price (using minute bars) and LongSignal at the entry price. (Does OT RT data support tick charts? Does OL support Last Fill or Bid / Ask in RT?) Or I can run ToDo EOD (as I am doing), generate LongSignals the night before, and accept what the Trade Plan / Broker gives me. I can't change or specify the Fill price via OL to improve my backtest stats. But at the HRE trades placed will probably fill near the LMT given my Buy Stop Limit scenario.) And don't worry. Be Happy! correct? | ||
^ Top | |||
Jim Dean![]() Sage ![]() ![]() Posts: 3022 Joined: 9/21/2006 Location: L'ville, GA ![]() |
Yes re RT - and of course the RT bar-duration you’d Use would be the one that your trading signal analysis was intended for (Daily, 10min, whatever). Natively in OLang (without a lot of effort doing special coding), the displayed chart bar-times will match the brokerage interface trigger times (unless of course you use a Market order). Yes OT RT supports Tick but not well - it doesn’t maintain server based history so the available ticks start when you start OT and continue as long as the feed is not interrupted. You can do to any effective backtesting. And of course since Ticks are “NTB’s”, most classic indicators etc are questionable applicable. One of the recent survey Q’s asked for votes re improving Tick feed (w/history from server, like other time frames). So maybe this will change. No re bid/ask or other Level 3 interface. N’s most common approach is to do as you said - run analysis at night and use MOO for entry at (semi-negotiated) Open price the next morning. That and Mkt are the two fully reliable order types from N platforms. Using OLang you can modify the threshold Stop level for a SMkt order, using the “ExitLevel” assignment in OLang. But afaik, that only applies to backtesting (reliably). And doesn’t support a Broker order. For all threshold based order types, stick to the rules in the Order Pane window of the TradePlan. Yeah - that’s good advice for any area of life that you can con yourself into accepting! Heh heh. |
|
|
Legend | Action | Notification | |||
Administrator
Forum Moderator |
Registered User
Unregistered User |
![]() |
Toggle e-mail notification |