Search | User Listing Vidsite | Calendars | Quotes
Home Page ->  Custom TradeTight Routines -> Tools In Team Development -> View ThreadLogon (or Register, or Join TradeTight)

You are logged in as a limited-access Guest.To join TradeTight, first read the info in the Organization & Content room, then click the link above. 

Matthew 25:16,21 (ESV) … He who had received the five talents went at once and traded with them, and he made five talents more … his master said to him, ‘Well done, good and faithful servant. You have been faithful over a little; I will set you over much. Enter into the joy of your master.’


Sticky TrdLog-Files for StradFolio & StradWiz
Jump to page : 1
Now viewing page 1 [50 msgs/pg]
Jump to room :
JimDean
Posted 8/24/2019 11:48 AM (#9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
This breakout thread is for Log File and StradFolio discussions only - other topics use normal thread:
http://tradetight.org/forums/thread-view.asp?tid=1444


I'm focused right now on resolving whether, and how best, to provide for "logging" of Signals, etc over time, direct from the Stradicator. Whether I create a log or not, there definitely will be an option for the current symbol to have a popup any time the final displayed bar of the output range has a Signal appear on it (described earlier) ... so that the manual trader can implement an order.

Re creating a text-file Log (importable to Excel), there are three options:
1. Don't
2. Do it, but only via the "Robust" Trade Plan (which needs something like it anyways)
3. Do it optionally direct from the Stradicator, even if no TP is engaged

The log file, mentioned earlier, contains all the info from the Signal-action popup, for every bar in the output range specified by the BarWndo input ... and possibly more info, for every bar in trade that doesn't have a Signal. Aside from debugging or general interest, the Log file's main purpose is so that users can pull it (or a series of them) up into Excel, then evaluate the trades in whatever way they may want ... it will have absolutely complete info, so there is a lot that could be done.

The most notable derivative of the Log file would be feeding a fancy Spreadsheet which is designed to more-or-less emulate/replace the Portfolio Simulator ... keep in mind that Port Sim is unable to deal with scaling in-out trades as well as some other things ... so if Portfolio equity curves are desired, Excel will be the solution path. Many comments from N staff have led me to believe that they don't plan on upgrading PortSim adequately in this manner, for a long time to come (if ever).

I have the ability to create a spreadsheet like that, but it's definitely not in the Project schedule. But there are others who also could do it, once they know the Log file contents and format. MARK HOLSTIUS certainly could! (are you seeing this, buddy?) So ... if anyone has a sincere interest in creating a spreadsheet that takes the raw info from a bunch of log files of trades, and builds the curves and composite stats a la PortSim, please contact me ASAP (even if it might be several months before you could take it on).

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 8/25/2019 7:55 PM (#9681 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
I’m very pleased to report that Mark Holstius immediately replied to me, and agreed to work with the Trade Signal Log output file, to create a powerful and versatile spreadsheet which performs the kinds of functions that Portfolio Simulator does for “simple” OT trade plans … but of course with additional more sophisticated analysis options and statistical output.

It will of course create equity curves for the overall trading Account, based on simultaneous trades from multiple symbols (like PS does). It will properly deal with the Stradicator’s dynamic scaling in and scaling out signals. And it will be able to model a combo-account that uses various combinations of instruments, and/or timeframes (ie some intraday, some daily). And so on.

Mark is busy for a few months, but he told me he would be able to dive into this project no later than 2/1/20 … which, if all goes well on my end, will mean that he will likely be done about the same time that my list of Project tasks are done.

Since the Log file output will be part of the Stradicator paradigm, all five of the initial Strad’s (and any future ones) will offer it as an option. Mark’s spreadsheet will be able to work with any Strad Log files, so a mix of diff Strad’s and diff Syms and diff timeframes all in one Portfolio simulation will be a “natural” for it.

This will take Mark a lot of time, so I will arrange a means for licensed distribution of it - he will get 100% of the sales revenue for it, when users opt to get it. The Log file output option is a part of the Stradicator package - the spreadsheet isn’t.

I’m very excited about this - Mark is, as you all know, THE primo expert in Spreadsheet design in the N “family”. It’s an honor to have his help.

Thank you very much, Mark!!

(PS: so, I will use option #3 from the prior post.)

Post moved by on 8/25/2019 7:56 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 8/25/2019 7:56 PM (#9684 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
More thoughts about implementing the Log file from the Stradicator…

This differs from the Log/control file of the Robust TradePlan - the main purpose of that file is to *control* the actual TP flow … the fact that it documents what happened as and after the trade is complete is sort of a “side benefit”. The RTP file has some tech detail in it that a true Log doesn’t really need. So, although it *could* be used to feed the Stradicator Portfolio (“StradFolio”) spreadsheet, it wouldn’t be the cleanest or most efficient format. Nor will it include the “reasons” behind why a given signal fired - that’s internal to the Stradicator but not passed on to the TP.

So, the decision to include the Log file output option as part of the Strad paradigm will allow the RTP file to remain dedicated to its purpose … and will allow the format of the Strad Log to be both informative and efficient (re as input to the StradFolio excel sheet). I like clean distinctions.

The main focus of this post is to define *how* the user will “trigger” the creation of the Log file. Since opening and closing files can slow things down, and since files need to have a clean structure for import to StradFolio, and since the purpose is historical study rather than live HRE tracking, this means …

1. One file should be created for all the trades by that Stradicator-config, for a given Symbol and Timeframe (bar length and first-last bar output range).
2. The filename should ID those #1 criteria, in a format suitable for sorting, and should be unique enough so that if just one input changes, a new name is used.
3. The initial record(s) of the file should repeat that info, and also document the specific Strad input-Param settings used.
4. The Log file creation should be triggered by the final Output control slider, using a setting that is common to all versions.
5. If the Log is triggered when using real-time feed, the Strad must halt the creation once the then-current HRE bar is reached - and ignore any ongoing price-prints.
6. The only way to do #5 is to end the Log file output with a Popup window, which automatically “freezes” OT operation until the user clicks OK.
7. The final-param “0” option is in all versions (#4), and creates a popup that freezes things (#6), and applies to the current charted Symbol - an ideal solution.

So - I’ll add an extra click-button option to the Help pop ups - likely at the bottom of the first popup help pane, to optionally create a Log output. If that is clicked, the popup closes and the file will be created, then a new popup will appear to report completion and end execution. This approach prevents an infinite loop if a RT feed is active.

If the user has, say, 20 symbols in their FL and wants to get a Log file for each of them that uses the same Strad-input-pattern and timeframe, then the procedure is simple:
1. Click on first Sym in FL to bring up the chart
2. Right click the indicator to open param panel (change final param=0 first time)
3. Click on “Create Log” button when Help panel pops up
4. Click on Log-Completed popup “OK” button when it appears
5. Click OK to close Parameter panel, then click on next Sym in FL
… repeat steps 2-5 for all desired Sym’s in FL.

Another variant is to create a series of separate Log files for a single symbol, that are based on different Strad param settings. Steps 1-4 are the same, but step 5 leaves the Param panel open - you change the param sliders to the various combos, in succession. If a combo requires >1 slider to change, then reset the final param to a nonzero value until the new pattern is as you want it.

This is pretty versatile. I’m sure though that some of you will be thinking that wont work, if the FL is *dynamic*, changing from one day to the next. Ideally, there needs to be a Log Output which handles that. It’s a much more complex scenario.

The inner workings of how OT processes things for profiles that use Dynamic Scans is wholly undocumented. But I do know that once a trade on a given symbol “kicks off” on a given day, then even if that symbol disappears from the dynamic-scan FL the next day, the TradePlan keeps things rolling until the trade is complete. So - the solution for dynamic FL studies needs to use the TradePlan control-Log file, rather than the Stradicator Help-panel file. That’s do-able but clearly is a separate task. So, I’ll implement the Stradicator Log-Output first.

Hopefully most of you (whomever is reading ;-) can genrally follow this description. If you notice that I’m missing a bet somehow, please let me know. The goal is for the StradFolio excel analysis to be able to work with any kind of Stradicator-based trading that OT can support.


Post moved by on 8/25/2019 7:56 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 8/25/2019 7:56 PM (#9685 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
This post presumes that you’ve had the perseverance to read the prior (long) post - it won’t make any sense to you, otherwise. This post (like the last) is stream of consciousness for me as I plan things. Some of the things in this post may contradict plans made in the prior post.

MAYBE:
If I’m going to have to create a TradePlan Log-file solution anyway, to handle dynamic FL’s, then it might make more sense to *dispense* with the Help panel popup one-Sym-at-a-time approach, and just handle the entire thing via the TradePlan.

This means that the “Simple” TradePlan (supports trading that does *not* use dynamic partial exits and add-ons) must be *enhanced* to be able to generate a Log file - which is not otherwise needed for the TP to operate. This is do-able, and provides a nice development stepping stone into the Robust TP architecture, later.

The Log file created from the TP will *not* document the reasons behind why the Signal was fired, but that’s not really necessary for the StradFolio analysis anyways. The Log file *will* document the symbol, size and type of order and price it executes at. It will also record the ohlcv for each bar during the trade, which StradFolio will need to create a continuous equity curve (and possibly for other stats such as volatility or intranet extreme excursions).

When the TP is being run by OT with static-FL backtesting, all the trades for a given symbol will be processed, then OT moves on to the next symbol. In that scenario, one Log file per symbol could be the result (even for dynamic Scan runs - if a symbol skips in and out of the FL, the routine could just re-open the file for that sym any time a new trade occurs for it) … or, which might run faster, it could just create one small file for every trade, with the entry date and symbol and run-ID in the file name.

When the TP is running using dynamic-FL backtesting, since the FL symbols potentially change every day, then the one-file-per-Trade approach is the most practical one, and will run *much* faster than trying to build one massive file that iteratively opens, reads to the end of file, records a new trade, then closes again, over and over.

Result: a given backtest run might create several thousand tiny files (ie NT= number of trades = number of files). It is NOT practical for the user to manually these into the StradFolio worksheet. But, thanks to a handy-dandy google search, I found a nifty automated procedure that I’m 95% certain Mark can build into the spreadsheet:
https://www.rondebruin.nl/win/s3/win021.htm
*** MARK: if this is not something you know how to do, please let me know now so I can chart a different course. ***

Nutshell: all the tiny files get stored in a folder that is dedicated to that particular backtest run. The macro-routine above in StradFolio automatically concatenates the files, in the order they were created, into one big CSV file. Which is then processed for analysis. Mark: note that each trade will have its own series of records (one per day), and the next-listed trade in the big file will often be a different symbol, whose entry date is either the same or following the entry date of the prior listed trade - and those trades often will ***overlap***. Please let me know if you can work with this format/sequence.

All of this means that the comments in the prior post about the final-param input=0 popup initiation of a Log file direct from the Stradicator would *not* be implemented. I’ll wait to hear back from Mark before heading down one path or another.





Post moved by on 8/25/2019 7:57 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
RobertPfoff
Posted 8/25/2019 7:57 PM (#9686 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Friend

Posts: 19
0
Location:
USA: PA, Warrendale
I like the second option better if it is doable. Dynamic FLs are inherently complex. This looks like it would work.

Post moved by on 8/25/2019 7:57 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 8/25/2019 7:57 PM (#9687 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Hi Rob -
I take it you mean the creation of the Log file from the TP. The subsequent posts detail the logic and conclude the same thing. But I need to hear from Mark so I can create file(s) that the StradFolio sheet can readily parse.

Since one of the really powerful features of a Strad is the intelligent Scan, which should be redone fairly often, imho the ability to use Dynamic Scans for backtesting is very important.

There is an alternative path though. If the manner that OT processes Dyn Scans is for some reason a poor fit to meet this need, then the same thing can be done by building the Scan into the Stradicator as a Filter rule (along with any other desired Scan filter rules such as liquidity). In that case, the FL needs to be massive (like maybe the Rus3k+Optionable). This means the backtest calcs will take a lot of time. But then again, so do Dyn Scans. So maybe it will be a wash.

The point is to be able to do it, somehow.

If the huge-FL approach with the Scan spec’d as a Filter turns out to be the most practical method, then the Log Files could be tiny trade by trade multitudes - the same as described for the Trade Plan generation, above, OR could be one file for every Symbol which has any trades actually occur during that backtest window, after the Filter rules (generic plus Strad E-Stats) are satisfied.

That would create far fewer files, and the file read/write time would be more efficient than the Trade Plan method. Also it would be easier to implement than the Trade Plan method.

However, Mark needs to tell me if he thinks that a big concatenated input file from that approach would be equally viable.

I’m pretty sure that if I structure the records of the files appropriately, so they can be intelligently sorted in excel without scrambling the trades, that either way can work.

Post moved by on 8/25/2019 7:58 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 8/25/2019 8:11 PM (#9689 - in reply to #9687)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
This is the new breakout thread for Log Files and StradFolio discussions. I moved several relevant posts from the general discussion thread here.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 8/26/2019 7:13 PM (#9691 - in reply to #9689)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Mark and I had a productive phone discussion today. We are definitely good to go. I *think* that I’ve figured out a mechanism for collecting the data from all symbols in the FL, for the entire test period, into one big file. Which is what Mark much prefers.

Very exciting! Thanks again, Mark!

=================================

Auto-Creation from Chart or Focus List … planning in-progress …

Two new PltRtn option #’s: one file per symbol with auto-concatenation for new HRE bars (works with RT, adding HRE[1] bars) … OR … all syms into one big “static” file without ongoing HRE concatenation (must manually rename or delete big file before a new one using same inputs and barlen can be created).

Normally one/sym used with Plotted symbols, allowing new bars to be added at end of file as they appear; the big all-syms used normally with FL-Columns, for ToDo or selective click-through desired syms.

Only possible infinite-loop issue is if the one-sym Plot option is (improperly) spec’d with RT feed in a FL-Return column. Solution: popup on bar0 allows “continue” vs “stop” option … presumes that each new RT price print restarts the calc from bar zero.

Multi-symbol big-file mode stops itself, once the open-and-Find-eof search discovers the current symbol is already there. When that happens, ideally the code will rename the file to indicate it’s complete (or maybe create new then delete).

Maybe no trades for a sym, so search keeps trying. So, *final* record of file has all syms processed already. If renaming is easy, then filename can have #syms and #trades and #records.


Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 9/5/2019 4:31 PM (#9696 - in reply to #9691)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
I've been doing a lot of experimentation to proof-of-concept the Stradicator Trade-Log output file structure and functionality. Those files will load into the StradFolio spreadsheet which Mark is graciously creating. Also, they will serve as a handy way of documenting the progress of the trade, sort of like a "supercharged" vote-line Advisor output.

The details, which hopefully will be fully understandable to Mark, and at least halfway understandable to others, are posted here:

http://tradetight.org/forums/thread-view.asp?tid=1445#M9695

I've got to spend a bit more time on finishing the coding for this, but my intention is to create a small DLL that will spit out sample Log files suitable for testing in the StradFolio as Mark works on it. That DLL will have Signals in it, but they will be "faked", not generated by a stradicator. Once I complete it, I'll make the DLL available to everyone in this group, for illustration purposes. The code in it (minus the fake signals) will be folded in to every Stradicator.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 9/6/2019 2:31 PM (#9697 - in reply to #9696)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
For the filename, I'm tweaking the YyMmDd-HhMmSs spec to be more informative, and less likely to create duplicate filenames or trade-ID's.

The YyMmDd always is based on the final bar processed by the Strad calc.

The Ss always is based on the system-clock seconds at the time the final bar is processed.

For Daily & higher bars, the HhMm is also from the system-clock of final processing time.
... in this case, the Filename will use the format YyMmDd-(HhMmSs)

For Intraday bars (Periodicity < 2), the HhMm is based on the Open of the final bar processed.
... in this case, the Filename will use the format YyMmDd-HhMm(Ss)

For HA & NTB bars (periodicity < 0), naming rules are based on the underlying-bars' duration.
... the HAT Stradicator calc's its HA bars ... it "rides & trades" *on* underlying (and uses that info)


Also, to assure unique ID's for each Trade's group of records (bars), I'll create that unique-Trade ID using a similar format, but the bar-date/time info will be the Open of the initial-entry Signal bar.

====================

The reason this detailed-precision is potentially important is that several independently-run Log files that use the same Strad-pattern might be manually combined into a big Log file for the StradFolio to run.

For example, if the user wants to run the test on four distinct but separated datetime-ranges (all the same barlengths), to see how that Strad pattern works on historically bearish periods, then four separate runs must be done with only the BarWndo parameter changing. After that, the user manually Edits those CSV files and Copy-Pastes their contents into a new composite CSV file for StradFolio import. In that case, the YyMmDd (and/or the HhMm) will be the key distinction in the filename between the four files. This is a *very plausible* StradFolio use. It could be done for single-symbols from the Plot instance, or for entire FocusLists of symbols ... either way, four files would be manually merged.

Another example ... less common but possible (if Mark's StradFolio can handle it) ... possibly two Log files that are based on *different* bar-lengths might be merged. A user might trade Daily bars via one brokerage account (2x margin), and Intraday bars from a different brokerage account (4x margin), for instance. But the user might want StradFolio to intelligently apportion total equity+cash based on the sum of the two accounts. Note that trading separate accounts also makes it possible to trade the *same* symbol on the two different timeframes, simultaneously (tho I'm not sure that's legal?)

The point is this ... the timestamps help the user remember the specifics of the run | trade (rather than using random numbers). They need to be unique so that prior output files don't get overwritten accidentally. Hopefully this solution will assure that, and allow plenty of flexibility.

I've edited the reference-post to reflect this:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9695


Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
DonTurner
Posted 9/7/2019 1:27 PM (#9700 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Spectator

Posts: 3
0
Location:
USA: CA, Ridgecrest

1. oLang restricts file naming. Maybe someone knows how to code outside oLang and maybe outside of dotNet a way to automate renaming a file based on reading a field in the file containing the desired file name.

Imagining the future:

2. While reviewing appended files in Excel, a user may want to sort or group files on various parameters or results or some features not anticipated such as comments. The user can append Excel columns for features not anticipated and resort/regroup. User can save or SAVE AS to preserve the modified Excel file. A user can filter to reveal only rows of interest. In comparing appended files in EXCEL of many rows/records per file, each row needs an id to tie it to that file as distinct from rows of other files.

3. A summary/port-sim sheet could be created using a combination of VBA for Excel and linking the summary sheet to detail sheets.


Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 9/7/2019 2:21 PM (#9701 - in reply to #9700)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Hi, Don

1. All the file naming described in the post above will follow Windows rules, and not be restricted in any way by OLang (at least that's the way it's working, now ;~). The files are initially created BY the routine, and the names are carefully vetted prior to creation. The structure of the filename, unless you customize it, is highly regimented. My guess is that most people will use the defaults. NOTE: I'm in process of expanding the prior-post's explanation and modifying it to make it both smarter and more versatile. Give it a re-read now ... and when I'm done with the re-vamping, I'll delete it and re-post it so everyone gets an email notice.

2. The TradeLog file will contain comma-delimited column headers as its first record, so when the csv file is imported to Excel, all the columns (around 16-17 currently) will be neat and orderly. The StradFolio excel file itself will be VERY VERY complex, and I strongly suspect (and advise) that Mark lock it up so that people can't modify it in any way that might "break it". However, users can load the csv TradeLog files into a blank sheet and do *anything they want* with the data, on their own. I'm going to work with Mark, though, to make sure that any user-modified csv-export from a modified sheet will NOT be importable into StradFolio (there will be checksums to prevent it). I feel very strongly about this ... it's impossible for Mark (or I) to support the StradFolio functionality or results, if users are messing with the data or the analysis in unknown ways.

3. I'm confident that Mark's solution will be comprehensive as to summary and detailed reports for the StradFolio. As mentioned, the TradeLog file will document itself if independently loaded. Mark's sheet will undoubtedly include VBA macros to accomplish its work.

I can't emphasize strongly enough how hugely complex Mark's sheet will be, compared to almost any sheet that any of us has created in the past ... including me, and I've created a lot of huge doozies in the past 35-40 years. As I mentioned earlier, Mark's sheet will be *for sale* ... and the proceeds will go to him (maybe with a small percentage to me to help manage things). As such, he will be expected to provide help and support for it (written, video or forum Q/A, as he sees fit). He's *really good* about explanations and assistance, so I've full confidence in him for this. But it's essential that the tool and data remain unmodified.

Thanks for your insightful comments!

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 9/8/2019 10:48 AM (#9702 - in reply to #9701)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
TradeLog Test & Demo Mini-Stradicator "PMA"

When I get the TradeLogic file-generation code completed (soon, so that Mark can use it to start work on StradFolio), I need to pair it up with a "simple" but representative shell-DLL that creates a full complement of Stradicator trading Signals. This will be done quickly, without bells and whistles (minimal Help, plot and return options; no Gurus or Overrides; no independent Bgn/End or Fuzz tweaking, no ratcheted Cut|Grab envelopes, no Vote plots or state Band, etc).

The key purpose of this Mini-Stradicator is for all types of signals to be generated logically, for their size management to echo full-blown Stradicator concepts, and to provide the full set of TradeLog features (including popups for file name and maintenance). It will be the "sandbox" where TL code is developed ... that code will be directly useful for the planned full-bore Stradicators. After its initial release, I'll most likely expand it in a second Mini-Strad release that bootstraps the Equity-Filtering and Equity-Stat calcs ... which will activate one extra Plot and one or two extra Return options. All that code will end up being ported into full planned Strads, as a part of the paradigm.

Another BIG benefit of this approach is that I will be able to distribute it to y'all for "beta testing" (in the fairly near term). And hopefully, its simplified logic rules and operation will help all of you "ease in" to a full understanding of how the full-grown Stradicators work. During the development period, all of you who've bought into this Team will get this on a "free conditional rental" basis ... I'll keep your license active for it as long as you work with it and provide feedback ... rentals will be renewed monthly for those who actually participate. If I decide to formally release it after beta-testing is complete (unlikely), then your Buy-In discount will apply if you choose to purchase.

Please note that although this could be a "reasonably successful" strategy, its purpose is to serve as a code-development platform ... it will *not* have most of the robust logic that's in a full Stradicator ... so please don't pre-judge the "true" Stradicators by its performance. For instance, I'm sure that the PVT Price & Volatility Trend Stradicator (one of the five planned Strads) will be much better, since PVT analyzes and blends Price & Volatility via robust MA Stack+Slope logic.

Here is the link to the PMAeval Stradicator Features and Logic spec's in the Reference thread:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9703

It's important that you understand these rules fully, if you plan to do any future testing. Tell me where they are unclear so that I can rephrase them appropriately. Thanks!

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
RobertPfoff
Posted 9/8/2019 2:24 PM (#9704 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Friend

Posts: 19
0
Location:
USA: PA, Warrendale
Sounds good, I can't wait to get my hands on something. I like the solution of moving everything into the excel file. Long file names are too confusing.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 9/9/2019 3:53 AM (#9705 - in reply to #9704)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
*** PLEASE GIVE FEEDBACK*** ... this means “you” :-)

My prior post in this thread had a link to a *very important* reference-thread post:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9703

That post actually provides an ALL-IN-ONE DEFINITION of the first Stradicator that each of you will be able to install and test. It is a complete definition, but since I was the one who wrote it, I don’t know how clear it is. PLEASE READ IT AND RESPOND IN THIS THREAD IF YOU WANT TO RECEIVE A COPY TO TEST, once it’s ready.

In your response, ask any questions you need to about that post - it has orderly numbers to make it easy to reference specific things. I will revise the description to clarify it as needed, and maaaybe even change its logic a tad if someone points out an oversight or oddity.

Since I’ve not gotten any responses to posts that ask questions, from MOST of you, I’m probably going to have to identify the BETA-TEST members of this forum-group as the subset of people who want to actually interact ... of course, that’s *your* choice. But I don’t want to send Beta routines out to people and ask for testing + feedback, if they’ve not been keeping up to speed with how things are supposed to work. It would just create too much confusing during a time when I’m actively engaged in moving forward.

So, **if** you want to be part of the Beta Test group that gets the PMA Strad DLL documented at the link above, please *study* that info (just one post), and reply on this discussion thread with any requests for clarification ... or just to assure me that you've read and understood it, and are willing to be a tester that provides *timely* feedback, once the DLL is ready.

If I don't get adequate response (ie enough people to make it worthwhile), I might not create the PMA Mini-Strad DLL at all ... instead, I'd locally generate some TradeLog test files for Mark to work with.

Thanks for your time and insight!

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
RobertPfoff
Posted 9/9/2019 11:06 PM (#9711 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Friend

Posts: 19
0
Location:
USA: PA, Warrendale
I would like to be part of the beta testing. I understand the underlying logic fairly well and I am sure it will be clearer once I see it in use. My only confusion although I think I know is I find myself guessing at what your abbreviations stand for such as PMA, WTR, and LRS. I also understand your trade file naming explanation and it sounds good. I assume it will work fine with dynamic focus lists.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 9/9/2019 11:17 PM (#9712 - in reply to #9711)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
PMA = price moving average
WTR = defined in note B - wma(TrueRange)
LRS = native OLang function = Linear Regress Slope.

Don’t miss the notes at the bottom of the post!

Thanks for replying!

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
KeithParsons
Posted 9/10/2019 8:26 AM (#9713 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Veteran

Posts: 122
100
Location:
S.Africa: , Umgeni Park, Durban
Jim,
Thanks - I am pretty clear on all of the above.

Such good news on Mark's participation. I have learnt so much from his posts these past few years and now look forward to viewing his input here.

Regards,
NB: Certainly would like to be part of your Beta team.




Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 9/10/2019 3:32 PM (#9716 - in reply to #9713)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Keith Buhl responded by email to say he wants in on Beta testing and will keep up with timely responses.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 9/11/2019 4:11 AM (#9719 - in reply to #9716)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Salim emailed me to say he’d try but he might have conflicts. I’m considering that a wish but not a commitment.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 9/11/2019 8:52 AM (#9721 - in reply to #9719)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
TradeLog File Generation

The TradeLog process is finally getting some clarity. I've been discussing things with Mark, and considering a variety of options ... this post defines when and how the TradeLog will create files (from Plot or from Focus List), and how it will deal with specialized Focus List situations. This approach allows for the TradeLog routine to have totally automated control over the output filenames ... which will not only significantly simplify the coding, but also simplify the user experience and make it more orderly to maintain over time ...

A "TLS" file records all the bars of all the trades from a plotted-Symbol TradeLog run.
A "TLF" file records all the bars of all the trades from a Focus-List TradeLog run.
A "TLX" file documents all the strategy-input-specifics for a TLF run, and stats for each Symbol

... here's the why's and wherefores ...

When the user has set up the Focus List with customized Strategy-assignments that differ amongst the Symbols in it (right click on a Symbol to assign a custom strategy to it), the FL-generated TradeLog file can end up with trades from a variety of different Stradicators altogether ... or trades based on differing input-patterns that use the same Stradicator. Virtually any aspect of the backtest-run might differ ... even the bar-lengths (1-day, 20-min, etc) can be custom-set for a Strategy, so that a given FocusList-driven TradeLog might include trades based on Symbols which use differing Stradicators, differing input-param-patterns, differing bar-lengths, differing historical time-windows, differing order directions, differing Order Types (and of course the Strategies can have differing TradePlans too). WOW! The only limitation seems to be that a particular Symbol in a given profile's FocusList can only have *one* of those assignments at a time. However, even that limitation can be circumvented by creating separate TradeLog outputs driven by alternatively-structured Focus Lists in multiple Profiles, where the custom-Strategy assignments for the same Symbol(s) are different. I'm sorry, but hey ... DOUBLE-WOW! (Note that a Portfolio which uses the latter merging-feature *cannot* be handled by PortSim - nor can PortSim handle dynamic scaling in/out, or multiple barlengths, etc).

By contrast, when a TradeLog file is generated directly from a plotted chart, it's dedicated to that one Symbol, with one particular combination of Stradicator input settings, using the current barlength. This allows for the Filename to be automatically generated with a useful and informative summary of the model.

If the FL does have symbols with custom-Strategy assignments, then the FL-processing will involve more than one Stradicator, or the same Stradicator with more than one Input-Param's Pattern. A decision has recently been made to include the Bar-Length (ie 1 day, 30 min, etc) as a std-paradigm slider in the Stradicator, so that important criteria, along with the order type (MoO, MoC, Mkt, BoO) is "known" to the Strad, and to the TradeLog routine that the Strad calls.

The presumption is that AutoTrade is being used to mechanically automate these runs. AutoTrade's time-window settings are such that a given AT run can't have a mix of MoO's, MoC's and BoO's ... however, Mkt can be used with MoC & BoO. So, there are some possible custom FL strategy-assignments that will be disallowed by the TradeLog runs (a popup will appear to explain).

However, there are plenty of legit custom Strategy assignments that could be mixed ... that's a topic for another (long) post. The comprehensive TL-file definition (see link below) provides for this ... a separate "TLX" file holds an ID record for each unique Strad+Patrn that the FL Sym's utilize ... which provides a complete expansion of the Patrn inputs, as well as handy statistics about how many Symbols, Trades and active Bars are engaged with it in this historical model.


Check out all the details in this Reference-Thread post:
http://tradetight.org/forums/thread-view.asp?tid=1445&#M9720

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
RobertPfoff
Posted 9/11/2019 10:36 AM (#9722 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Friend

Posts: 19
0
Location:
USA: PA, Warrendale
Sounds amazing. The ability to analyze different stradicators in different time frames is groundbreaking but the one I am most interested in is analyzing different market orders. I have always felt the MOC was the way to go but no way to study it.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 9/12/2019 8:17 AM (#9724 - in reply to #9722)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Hi, Robert

You're right ... the differences in how MoO works, vs MoC, has occasioned a lot of discussion.

You might be interested the explanation I just posted, here:
http://tradetight.org/forums/thread-view.asp?tid=1448

Stradicator design, when push comes to shove, presumes that the TP order-type rules dictate limitations ... MoC and MoO can't be mixed in together.

Also, for now at least, Strad order-specification options presume that AutoTrade is being used to mechanize execution (rather than manual or OPilot or some mix of the those with AutoTrade).

So, Strad TP's with MoO orders *might* also use SM &/or Limit &/or SL orders, but never Mkt or MoC orders.
Conversely, Strad TP's with MoC orders *might* also use Mkt &/or SM &/or Limit &/or SL orders, but never MoO orders.
Finally, Strad TP's that use BoO orders *might* also use Mkt &/or SM &/or Limit &/or SL orders, and potentially could use MoC orders (though I can't imagine a reason for that), but never MoO orders.

Currently, the Strad slider-paradigm allows the user to choose MoC instead of the "default" MoO route, by making the BgnVot slider negative (req's Powr or Cstm version). The plotted Signals and Equity calcs change, accordingly. In either input case, the worst-case Fixed Broker StopMarket order is in force. I'm currently debating whether to include a second Fixed Broker Limit order to capture extreme profit-moves, but for now, that's not in the picture.

If the Stradicator sees that the Data Periods setting in use is Intraday, then the "default" MoO calc's require a TradePlan to uses BoO orders ... and a negative BgnVot slider input, in that case, calls for the TradePlan to use Mkt orders. Again, SM &/or Limit orders might be part of either TP, but for now the Broker worst-case-loss-threshold SM order is the only one that the Strad paradigm is modelling.

For the Intraday case, the Strad needs some "tricky" code to model the negative-BgnVot-input Mkt-slider case. Even though the TP is using a Mkt order, the INTENT of that option is for the Strad analysis to *ignore* all price-prints that occur early in the formation of the intraday bar ... the Strad only does the calculation when the HRE bar is *almost complete* ... therefore, the calc is a reasonably approximation of a "BoC" order (which N does not offer ... just my terminology) ... using a Trade Plan that has Market orders tied to that logic.

The current Help panel "hints at" how these BoC and MoC orders are processed:
... "Powr/Cstm MoC override -MmB: B= neg-slider val; Mm=#minB4barC"
What that cryptic abbreviation means is that you can type in a negative value with 2-3 digits. The ones digit "B" is evaluated as a normal slider input, defining BgnVot thresholds, and the extra tens+hundreds digits are used to specify how many minutes before the actual Close of the bar are reserved for analysis of Signals. That time-window for the calc is managed by checking the System clock on your local machine ... which hopefully is properly set ... and presumes the RT feed you get has minimal lag.

To properly implement these time-window rules with Mkt orders to create "BoC" intraday-bar orders, the Strad presumes (requires) that you use RealTime feed.

To properly implement Strad modelling of MoC daily+ bar orders, you do NOT *have to* use Realtime feed ... instead, you can use the AutoTrade calculation-time input to "ignore" the prices on the Daily bar until very close to the exchange Close time. That is, if you have RT feed, or if you have EOD feed that you manually ToDo- update several times during the day, the bar's OHLCV values are ignored until you hit the time-window defined by AutoTrade.

So ... the Strad paradigm provides automated support for ALL possible order type combos, EXCEPT mixing MoO and MoC|Mkt|BoO (TP, AutoTrade disallow this), or mixing Mkt and BoO (Strad "reserves" Mkt order use to implement "BoC" calc's).

Btw ... the distinction between BoO and BoC is actually sort of a silly one for intraday bars, since technically the time-difference between them is nil ... the very next print after the Close of one intraday bar is the Open of the next bar ... there might be only a millisecond between them. So ... although I've included plans for "BoC" support in the Strad paradigm, it's low priority and might not appear in the initial releases (or ever, for that matter, if no one really wants it or some other need for its existence is discovered).

Have fun!


Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 9/12/2019 11:34 AM (#9725 - in reply to #9724)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
It appears at this point that I can pragmatically count on maybe 3 people for doing beta-testing and also providing timely interaction. Since I was hoping for at least five and hopefully 7-8 out of the 11 in this "buy-in" group, I'm reconsidering whether I should create the PMA stradicator, rather than just moving ahead to get CVW to the point that it can work with TradeLog, and release yet another CVWeval beta, which would have a limited-time license. Going the CVWeval route probably means it will take a bit longer before I release a testing beta, but means the distribution version will come sooner. The side-benefit is that a CVWeval beta would allow testing of "actual" Stradicator features besides just TradeLog. Hmmm. And maybe if I do that, more people would be willing to commit time and priority to work on the beta. Probably that's the best way to proceed.

So ... I'll get the TradeLog engine working ... my goal is to make it a callable routine. As I do that I'll cobble together a really crude shell routine that creates barely-sensible signals, which allows me to generate TradeLog files for Mark to work with ... but those signals aren't expected to be viable for actual trading. That way, he can get started soonest on StradFolio work.

Then, once an adequate spectrum of Strad-paradigm features are implemented in CVW, I'll consider releasing a second CVWeval for people to beta test.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
DonTurner
Posted 9/12/2019 1:23 PM (#9726 - in reply to #9724)
Subject: TrdLog-Files for StradFolio & StradWiz



Spectator

Posts: 3
0
Location:
USA: CA, Ridgecrest
I recall preferring oPilot to AutoTrade because oPilot allowed a delayed real time of about 20 minutes. So, I hope Strads will allow use of oPilot.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 9/12/2019 1:44 PM (#9727 - in reply to #9726)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Yes Strad's will work with OmniPilot, which is more flexible than AutoTrade. But it's up to you to program OPilot to operate in an an appropriate way for your param-input choices. I'll provide instructions for AutoTrade applications.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 10/2/2019 10:38 AM (#9729 - in reply to #9727)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
I've been delayed a bit for Barry to return from vacation, and catch up with his emails. I've now received clarification about the way that the FL and AutoTrade processes symbols that have "custom strategies" assigned to them, notably when the strategy in question has a "custom timeframe" specified for it in the strategy builder window.

Prior posts and lots of back and forth thought had presumed that if the current timeframe was, say, 60min (ie the chart shows those bars), but if a custom strategy was assigned to the symbol via the FL right-click menu, AND if that strategy had a custom timeframe assigned to *it* of say, 30min (only) ... AND if 30min bars were loaded via Data Periods, as well as 60min bars, and both bar-lengths were checked as "voting" ... THEN, somehow, OT would properly process that strategy for that symbol for the 30min timeframe, while the other symbols in the FL that didn't have custom-assigned strategies would use 60min bars with whatever active strategies were checked via the chesspiece.

Also, I'd presumed that PortSim and AutoTrade might hopefully somehow integrate all that, based on the Analysis run.

NOT.

Sigh.

Barry said that in those circumstances, the 30-min-only custom-strategy would be ignored, since the current bars were 60min ... that is, the entire SYMBOL would be skipped over. For Analysis, for PortSim, and for AutoTrade. Apparently, the "custom timeframe" feature of the strategy builder window is there to EXCLUDE processing of a strategy for a symbol, if that timeframe is not "current". How useful! (LOL)

Double-sigh.

The GOOD news is that this could simplify the task for logging ... there's no absolute OT-options related need to identify the timeframe on a symbol-by-symbol basis in the TLX file, since any symbol in the FL that uses a custom strat which does NOT have the current timeframe will be *skipped*.

I *could* keep the barlength in the filename and in the StradID-record, so that Mark's StradFolio sheet can correctly discriminate between multiple barlengths *IF* the user chooses to merge several TL-run-outputs in to a composite file. To actually trade this scenario via OT and AutoTrade, you'd have to be running OT on two separate machines simultaneously ... and *might* need separate brokerage accounts, since I'm guessing that OT (or IB) won't allow two machines to be logged in to the same account at the same time.

QUESTION (#1): do ANY of you think this multiple-timeframe, multiple-machine StradFolio-analysis scenario is important to support? If so, why?

The other offshoot of this was the possibility of creating a new Stradicator-paradigm standard input to specify the barlength being used. Benefit to this was that in the case of a Profile that has multiple BarLengths loaded via Data Periods, this provided efficiency-improvements by explicitly skipping past the calcs for the other barlengths.

HOWEVER, there's another method for doing this that is simple to implement (I'm using it already in many routines), that does *not* require a new input parameter. I've built in a test to see if the number of bars loaded is less than 10, for any timeframe that the routine is being asked by OT to process. If <10, the entire calc is skipped.

To implement this, the user dedicates a Profile to one particular timeframe-barlength (such as Daily), and sets Data Periods for that barlength to an adequate number of bars for warmup and desired output history ... and sets any other barlengths to have just ONE bar loaded (or simply delete those timeframes). Since OT for some arcane legacy reason refuses to allow the Weekly timeframe from being deleted, just set it to 1 bar (if you're not trading Weekly bars). Voila!

So, no need for that extra new input.

Updated info re TLF, TLS and TLX files will be coming.

I just today got some additional info from Barry. He says that it IS possible to run AutoTrade on two (or more) different RT profiles at the same time, as long as they are running on two different machines, EACH of which has a paid-for independent RT feed. IB *does* permit multiple simultaneous access to a single account, *if and only if* the connection is via FIX protocol (ie using GXTrader, not TWS). However, there's danger of a potential PROBLEM, if the two+ machines have some common Symbols in their focus lists ... it's likely that sometimes the Stradicator + BarLength running on machine A might initiate a trade on symbol ABC, and then a bit later, while that trade is still active, the Strad+BarLen on machine B might initiate a different trade on the same symbol. Neither machine would know what the other is doing ... but the Broker would treat it as one big trade with multiple scaling in/out rules. Barry says that OT somehow recognizes that the trade is "unmanaged" in that case, and sends out emails to the user warning them of the conflict). It *may be* that the thing which triggers "unmanaged" wouldn't occur when the two sub-trades were being driven by Stradicator-TradePlans, which are carefully managing the various order Sizes. Or, it *may be* that it would create alarms nonetheless. There's no easy way to tell. So, for now, presume that if you use multiple machines + feeds to trade into a common brokerage account, you should NEVER have any overlap of the symbols between those machines. (And no, sorry, there's no easy way for me to automate that check ;~)

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 10/2/2019 1:35 PM (#9730 - in reply to #9729)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Re: tuning input-param patterns for Long-Only vs Short-Only vs BothLS

Logically, it makes sense to do this (I presume all of you know why).

The question is ... can OT practically support the USE of this distinction?

Presume that AutoTrade can only run on one (active) Profile at any given time, to a given Brokerage account.

Presume that some of the symbols in that Profile's Focus List, on a given bar, might be signalled as a Short entry, IF the input-pattern is tailored to Short-Only runs.

Presume that some OTHER symbols in that Profile's Focus List, on a given bar, might be signalled as a Long entry, IF the input-pattern is tailored to Long-Only runs.

If somehow things could be set up to handle this simultaneously, it would seem to be the best of both worlds.

BUT ...

The FL doesn't allow the same symbol to appear twice, once with a LO strat and again with a SO strat ... so the problem is that we don't know ahead of time which symbol would be potentially signalled for entry in which direction ... therefore, even if we had two different tailored Stradicators in place, one for LongOnly and the other for ShortOnly ... we'd have to *manually right-click-reassign* them on a symbol-by-symbol basis, for each new HRE bar, based on some (unknown) criteria.

This is not practically feasible, and definitely not backtest-able or automate-able.

We can, of course, spec in the Stradicator that BOTH L|S are possible, and come up with a "compromise" input-pattern for Both ... but intuitively this might not be as good as using two separate patterns.

=========

As things stand, this means that we likely will dedicate a given Profile to BothLS or LongO or ShortO, and all symbols traded in that profile will use the same directional option(s).

If you're trading Daily bars, via MoO orders, then *maybe* you could run Autotrade on the LongO profile for a given FL, and submit those orders, then change profiles and run Autotrade on a ShortO profile for the same list, and submit those orders ... but I've got a feeling that things would get discombobulated within OT and/or at the broker in that situation. So, forget that option.

I can't imagine anyone would want to trade ALL their symbols ShortOnly. At least, not for any extended period. So, BothLS (not optimized for either direction), or LongOnly (optimized) would be the two viable choices.

=========

Here's the NEW IDEA ...

Maybe I can come up with some kind of user-friendly way to provide two different input-spec's for Long vs Short trades. That is, somehow, for each bar where no trade is active, check if a Long trade is signalled by the LongOnly spec ... and if not, check if a Short trade is signalled by the (different) ShortOnly spec.

Then, if either trade starts, the relevant spec would manage the trade to completion.

A further "twist" might be to allow an entry signal in the *opposite* direction of an extant trade (ie a reversal) to end that trade. Strad's currently do this, but use the same input-pattern-spec for both directions. In this scenario, the Long trade, managed by the LongOnly spec, could be interrupted by a Short-Entry signal from the ShortOnly spec.

Keep in mind that, due to OT limitations, a "pure same-bar reversal" is not possible for automated mechanical trading ... the closest to that allowed is for you to exit on one bar and enter in the opposite direction on the next bar.

----------------

So ... how might this "dual-processing" for separately-optimized LO and SO patterns be managed?
And ... is the value of this significant enough to implement? (if so, it would be in the Paradigm)

First: I am *not* going to double the number of inputs (just too scary for the user).
Key: the Master-slider selection contains a "map" to all pattern-ID inputs
So: the Master input might spec the Long pattern, and the Guru+Xprt inputs spec the Short pattern (or vice-versa).

If this was implemented, then it follows that the user would figure out the "optimal" LongO pattern and the "optimal" ShortO pattern from separate test runs, then combine them.

But that means the user must have a way to "save" their custom pattern for one direction so that the Master input can access it via some specific Index number ... while actually modelling the other direction with the Guru+Xprt inputs at the same time.

IMPORTANT QUESTION (#2): do you consider it useful and important to be able to spec different input-rules for Long vs Short Trades (identifying &/or managing them), as long as it's easy to do from a user standpoint? (question #1 is in prior post)

==========

Presuming that the majority of you who choose to respond say "yes" to that question, then here are the ramifications that I've been cogitating about for some time now ...

1. User needs an easy way to "save" a customized input-pattern and "assign" it to a Master index-number so that it can later be used for the LongO or ShortO part of the trading model.

2. Code needs to be able to independently process the two different spec's, both when searching for initial entries to determine a trade direction, and when managing an active trade.

-------------------

Of those two, the first is by far the easiest. The routine currently provides a "function-call-string" output popup panel ... once the custom pattern is determined for one of the directions, the user would simply copy the string from the popup panel and paste it into a Master-Spec Text file that defines the input-pattern to be used in relation to a particular Master-slider input-number (custom specs might utilize any Master input from 1001 to 9999, for instance). Format:
IndexNum = FunctionCallString

-------------------

On the other hand, the requirement for the code to properly evaluate and handle the two custom-directional-patterns is *not* simple. At least not that I've been able to figure out so far. I can think of two alternatives to deal with this (note that these are "invisible" to the user):

a. Nearly double the number of lines of code, dedicated to doing two separate calc's and then resolving them together. This is the brute-force approach. It would be efficient but very inelegant. And would take a lot of extra monkey-typing (and monkey-typo's). If this turns out to be the "only way", I'd probably NOT do it.

b. Do the calc's for the Guru+Xprt inputs in the code for one direction, and CALL the stradicator (from within itself) with the Master-slider opposite-direction inputs, to determine the alternative. Then write a relatively small amount of new code to "decide" between them for Entries, or for "reversal" exits. Since the "Signal" return-value output is already set up to report events and status from the Master-based pattern-model to the calling "shell", then as best I can tell from just thinking through how I'd have to modify things, this would be fairly simple to do.

-------------------------

So, using "b" as the assumption ... presuming that the "benefit" is clear related to the Question that I asked above ... how do I assure there are no meaningful offsetting "cons"?

The OLang parser has some tricky nuances which I've described in detail elsewhere, regarding how "efficiently" a Call to another custom routine runs. All of the param's in that "efficient" Call *must* be either actual values, or static variables, or input-params from the calling program. Also ... that Call will *always* be executed by the calling routine, even if the "extra custom direction" run is not needed (ie how the Stradicator works now).

I haven't explicitly tested it but I'm 99.9% sure that to satisfy the "efficient" rules, I *cannot* use variables in the Call whose values are read in from the Master Text file. So, that means I need to reverse the logic described earlier ... the explicit Guru+Xprt input-parameters (NOT the Master-index) would be used to drive the alternative-direction Call ... and the Master-Index input (in this dual-track situation) would be used to drive the calc's in the "shell" layer code.

So far, so good.

For the "normal" case where the Master is being used as an upper layer to the expert logic (ie how it works now), with nonzero Guru+Xprt param's optionally overriding the Master selection ... so one pattern is being used for whatever directional approach is chosen (Both, LongO, ShortO) ... in that case, the way that the "efficient-calc" Call method works would STILL RUN the Call, ignoring the Master input, using whatever nonzero Guru+Xprt inputs were provided. In this case, the program would "ignore" the results of that Call ... but the time it takes to calc it would still be a factor. This isn't a show-stopper, but it's something I'd like to avoid.

To avoid the unnecessary calc time in the "simple case", I'd need one of the explicit inputs to "contain" a flag that says "don't do anything, called-instance ... just skip over all the calc's and return a zero value". There is an EASY way to do this ... since the Master, which is an explicit param, is included in the Call ... IF that Master param is NOT NEGATIVE (ie a special dual-direction run), then that will be a flag to skip quickly thru the Call-calc's).

Whew. Maybe that gives you a headache to read, but it's actually *very simple* to implement (at least from a prelim planning think-thru perspective).

RECAP:
If the Master is a negative number, evaluate two separate directional patterns, using Call
If the Master is zero or positive, use it as the starting pattern that Guru+Xprts can override

------------------

The remaining "moebus-strip-twist" is for the Stradicator to know whether it's currently calculating the outer "shell" call (which ignores the negative Master input and uses Guru+Xprt inputs), or whether it's currently calculating the inner "called" model based on the negative-Master's pattern from the Text file.

Fortunately, that's also easy to solve ... the final "OutputReturnHelpPlot" parameter simply needs a dedicated value to flag the "called routine instance". That is, the Call statement will hard-code a value which will specify a non-plot, Signal-return, negative-Master text-file-driven set of inputs ... while the Shell instance will use the actual OutputReturnHelpPlot value that the user specified.

==========

OK ... hopefully most of that was clear to some of you. The bottom line is that, from what I've been able to figure out over several days of mentally horsing around with this, DUAL-PATTERN CUSTOM-LONG+SHORT RUNS ARE FEASIBLE, without a "major" amount of extra coding, and as a part of the standard Stradicator paradigm.

QUESTION (#3): Do you think this is a useful approach that I should follow?

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
SalimHira
Posted 10/3/2019 5:02 AM (#9732 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Veteran

Posts: 183
100252525
Location:
USA: MD, Columbia
QUESTION (#1): do ANY of you think this multiple-timeframe, multiple-machine StradFolio-analysis scenario is important to support? If so, why?

I think its important to read the market in Multiple timeframe, as I use triple variation of Time, Non-Timed (tick and volume chart), and Heiken-Ashi to gauge the price action rhythms for anticipated price turns. With this kind of setups, you get visuals of how fast or slow and the range of price in fluctuating, and make decision accordingly. Just not sure how automation can interpret this :-).

I would not be a proponent if it is Time-based chosen in multiple timeframe only - here One timeframe is sufficient to trade of trader preference.

So - would you ever trade part of your account on daily bars using Stradicator A, and trade another part of your account on 65m bars, using Stradicator B? If so, and if Strad’s A & B happened to come up with trades that partially overlapped in time for the same Symbol, would you ever consider modifying the position size of the existing trade based on A daily, if the B 65m trade started during that? That’s the scenario I was trying to describe.

Hummmm, personally (that's me only), I have two-sided opinion on this factor. From what I am reading here, your suggestion is that every "directional move" (i.e., corrective - in smaller time-frame) will be noticed and taken into account to trade or not based off some kind of confirmation.

For beginners, I'd stay on one-time frame and one-directional sided strategy. Thereupon, once comfortable and experience gained, I'd transition to your methodology as suggested. So, the answer is YES, and it'd be really cool to trade as learned professional by taking every opportunity coming my way :-).


----------------

IMPORTANT QUESTION (#2): do you consider it useful and important to be able to spec different input-rules for Long vs Short Trades (identifying &/or managing them), as long as it's easy to do from a user standpoint?

Absolutely YES, imho, from my stand point if I have understood correctly.

Usually, as you have explained, as I understand... when one directional move has not come to an end (exit), while the other directional move (entry) has begun when different spec input-rules are utilized.... there is also a "reasoning" behind this diaspora about on having separate Longs and Shorts strategies - meaning, in simple terms, when you have a Long entry positions, traders usually do not want to exit sooner (expecting price will go higher, simply a correction) ... while when in Shorts position, buyers usually do not usually want to step in front of the runaway train sooner either till some kind of confirmation... so, there is a some kind of crossover in logic, and its not simple to explain as a trader cannot see this in a BothLS strategy, that includes, to difficulty to code it as you have mentioned herein, and why a Long Only, and Short Only (i.e., liked your thoughts on this) strategy is important to implement too.

QUESTION (#3): Do you think this is a useful approach that I should follow?

As I attempt to follow the read, you seems to have thought out the logic as best as one can get to implement, imho, as I can't think of any better suggestion.

The user aspect is that of keeping the Master Text File up to date as described, adding to it as optimal mono-directional patterns are found. Did you fully understand the mechanics the user would need to to for that text file manipulation, and do you consider it to be reasonable, or too confusing?

I somewhat got lost in the mechanics as it was explained. Not confusing, but could not follow cohesively and interpret of what was being attempted to convey the message.

OK here are the steps the user would take:
1. Master = 0; experiment on plot to find combo of Guru + Expert settings that work best for Short Trades; once obtained, copy the function-call string from the second panel of Help Popup.
2. Open the Master Text File (in an SDK folder) using notepad, and insert a line; Paste the string that you copied in #1 into that line; on the left side of the line, type in “####=“ before the string, using any unique four-digit number to act as the index for that Pattern; save the file.
3. Master = 0; experiment on plot to find combo of Guru + Expert settings that work best for Long Trades; once those are set, type in the #### from step 2 as a negative number in the Master input to activate the optimized Short analysis in conjunction with the optimized Long analysis.

That’s pretty much it. Please ask questions if you don’t understand. If this is too complex, the whole idea is a waste of time. Thanks.


Ahhh, okay, I get it now, quite simple :-), and user-doable. Kudos, Thumbs-Up. hummm, this is really cool now that I think of it.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
RobertPfoff
Posted 10/3/2019 10:17 PM (#9733 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Friend

Posts: 19
0
Location:
USA: PA, Warrendale
1. I don't foresee using multiple timeframes, at least in the near future

2. I generally try to trade only in the direction of the dominant trend, but I could see real value in using an entry in a short only profile as a reversal exit from a long only trade, particularly with the ability to back test if this is a better exit than the standard exit.

The current Strad logic already uses "reversal" logic to exit, based on the same input-pattern ... if you're not going to create a custom pattern for actually trading each direction, then the existing logic based on a common pattern should be sufficient.

3. Sounds good, although I don't fully understand why I would want to do this, as long as it is not too difficult to implement

Sounds like my posts may have focused too much on the details, and obscured the "big picture". Please note that the Strad's are intended to provide for *totally self-contained automated mechanical trading* (though you can use them in other ways if you choose). As such, *ALL* considerations that factor in to trading decisions *must* be possible to model *within* the Stradicator inputs.
So, your comment in #2 above re "trading only in the direction of the dominant trend" is *part* of the Stradicator logic ... that directional-trend rule would either be implicitly handled by the Stradicator's internal rules ... OR would be handled by the optional "Filter" inputs that you can specify via Guru-param overrides (discussed in detail elsewhere). Keep in mind that the Guru-Filter interface supports *multiple simultaneous* filter rules, which can be anything from a fancy TradeTight routine such as MTV, or just a simple, short OmniLanguage routine that *you* create (much like an OScan rule). Therefore, the "dominant trend direction" determination is *part of* the Stradicator model.
Your #2 comment does imply that you sometimes trade Short and other times trade Long (depending on trend direction). The question about separately customizing the Strad patterns for Short vs Long trades is that WHEN your specified Strad Guru-Filters identify a Short trend, then does it seem valuable to you to use a Strad input-pattern "custom-tailored" for Shorts, to find Entries and also to manage those trades ... and vice versa, when Guru-Filters identify a Long trend, then should the Strad input-pattern used be one that is "custom-tailored" for Longs?
The alternative is to use the same input-pattern for Shorts and Longs ... in that case, the Guru-Filters would still be in play, but the Entry-ID and trade-management rules would not be directionally-distinctive.
Reconsidering, with all that in mind ... how valuable do you thing it would be to have the Strad's provide for separate Long vs Short input-pattern models, to be used together in a common "combo long+short" run?



Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 10/4/2019 1:55 PM (#9734 - in reply to #9733)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Everyone:

Please note that when someone posts a reply to Questions that I ask (or other Comments), I'll often be responding by Editing that post and adding comments in Blue, so that the immediate context is maintained rather than being separated by other intervening posts. So, please always click on the link from emailed notifications, rather than just reading the text in the email.

Often my "blue" comments will encourage further response from the person who made the original post ... in that case, please Edit your original post, and add your comments after my blue ones, using "[" then "red" then "]" at the beginning, and "[" then "/" then "red" then "]" at the end.
Thanks!

(two prior posts illustrate this)

Example: your initial post with black text ...
My response to your post's comments
Your response to my response

(Text Color Changes.png)




Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION


Attachments
Attachments Text Color Changes.png (5KB - 1 downloads)
Top of the page Bottom of the page
JimDean
Posted 10/4/2019 2:13 PM (#9735 - in reply to #9734)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
I've just had a "eureka" moment ... an idea which adds a LOT of value to the TradeLog-file output, beyond simply a channel to feed the excel StradFolio analysis.

Part of the Strad paradigm will be the availability of many Performance Statistics ... typically intended for custom Focus Lists &/or OmniScan uses, to help determine which Symbols have the most attractive recent-historical activity. I've listed the available Return-value stat's here:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9645
... be SURE to review that post ... there are MANY COOL NEW METRICS being provided ... I've updated it (in blue) with some new hopefully-more-understandable label-abbreviations.

The "eureka" idea:
I can output those extremely useful Performance Statistics to a FILE, so that you can have a permanent copy of them, and/or import them to your own Excel sheet for evaluations.


The TradeLog file provides a perfect container for this ... the Stradicator tracks all those Stats during the processing for each for Symbol ... it's very easy for me to tell the Strad to pass most all of them directly to the TradeLog routine, once the process hits the HRE bar.
The final Record in a TLS file (single-Symbol TradeLog gen'd from a Plot) will provide TWELVE relevant performance-metric stat's for that run. (details for all bars-in-trade precede that in the TLS file)
The Symbol-Record in a TLX file (short TradeLog "index" for multi-sym FocusList runs) will similarly report those stats, for each FL symbol. (details for all bars-in-trade are stored in the TLF file)

If you don't "get it" as to how powerful this is ... it's like getting a "filedump" of a multi-column FocusList with complete Stats ... then please ask questions. I'm quite excited by this, since the greater-than-expected effort to get the TradeLog-file routine working now has even greater benefits, for very little extra code.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 10/5/2019 3:09 PM (#9739 - in reply to #9735)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
During CVW devel, I’ve changed the way that the “output Calc bars” window is specified. MTV used two inputs, one to define the window-width, and another to define how much before the HRE that window ends (ie shifting the window left). This was a versatile approach but I found a way to simplify it without compromising it’s usefulness, so that it could be handled with just one input slider.

However, in order to fully realize the significant benefits offered by the TradeLog file and StradFolio analysis, a greater degree of “backtesting” specificity is needed. The most straightforward way to deal with this is to return to the two-input approach that MTV uses. Doing this also provides simpler and more explicit spec of trade direction options (LongOnly, ShortOnly, BothLS, CustomLS - Both uses a common input pattern, while Custom uses the recently-discussed discrete optimized patterns for Long vs Short). Jury is still out on CustomLS - I’ve only gotten two responses from the team thus far.

The resurrection of the extra input will replace the final gray-separator parameter that initially was intended for BarLength - but info that I got from Barry makes it clear that is not needed.

I also recently noted how helpful the TradeLog file will be, since it has 12 sophisticated performance metrics about each Symbol run in a given Strad+PatrnID model. I mentioned that the file could be imported into another type of Spreadsheet, to evaluate those metrics (independently of the StradFolio analysis).

I’m going to call this alternative spreadsheet “StradWiz” - it will provide a turbocharged alternative to Strategy Wizard, allowing all the benefits of the Stradicator Paradigm to be evaluated and optimized, using a refined set of metrics.

So - both of the essential OT tools: Portfolio Simulator and Strategy Wizard, will be replaced by parallel spreadsheet tools, that support the full set of Stradicator Paradigm features.

Whee! It just keeps getting better and better!

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 10/5/2019 4:32 PM (#9740 - in reply to #9730)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
This is a followup to the prior post here:
http://tradetight.org/forums/thread-view.asp?tid=1446#M9730
… which presents the idea of integrated “CustomLongShort” modeling, using a negative-Master input in conjunction with a complete set of Guru+Xprt inputs that are tailored for the opposite trade direction than the Master uses.

After some additional thought about how to implement this, I think that the tailored L/S distinctions should be restricted to the “Paradigm” inputs - VoteGuru, BgnVot, EndVot, FuzVot, and CutGrab inputs. The meaning and rules and code behind those inputs will be “essentially” the same across all Stradicators.

In contrast, the other inputs after the Master and before the VoteGuru that control the “core logic” which differentiates the various Stradicators (CVW, HAT, ADX, MMD, PVT, etc) would NOT differ between the Long and Short Custom models.

In other words, the neg-Master CustLS directional tweaks would be built upon on a common “core” playing field “indicator” … for CVW, the core indicator is based on the CumMeth, TimeGuru, MAspeed, MAmeth, and MAslope inputs. The L/S distinctions will therefore be “interpretive nuances” rather than major playing-field differences.

There are a lot of benefits to this:
1. Plot and Return output automatically adapts - no need for creating extra options
2. Signal dots and CutGrab envelopes look the same, but are in different locations
3. The EquityFltr, WndoWdth, BarsB4hre, and Output param’s work the same way
4. The Paradigm code-portions will be complex, but will readily “port” across Strad’s
5. Since fewer calcs change between L & S rules, the entire model is easier to grasp
6. This approach will run faster than if the neg-Master could vary the core-inputs also

=========

If the custom L/S distinctions are limited as described above to the four Paradigm Vote & Envelope inputs, AND if the powerful but complex custom-version manual-overrides for those inputs are rearranged a bit to support Long vs Short variants, then there’s another more “transparent” way to interface with the user.

Refer to this post if you need a refresher about how the pos/neg/override inputs work:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9625
I've updated it to show the two new sliders, and rearranged the overrides for CstmLS

The normal “slider” inputs for those params are all simple +/-integers. These four inputs could allow *decimal* values as an option - that is, instead of simple inputs: BgnVot= 4, EndVot= -3, VotFuz= 5, CutGrab = -4 … in which case those values apply to both L & S Trades … the CustLS model might use inputs: BgnVot= 4.5, EndVot= -3.2, VotFuz= 5.3, CutGrab = -4.2 (random example).

In the decimal input scenario, the +/- feature flag (explained in the “Negative” middle section of the post linked above) would apply equally for L & S … the integer value would be used for the L model and the decimal value would be used for the S model. The expert meanings of the values from 1-5 would be the same.
Comprehensive control of these inputs is available for the CVWcstm routine using manual overrides ... the prior link shows how they've been rearranged to accommodate the separate L/S models.

The biggest advantage to this method is that the user has immediate fine-tuning control over both directions, without having to figure out which -Master index to use, or having to save another -Master record in a text file. Much easier to fiddle with.

In either case, the popup Help panels will fully document what inputs are used for each direction, and their ramifications.

Please consider these two approaches (neg-Master vs decimals+LSoverrides), and tell me which you’d prefer, and why.

later ... lots of additional though about this ... explained at link below ... link above updated for that new approach: http://tradetight.org/forums/thread-view.asp?tid=1444#M9743

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
SalimHira
Posted 10/6/2019 8:04 AM (#9742 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Veteran

Posts: 183
100252525
Location:
USA: MD, Columbia
I’d prefer the decimal option as easy to remember and tuning, better adapting to user preferences in fine detail as you pointed out.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
KenWilsdon
Posted 10/7/2019 5:06 PM (#9744 - in reply to #9740)
Subject: TrdLog-Files for StradFolio & StradWiz



Friend

Posts: 48
25
Location:
: ,
You present a compelling case for the decimals+LSoverrides option. I, too, think that this would be the better way to go, with more custom control and flexibility, as well as simplicity for the user.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 10/10/2019 4:42 PM (#9749 - in reply to #9744)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
This has been a long time coming. The TradeLog file planning, tweaking, coding, testing, refining, and polishing is now COMPLETE.
There's a fully-functioning generic TradeLog "subroutine" which will work with any Stradicator without having to be modified (as long as the Stradicator has <= 15 inputs, which is a firm design goal for me). The "complexity" of the code is mainly related to doing significant file and folder creation and maintenance, *so that* the user doesn't need to.
I also created a test shell-routine that "calls" the TradeLog engine using the same syntax that a Stradicator would, albeit with unchanging "dummy" values assigned just for checking. The test routine does *not* vary things from bar to bar or determine entries or exits, etc ... it just sends values to the TradeLog engine in an appropriate way. Believe it or not, there are a few tricks needed to get this to work correctly.

This post is not intended to be a tutorial in any way ... I've got to update some documentation which will be a decent outline though.
Basically, to create a TradeLog file and fill it with info, the user simply changes an input in the Stradicator to tell it to dump the results to the file ... this could be a Strad plotted on a chart, or one assigned to a Focus List. That's it ... no other steps are required.
Once that "activate TradeLog" input is set, then ALL subsequent Stradicator recalc's will attempt to dump information to the TL files (there are two of them), until the Strad input is changed to turn off the TradeLog-output.

There's only one "rule" ... once the output has been saved from a particular Stradicator "pattern", for a particular barlength-timeframe (such as daily), for a particular Symbol ... then the engine will refuse to repeat the info-dump to those same files, for that Symbol.
When it encounters that situation (request to dump an existing Symbol again), the engine is very friendly ... it gives you three choices in a simple Popup box: Yes/No/Cancel

YES: Rename the existing TradeLog output files (all data for all symbols for that stradicator pattern and current timeframe) with the suffix "-Arc.csv" (for "archive") , and create a brand new pair of files with just the info from that one Symbol in it ... to which other symbols can be added if the need arises.
... OR ...
NO: Leave all the files as-is, and Skip the dump of that Symbol, then continue. The
... OR ...
CANCEL: Abort all present and future additions to that pair of files, for this Symbol or any other Symbols ... remember, the files are uniquely named so that if you change any of the Strad Inputs, or the current barlength-timeframe, a NEW pair of files with different names will be created.

If you chose Cancel to Abort, a special "TLA_ ..." file is put in the folder that acts like an off-switch for any future attempts to write to the "TLS_ ..." & "TLB_ ..." files that have the same "..." name. If you change your mind and want to add more Symbols to those particular TLS & TLB files, all you need to do is to open the TT_Output-Files\Stradicator-TradeLogs folder (which is *automatically* created if necessary, always in the Nirvana-standard C:\Program Files (x86)\Nirvana\OT20xx\SDK\ location). You'll see the "TLA_ ..." file at the top of the list (sort by date). To resume adding more (new) Symbols to its companion TLS & TLB files, just DELETE THE TLA FILE. Voila. Done.

The TLS file exists mainly for three reasons:
1. to keep track of what symbols have been processed already (one record-row per symbol)
2. to document the complete details about the Stradicator Inputs used for those outputs
3. to hold a *bunch* of summary statistics about how the Strad performed for each Symbol
... all this info is what the StradWiz spreadsheet will use for its analysis ...

The TLB file exists for one reason - feed a massive trade-history to StradFolio spreadsheet:
Every record-row of that file represents one bar of an active trade for a Symbol in the TLS file.
Each row starts with some fields to uniquely identify what Strad & Symbol & Trade it's part of.
Each row has condensed data for that bar's OHLC, GutsPrc, ATR, plus the Volume up/down bias.
Each row reports the bar's trade status: Net Prof/Loss, MaxDrawDown, and RwdRisk TradeQuality
The row for any bar with a Buy or Sell Signal has: order type+dir'n, order size, and order fill-price

For grins, I've attached a Zip with a simple-sample of the TLS and TLB files. The formats and structure of them are all finalized, including the first-row column-headers. Note as discussed above that the values in the columns are "dummy" tests ... normally they will vary but in these examples they are fixed, so don't fret if they seem odd.

The TLS and TLB files have the ".cvs" extension ... that stands for "comma separated variables". If you own Excel, you can just double-click on them to open them into Excel, in the orderly columns that you'd expect. Alternatively, you can right-click on the filename and select "Edit" from the menu ... the file will open in NotePad, and you'll see a bunch of commas and some double-quotes that don't show up in Excel. These files are NOT intended for a user to edit. But users can feel free to build their own custom spreadsheets that use these as Import files (for one of the SS tabs) to work with in any way you wish.

I deleted file attachments since I made some small tweaks re meaning and sequence of columns. Also, I'm spending time today to try to cobble together a really rube-goldberg crude simulation of trade signals and values so that the sample files actually are a bit more realistic. I'll go as far as I can with this within a max of two days (hopefully one) ... rather than spending considerably more time that the earlier-proposed "PMA" spec (click here) described (since not many volunteered for testing). The goal is to create some files that Mark can use for StradFolio development work.

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
RobertPfoff
Posted 10/10/2019 9:31 PM (#9750 - in reply to #9680)
Subject: TrdLog-Files for StradFolio & StradWiz



Friend

Posts: 19
0
Location:
USA: PA, Warrendale
Congratulations, sounds great

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
JimDean
Posted 10/12/2019 8:35 PM (#9752 - in reply to #9749)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
...TradeLog-routine Status ...

First, please note that I added an important "definitive" post to the Reference thread, explaining the entire scope of how TradeLog works. It's a long post, but it's been composed to be readable by anyone, without having to be up-to-speed on other technical details. It fully describes the operation of the TradeLog routine, from the user's point of view ... explaining all the popup boxes that could appear, the reasons why they would, and what response you should give when TradeLog's one "Yes/No/Cancel" query-box appears. The TradeLog routine handles all file creation and maintenance *automatically*. The snapshot below concisely walks through all the popups ... and the text-explanation below explains the whys and hows in detail. Everyone, please read this ... and please ask questions, if this isn't 100% clear:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9751


I spent yesterday day expanding the TrdLogTst routine so that it acts like a "simple" test-Stradicator. The goal is for it to create actual and reasonable trades (which it does, nicely) based on fairly simple rules ... well, the core "indicator" is simple, but the various order-gen rules got pretty fancy. Many thanks, once again, to KenW who dialogued with me on the phone a few hours to help come up with a viable solution in a streamlined time.

I'm providing a snapshot below of the cobbled-together output as it stands right now ... each trade has it's price-candles surrounded by four Cut+Grab FullXit & PartXit envelopes, plus a (pink) BrokerSM "fixed" level. I don't plan any further changes to the Price Pane (or the CutGrab logic).

The indicator pane, thus far, shows histo's for every bar that is in an active trade (including the initial Signal bar, which enters with an MoC order). The "short" blue histo's appear when the initial entry seemed "less certain" ... they represent a "ToeIn" position-size about half of the "normal" size defined by OT's Trade Calculator. Some trades never increase in size ... but many trades, in a later bar, move into a "more certain" condition that triggers a "confirm" order ... this bumps the Size up to the normal TrdCalc "100% basis", and the blue bars double in height. The snapshot does not show it, but it's possible also for a trade to Enter initially with a Full size, if the core Indicator shows certainty from the get-go.

All the other histo-colors on the Indicator mark where an Order of some sort occurs. Violet = Partial Exits triggered by Close crossing a red Partial Cut envelope level. Purple = Partial Exits related to an internal rule that looks for brief "consolidations". Cyan = Partial Exits triggered by Close crossing a Profit Grab envelope level. Dark Red or Dark Green appears if a Loss-Cut or Profit-Grab Exit ends the trade. Dark Red also appears if the Broker SMkt line is crossed (almost never), or for a Full Exit that's triggered by and internal-logic "reversal" due to the core Indicator radically weakening. The height of the Red histo indicates the type of rule that fired it.

The model is set up to allow 4 Partial Exits (Grabs or Cuts) for a fully-Confirmed trade (2 PX's for a Trade that just has a ToeIn size) ... for any (rare) AddOn that fires (teal color histo) during the trade, one extra PXit is allowed. AddOns have *very* restrictive rules, requiring a pullback-PXit beforehand, then a clear but brief reversal back to the original Trade direction, such that the AddOn MoC price will be "attractive" (ie not beyond prior "resistance" before the PXit pullback.

The "core Indicator" is pretty simple ... a few rules derived from three differing-length LinReg Slopes of price. I've not set up any input sliders to vary things ... this exists mainly just to "drive" the TradeLog routine and produce "robust" sample TLB files so that Mark can begin work on the StradFolio spreadsheet when his time permits. ALL the different "classes" of signal are modeled in this test routine, so that StradFolio can be tested with them.

It took most all day today to modify the TradeLog logic to handle the special case described in the final PopUp window of the linked Reference file post ... it was messy, but it's working great now. I wanted to be SURE that all the file management was automatic and user-friendly.

The test-stradicator logic still needs to have simple trade-equity calc's added, to populate the three TLB-file stat's for each trade: NetTradePL, MaxTradeDD, and TradeQuality. Once I add those calc's, I'll enhance the bottom Indicator plot to show a yellow Trade Equity curve on top of the histo's. That shouldn't take me more than a day to complete. Then, back to the "official" CVW Stradicator, incorporating the TradeLog engine in it, and other recently-discussed mod's.


(WBA early TL-strad snap.png)




Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION


Attachments
Attachments WBA early TL-strad snap.png (85KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 10/13/2019 3:38 PM (#9761 - in reply to #9752)
Subject: TrdLog-Files for StradFolio & StradWiz



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Today I realized that there were a couple of other situations that would commonly occur when using a Stradicator with TradeLog active, that might accidentally create unintended Log files, or inadvertently append more Symbols to a existing TL file that you had completed a long while ago.

This can happen when you "forget" to turn off Logging before shutting down OT, or before changing Profiles or Chart Templates. Or it can happen if you switch to a combo of parameter settings that you'd logged a day or week, etc ago ... thus matching a prior filename.

Usually in those cases, you *don't* intend to add to the long-ago file ... or you *don't* intend to restart logging first thing the next morning. So, after some additional research re accessing file date-time stamps from within OLang, I added code to support two more prompts that "courteously protect" you from those situations.

Accordingly, I revised the explanation (at the end) and added two popups to the big snapshot in the post here:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9760

Also, for you hard-core OLang coders out there ... I created a new thread in the OmniLanguage Section of the forum with several posts explaining how to use various string and file and date dotNet functions within OLang

Thread moved by on 8/25/2019 7:52 PM from Custom TradeTight Routines > Tools In Team Development > CVW Journal & DISCUSSION

Top of the page Bottom of the page
Jump to page : 1
Now viewing page 1 [50 msgs/pg]
( E-mail a Link | Printer Version | Search Room )

Owner of site: Jim Dean -- Forum content is confidential, and may not be distributed without written permission.