Jim Dean Sage   Posts: 3022 Joined: 9/21/2006 Location: L'ville, GA  User Profile | 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. | |
