|Tools, Techniques, and Training for Nirvana Platforms|
|OmniTrader, VisualTrader, OmniFunds & OmniVest|
|1 Timothy 6:6-7 (NKJV) ... Now godliness with contentment is great gain. For we brought nothing into this world, and it is certain we can carry nothing out.|
| TytnTapsCGF Development|
USA: GA, Lawrenceville
|Happy New Year to you all !! |
Work continues albeit with some hiccups. There were some interruptions due to illness and family issues, but it’s still in process. I’ve not been posting to the forum since that eats a lot of time and the frequency and timeliness of the responses to queries I was making became untenable (I think people just got weary).
Here is a long-overdue update for y’all:
I’ve been creating and refining a major core component of all the Stradicators … I’m calling it TytnTapsCGF. It will be an integral part of all Strad’s but also (and this is new) will be available for independent non-Strad use.
TytnTapsCGF is a very sophisticated “universal” trade management routine. It drives the TradePlan block and can be coupled with *any* system+filter (such as canned Nirvana plugins), to provide robust control of scaling in and out of the trade that the Entry (from the System) triggers.
CGF stand for Cut Grab Flat, which is short and for three separate exit concepts: Cut = Loss-side “trailing” stop (actually, two of them), Grab = Profit-side “advancing” stop (again, two of them), and Flat = Consolidation-over-time “go-nowhere” stop (three of them). All seven methods are evaluated continuously, and can be toggled and tuned by the user.
“Tytn” refers to the user-spec’d feature that gradually and logically tightens the Cut, Grab, and Flat threshold rules as the trade progresses, based on how the OHLCV data unfolds. “Taps” refers to the user-spec’d option to allow multiple “hits” to the various methods, which either triggers a Full exit, or fires Partial exits along the way.
This can be used either in Full Exit mode (no scaling out), or can incorporate multiple intelligent Partial Exits (Loss-Cut &/or Profit-Grab &/or Flat-Finish). The Trade Plan is generic … which is crucial since scaling control requires LOTS of Steps and Conditions.
Also, the user can activate scaling-IN logic, in two forms: the initial Entry can optionally be split up into a small-medium “Toe-In” entry followed shortly after by a “Confirm” entry *if* the OHLCV behavior warrants … and/or the user can activate dynamic intra-trade Add-Ons which intelligently add to the position later on, after pullbacks, usually with Partial Exits interspersed. The sizing of PXits and Adds is also under user control, but has built in rules to prevent “unwise” structures.
The initial release will most likely have the full CGF rules but no PXits or Adds (might have Toe+Confirm option), since that’s the simplest TradePlan. I’m very close to that now. Then I’ll expand it to include PXit and Add support.
There will be an “Expert” mode with relatively few inputs, and a “Power” mode with full tuning control (both will drive the same engine). There will also be a “Master” single-input option that allows the user to save and re-use complex Expert/Power input config’s, tied to a single input index number.
Finally, there will be external log files that map exactly what happens during the course of the trade - these will be in CSV format suitable for import to Excel, for a variety of possible uses. The Master database mentioned earlier will also be Excel-accessible. The external logs are essential, since OT’s native PortSim (and “Advisor”) can’t and won’t properly handle scaling in and out dynamically.
Much of this might sound familiar to you, from previous posts about Stradicator development. I decided that it would be best to work on this massive core component independently first, so that it could be distributed and used right away, and so that the “trade management” concept could be applied to virtually any system+filter from-end. It will be offered to all those who bought-in with early discounts, with pricing comparable to a Stradicator.
The second reason that I decided to break this out separately was that it gives me a great sandbox-platform to develop and test the core Strad management methods, at a *detailed* level. When this gets “folded in” to each Stradicator, the same engine will be used, but fewer inputs will be exposed to “tweak” how it works … that is, the Strad implementation will be more like the “Guru”-level interface that some of you may recall from MTV.
After TynTapsCGF is complete, I’ll move on as previously planned to building it into various Stradicators which have self-contained robust entry and filter logic, and offer the special Scanning and Equity-Filter controls discussed earlier. That will go pretty quickly, since a big part of the core engine will be locked down.
I’ll post about this in more detail, with snapshots etc, in the near future. Thank you all for your patience and support! And, thanks especially to Salim, who has been a great sounding board and idea-helper during this time … and to Roger and LD, who have recently suggested an excellent Volume-logic rule.
USA: GA, Lawrenceville
|Rob asked: |
If I understand correctly TytnTapsCGF can be used in place of a trade plan in standard Nirvana Strategies and be evaluated with true walk forward testing. Also will it support intraday entries and exits? I suspect the market on close orders to avoid overnight exposure may be beneficial in many instances.
It will be usable for any timeframe, including Forex … I’m making special provision for Forex, which requires higher precision than native N functions provide for.
It will have options for MoC or MoO for daily+ bars … intraday uses BoO and has no MoC equivalent. I am trying to set it up so that Mkt orders fire for certain specific instances, but that might add a lot of extra TP complexity (we’ll see). Note that any strat which uses intrabar Mkt orders cannot be accurately backtested.
Walk forward testing is an iterative process within the OT engine, based on user-specified performance metrics, to optimize user-designated strategy parameters. If TytnTapsCGF is used in Full-Exit, No-Adds mode, then OT can “understand” it and native walkforward testing is possible. But if dynamic scaling in/out is used, it’s very highly unlikely that any native OT eval/optimize tool will work properly. N has told me on several occasions that they have *no* interest in supporting dynamic scaling in+out. That’s one of the reasons I set up TTCGF (and Strad’s) to create “TradeLog” files when they are run thru a backtest, or during live HRE trading.
The log files are still in tweak mode, but I currently plan to have the engine create/update two files for every trade. One file will track each symbol’s trades (for a given Stratey pattern), storing all the bar by bar details of what happened and why. A larger composite file will store the net result metrics of every trade (ie P/L, MDD, etc). The small files exist to help the user understand what is/was occurring during the trade … ie how the TP played out, so that they can intelligently tweak the rules if needed. The composite file holds all trades for all FL symbols for a given Strategy pattern. It can be used to create and evaluate portfolio equity curves.
Since OT’s PortSim cannot (and likely will not) properly handle dynamic scaling, it’s crucial that these log files are carefully and generically structured, readily accessible by Excel. It will be possible to do the equiv of PortSim plotting etc in Excel.
Regarding walkforward testing … this is a complex topic that I’ve written about extensively in the past, both re mechanics and re “cautions” of curve-fitting. I’ve created a more robust and “safer” (imo) approach for Stradicators that use dynamic in/out scaling. The Strad continuously eval’s the (properly calc’d) equity curve on a symbol by symbol basis. When the EC performance begins to degrade, it keeps on tracking the strat on that symbol, but stops firing Broker Entry orders until the background EC performance becomes acceptable again. This allows portfolio capital to be avail for trades on other Symbols which have acceptable current EC’s.
That’s a “summary” of the approach. It would be wonderful if N decided to enhance TP and PortSim functionality to correctly handle dynamic scaling, but I’ve been told that’s not ever likely to be done. Thus the genesis of the Stradicator.
Note re TTCGF … since it’s not a “true Stradicator” (it doesn’t include entry System + Filter logic), it can’t do a “background” EC calc. However, by incorporating EC (plus other P/L metrics) in a Smart OmniScan, OT can use dynamic Focus Lists to accomplish essentially the same thing. Best of both worlds.
Hopefully that explanation wasn’t too confusing. :~)
USA: PA, Warrendale
|MOC is what I want, I just wasn't sure how that would work in real time. IB requires MOC orders to be submitted by 1545 and what I was looking at is the close (actually the 1545) price crossing my stop. If I just use intraday stops the low is taking out the trade too soon whereas the MOC stop allows the good trades to run significantly longer but still allows me to capture most of the gain. I wasn't sure how I could back test this to see if this was an advantage over MOO the next day. I understand the complexities of walk forward testing and a reasonable approximation is fine, I just want to have confidence in the results.|
USA: GA, Lawrenceville
|Hi Rob … |
I hear ya and understand. I’m counting on the help of AutoTrade to optionally defer RT-feed analysis and orders to the last few minutes of the session, thus making a Mkt order roughly equiv to an MoC.
This is a complex topic with a lot of nuances. Some users consider it relatively UNimportant foe the historical modeling & analysis to be “representative” … others consider it crucial. My goal is to find an optimal middle path.
Still working on it!
Here is an extract from an email I got recently from someone who has a strong “live-trading” perspective. I’m trying to handle his needs as well …
I am a "big" fan of automated trading. As I speak I am currently Auto Trading several live accounts (Futures, Forex, Stocks), and I will be restarting my Live EOD Options account next week. I find that Market orders are the most flexible EOD trading order type. I use them exclusively in my EOD stock trading and on 50% of my EOD Options trading.
Market Orders simply makes automated EOD trading much easier. It allows one to simply change your order submission times to handle the current market situation. For example:
If the market is trending (very bullish or very bearish), I can easily submit (or time) my order submission for a "near market close entry". Usually something like 3:58 or 3:59 pm EST. Thus, you are able to enter trades prior to the close and benefit from the anticipated gaps occurring at the open
If the market is flat or more normal - then change your order submission time to submit the market orders prior to the open. The broker converts the Market order to MOO orders at the open.
So, I am able to "easily" change the character of my automated trading by simply changing my order submission time. This easily adapts my trading entries to work with the current market situation.
If I were to use MOC or MOO orders for EOD trading - I would actually have to "modify" the order type on each strategy if I wanted to switch between morning and afternoon order submission, which is a pain in the butt to say the least (for example, my EOD profile trades 12 to 15 strategies with about 5 or 6 distinct trade plans). Just a reminder, MOC orders have to be submitted 15 mins prior to the market close. If you submit them after 3:45 pm, or if you submit them when the market is closed these orders are rejected. Thus - you have to run the To Do list prior to the actual market close (which means that your actual and simulated trades will not be the same). MOO orders also have the issue with time flexibility. If you submit them after the market has opened, they are rejected. So, neither order type is acceptable to my current trading methodology.
Yes, MOO and MOC orders are easy to simulate. MOO orders actually match actual trading for the most part (but the same can be said for a properly timed Mkt order). MOC orders however do not match simulation. They deviate from actual trading (as one has to make the decision on whether or not to take the trade before the market closes. This means that the actual trades taken do not exactly match the trades taken in simulation.
The goal in trading is to make money. The goal should not be to match actual trading to the simulation. Thats actually the direction that Nirvana has taken with their current ATM Elite Relative Strength exit issues....
Bottom line , A properly "timed" market order type is the most flexible way to trade an automated EOD strategy. Yes, there may be some simulation issues (just like there will be simulation issues with MOC), but my goal is to do whats best for profitable trading and not simulation accuracy.
My response to him …
Thanks for the feedback. It is a knotty issue since OT and Broker have various limitations for live HRE trading … and is complicated by the need for “generic” Trade Plans … and further discombobulated by the manner in which OT models those TP’s for historical simulation / charting / analysis.
My goal is to provide the most flexible options possible that make sense, working with AutoTrade, for both EOD and RT intraday profiles, and that can be historically modeled with reasonable accuracy.
Your comments are important and illustrate part of the problem. The extra limitation I’m adding that (it appears) you don’t consider to be as important, is that the historically-plotted and analyzed performance is reasonably representative. By that, I mean the historical chart should show the correct BAR on which the signal occurred and the order fired, and (majority of time) the correct PRICE at chichi the order executed (barring slippage or partial fill issues).
I consider both historical and HRE to be equally important. And I’m working to find ways to best implement flexible options for them. Still tweaking.
USA: PA, Warrendale
|I agree totally with what he said. My trading concepts are no where near as complex as his and I likewise would like to use autotrade as much as possible. I plan to IB paper trade an account to see how it works. The obvious advantage of back testing is to better evaluate the draw down in bear markets|
|Owner of site: Jim Dean -- Forum content is confidential, and may not be distributed without written permission.|