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. 

2 Chronicles 27:6 (NKJV) … So Jotham became mighty, because he prepared his ways before the Lord his God.


Sticky CVW Journal & DISCUSSION
Jump to page : 1
Now viewing page 1 [50 msgs/pg]
Jump to room :
JimDean
Posted 6/27/2019 11:20 AM (#9641)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
This thread "ongoing" Discussion, the best starting-point for those who joined the Team in June ... this is where I keep an ongoing "journal" of work, and post questions for team-members to help out with. This is the thread where your answers, comments and questions should be posted.

Other threads related to CVW development:

1. An active thread with "reference" posts such as help screens that will be kept up to date as development progresses (not open for user-posts):

2. An inactive thread with the initial VolEval Beta and SBAS testing (frozen now ... no more posts): http://tradetight.org/forums/thread-view.asp?tid=1431

3. An inactive (frozen) past-journal/discussion thread with CVW-development info, *prior* to adding several new Team members in June. It grew VERY long (5 pages), so I moved info from it to the VolEval thread and the Reference thread. There is a lot of interesting info about the thinking behind nearly every aspect of the "middle" phase of development, but most of those posts were later superseded by refined approaches ... so much of the info there does not accurately reflect how CVW operates now:
http://tradetight.org/forums/thread-view.asp?tid=1432


Important ... If you have comments or questions about a post in another (frozen) thread, then you MUST include a URL link in your post here, so that others can quickly find out what you're referring to. This is how to create that link (this is much easier to do than to explain, btw, and works for all forums, even N):

1. Navigate to the post in this Reference thread that you are mentioning.

2. COPY the entire URL string from the browser window ... for this post, it looks like this:
http://tradetight.org/forums/thread-view.asp?tid=1444&posts=1&start...
(actually, as this thread grows, the #posts and start# will change, or, depending on how you navigated to the reference-posts, the info after the "tid=xxxx" might be different)

3. Memorize the date-time info-line just above that post, for the "#nnnn" number that identifies that post. For this post, "Posted 6/27/2019 9:07 AM (#9641) ", what you want is: 9641

4. Navigate to this Discussion thread, and in your new post, PASTE the URL from step 2, and DELETE everything in the URL after the "tid=1444".

5. TYPE in a pound-sign followed "M" and the ID number of the post being referenced (step 3)

6. When clicked (or pasted in browser field), the completed URL should jump you directly to the post in question, and should end up looking like this:
http://tradetight.org/forums/thread-view.asp?tid=1444#M9641

NOTE: if you simply provide the #Mxxxx number, it's NOT a convenient means of finding the referenced post (requires you to use Search and potentially wade through things). So, please ALWAYS use this method.
Top of the page Bottom of the page
JimDean
Posted 6/27/2019 11:50 AM (#9643 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Here we go ...

Some of the more recent posts in the (now-archived) earlier discussions thread were moved directly into the Reference thread. However, there are a LOT of posts in that earlier 5-page 250-post thread that have info which is still relevant and current ... intermixed with stuff that's not really "reference" info.

So, I'm creating some new posts in the Reference thread that duplicate the info from posts that still remain in the archived one. I'll keep the ones in the Reference thread up to date, so eventually the archive thread copies will become invalid.
Top of the page Bottom of the page
JimDean
Posted 6/29/2019 9:51 AM (#9649 - in reply to #9643)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Hi, all ... please feel free to post any comments or suggestions about this ... it's a fairly simple change, but I figured the explanation behind it would help y'all come up to speed.

I just updated the Reference snapshots of the "draft" versions of Help Panels #3 - #6, here:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9634

Yesterday I finalized the color map for the WaveBand ... this is a crucial Stradicator paradigm output feature. I *updated it today*, adding "*" flags on NINE of the Bull|End|Bear labels. I posted a "crib sheet" color-key in the Reference thread, here:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9647

This morning, I posted six sample charts in the Reference thread, that show the current status of the various Plot Format options. One of them illustrates all the "envelopes and dots" turned on (negative slider Powr|Cstm versions), and the other five show positive-slider all-version defaults. The Equity option (#3) will be fleshed out soon ... I need to finish up the envelope coding first. Check it out here:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9648

Quick notes:
... the final Option #5 "V, CumV, MAs" plot is intended primarily as an "educational" output, providing a "drill-down view" of the Raw & Capped volume, CumVol Increm & Total, 3-MA's, and Slope & Stack status "all in one". It is NOT intended for actual "use" or decision-making, but rather as a "resource" when someone wants to know "why" the curves and histos and strips in Option #4 Vote Detail are what they are. This plot-option might only be available with the Cstm-version.
... the Option #4 Vote Detail is also an "explanatory" plot ... it shows the seven individual "votes" for Slope, CurBar, and Stack in a normalized form. Most people won't need this, since the three Option #2 bottom Strips show the "net" of those three categories ... but again, for people who are curious what's going on, this is very useful. This plot-option might only be available with Powr+Cstm versions.

The first sample show the default Plot Option #2 can get very "busy" on the PricePane, with all the envelopes turned on by the neg-slider BgnVot, EndVot, FuzVot settings (fewer envelopes if any/all are positive). Some folks like to see the "general reasons" behind actions taken by the Stradicator ... this combo of Price & Indicator panes is designed for that ... it's three thin Strips below the Band in the Indicator pane "explain" the status of the internal Slope, CurBar, and Stack voting, which collectively are the primary controlling factor for the Band.

However, some want a cleaner chart, and don't care too much about "reasons" ... they just want to "know what to do". Or, maybe they also want to plot some other things on the Price Pane, &/or create additional stacked Indicator panes for their own reasons. In that case, the "envelopes" may make the PP too "busy" ... and the "explanatory detail" from three bottom horizontal "strips" might not be needed. The second snapshot (Plot Option #1) shows that "clean action" mode ... the PricePane dots which indicate signals for Orders remain, as does the Band which echoes that info (plus general trade "status"), but the extraneous busy-ness is removed. (Note the PricePane dots all are echoed just below the Band.)

At this point, please review the first-linked M9647 Band-color reference-key. The snapshot has been updated, per the new fifth paragraph (just above the italics). The new asterisks flag nine "events" that logically only have to do with *managing* a real Trade: Price crossing Envelope lines (partial or full exits), Add-Ons, and Full exits related to position size or equity-vote filtering.

My "background" thinking has always been that the Stradicator "state" might be useful as a FILTER for other Strategies (or other Stradicators, or the same Stradicator with different settings ... think a bit on THAT one ;~). Presuming that's true, I'm thinking it might make sense to decouple some of the "trading-actions" logic for the "filter-mode" ... retaining the features that relate to the core of the Stradicator's focus (in this case, Cumulative Volume), and REMOVING the features related to raw price action (envelopes), or to position-size and equity-filtering.

If that kind of "filtering mode" is valuable/useful, then MAYBE the Plot (and Return) Output options could expand to include it. That is, a SIXTH plot option could be offered (it would become #1, and the current #1-#5 would become #2-#6) ... the new Filter-mode option #1 would have the seven "*" features inactive (which could alter the appearance of the Band ... sometimes allowing the "Waves" to continue longer than they would otherwise). The PricePane Plot would be completely clean ... no dots or envelopes. The Indicator Pane for the Filter mode would show the (altered) Band ... but nothing else (therefore using very little "chart real estate").

However ... without adding a new special "Filter" mode output option, it's possible to turn off all seven of those "*" features, with by making all the VoteGuru+Expert and CutGrab and BarWndo slider-settings POSITIVE, so that if you want to actually *trade* on that basis, you can. But if you're trading rather than filtering, my guess is that you'd want to see (at least) the dots on the price-pane, (possibly) some of the other plot-output options, and definitely many of the Return-value options (Stats for Scans, Signals for trades, etc).

In order to Keep It Simple & Sensible, I'd rather not add more output options ... so, this is what I'm thinking about doing ...

MODIFY Plot Option #1 so that it turns OFF its current PricePane dots IF all the VoteGuru+Expert and CutGrab+BarWndo sliders are all Positive (neg inputs are not avail for Easy|Xprt versions, btw).
That is, though "entries and exits" are shown by their related Band colors on the Indicator, Option #1 keeps the PricePane totally clean and the Indicator Pane simple. However, if any of those sliders are negative, you'd see the impact of the negative-input features on the Band with the #1 output, AND the Dots would show up on the Price-Pane (but no envelopes).
Using this approach, if you want to see explanatory detail ... any active PricePane envelopes plus 3-strips, or the Equity Status, or the Vote-Detail, or the V+CumV+MAs), you'd flip to plot Option #2,3,4,5

QUESTION ... do you think I should create new Plot/Return options just for the Filter mode, or do you think the "Modification" above with the current options is sufficient?

And ... this is a good time for you to take a look at that Band-Colors "key" as well as the five samples, and ask any "burning" questions you might have about the general format or approximate meanings.
Top of the page Bottom of the page
MikeDeWalt
Posted 6/29/2019 2:26 PM (#9651 - in reply to #9650)
Subject: CVW Journal & DISCUSSION



Spectator

Posts: 1
0
Location:
USA: WA, Stanwood
1. I believe than any internal logic that results in potential state change in orders or holding should also have some external manifestation. On the other hand internal states that generate signals and do not effect external behaviors can be masked, not displayed, or hidded and available via sliders or other options.
2 & 3 I have no opinion on colors other than the consistency issue that you've addressed in another post.
Top of the page Bottom of the page
JimDean
Posted 6/29/2019 3:00 PM (#9650 - in reply to #9649)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Second Journal + Question post for 6/29 ... this one needs your replies ASAP ... you can wait on reviewing the prior post till after this one ;!)

If you've taken a reasonably careful look at the "BgnVotNetNatcMny2Fw" explanation on the Reference-thread Crib Sheet or Help Panel #4, then you'll recall that slider-positions of (pos or neg) 1,3,5 use "ToeIn + Confirm" entry logic, while slider = 2 or 4 use "Norm-Entry" (All-In) logic. Check out the explanation here:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9625

Important background:

This choice is a "major feature" of Stradicators, supported by both the Simple and Robust Trade Plans. The first three "Bull Alert", "Bull Toe-In", and "Bull Confirm" bluish Band colors appear only if the BgnVot slider is 1, 3, 5 ... (also, the last-three "Bear" purplish Band colors). OTOH, if the slider is 2 or 4, then "Norm-Entry" starts every trade with a single large order (lawngreen or hotpink color). See the Color-Key here:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9647

Once a Trade has made a Norm-Entry, or has had a Confirm order, it's into the "full-Wave" mode where the greenish or reddish Band colors take over ... that is, the trade is no longer in a "tentative" Alert aka ToeIn state (which has a smaller position size). ToeIn orders appear when the NetVote is one vote less than the required BgnVote (6,6,5,5,4 votes per BgnVot slider).

Sometimes the extra NetVote required to Confirm (or create a NormEntry) never appears ... in that case, the trade starts at a fraction (1/3-1/2) of the Confirm'd size, and never gets any bigger.
If the NetVote jumps straight to the BgnVot threshold without an Alert-Vote bar preceding it, then if the slider=1,3,5 Toe+Confirm, the *first* bar w/adequate NetVote is a ToeIn-sized order.
In either case, if another bar appears soon thereafter that meets the BgnVot threshold, *without* any "weakening" of the vote since the ToeIn before that, that Confirm >= BgnVot bar bumps the trade size up and the Wave turns green/red.

In green/red Wave mode, if the FuzVotBndAddsSm2Lrg is negative, then Add-On's can appear (there are important pre-qualifiers for them, though). Add-On's *never* can appear in "Toe-In" size/mode. Also, the green/red Wave mode has a sophisticated chunk code that creates "warnings" (dark red/green bars) from several different situations (controlled by the EndVotOpXmwFw2Mny slider) ... much of that logic just doesn't make sense for ToeIn mode.

In *either* the green/red Wave mode, or the blue/purple ToeIn mode, there are a large variety of situations where a Full Exit is signalled ... too many to discuss here ... and most of those rules apply in *both* modes. If Partial Cuts &/or Partial Grabs are activated, via negative CutGrabGapSzSm2Lrg input (showing the dim inner-envelope pricepane lines), then in *either* mode, Partial exits will occur when Close crosses those lines.

Currently, when in ToeIn (aka Alert) bluish/purplish mode, some of the FullExit rules aren't used ... instead of creating (two different ways) and counting "Warnings", then signaling a FullExit when enough appear, the ToeIn mode simply checks if the NetVote has dropped >= 2 since the ToeIn started ... if so, the ToeIn/Alert mode does a FullExit. Currently, there are no ToeIn-mode "Warnings" (potentially creating Partial Exits) derived from Slope+CurBar+Stack Voting.

PROPOSED NEW TOEIN-MODE WARNINGS:

Since the Partial CutGrab envelopes CAN currently do a partial-exit during ToeIn mode ... and since in the red/green Wave mode any PartialCut is treated as a Warning re the internal logic ... then it seems to me that there should be some kind of internal logic that permits a Warning (PartialExit) to fire during a bluish/purplish ToeIn mode ... that is, scaling out of the ToeIn size, rather than waiting for a Full Exit.

Since a Vote-logic ToeIn Full Exit fires when the NetVote drops by 2, it seems sensible to make the Vote-logic Warning (PXit) fire when the NetVote *drops by 1* below the initial ToeIn/Alert bar's vote.
Depending on the EndVotOpXmwFw2Mny slider setting, which defines the PX size (40%, 30%, or 20%) ... along with the BgnVotNetNatcMny2Fw slider setting, which defines the ToeIn size (60%, 40%, or 20%) ... it *could* be that *just one* Warning/PXit that's >= the size of the ToeIn, could automatically convert to a Full Exit, ending the ToeIn mode trade.
OTOH, if the ToeIn is 60% and the PX is 20%, then it might take *up to 3 Warnings* to fully scale-out of the ToeIn mode ... this presumes the NetVote drops by one, then goes up by one, then drops by one again, then goes up by one, then drops by one a third time ... pretty unlikely ... but the trade is "managed" properly ... the price is "chattering", so the size is gradually scaled back and finally the position is closed (if some other FullXit logic doesn't intervene first, which is more likely).

It's not difficult to implement this ToeIn mode refinement *at this point*. I could use Teal or DarkCyan for the Bull ToeIn Warning color, and Magenta or Orchid as the Bear ToeIn Warning color, bringing the total #Band colors to a well-arranged total of 29!
OR ... I could use the already-existing three greenish and three reddish Warning colors, which distinguish the reason creating the logic (and the Partial-Grab cross colors)

THREE QUESTIONS:

1. Do you think I should implement the "ToeIn Mode Warning" logic as described above? If not, WHY not?

2. After checking the full-palate of colors, here:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9607
and the current Band-Color key legend, here:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9647
... (you can set these up on two separate Browser tabs and flip back and forth easily, btw)
do you think I should use Teal or DarkCyan for the Bull ToeIn Warning color ... OR should I use the existing greenish-Bull-warning color-set?

3. After checking those two snapshots, do you think I should use Magenta or Orchid as the Bear ToeIn Warning color ... OR should I use the existing reddish-Bear-warning color-set?
Top of the page Bottom of the page
KeithBuhl
Posted 6/30/2019 11:55 AM (#9652 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Veteran

Posts: 128
10025
Location:
USA: PA, New Hope
1. Yes.

2. Teal.

3. Magenta
Top of the page Bottom of the page
RobertPfoff
Posted 6/30/2019 6:02 PM (#9653 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Friend

Posts: 19
0
Location:
USA: PA, Warrendale
I agree it makes sense to implement the changes

I am already overwhelmed by all of the colors, so why not 2 more. I suspect I will be more reliant on the dots on the charts than all of the color changes but perhaps as I get more comfortable with it I will use it more. It is great to have such a compact way of demonstrating what is going on. Have you thought much of how people who are color blind will deal with it?
Top of the page Bottom of the page
JimDean
Posted 6/30/2019 7:52 PM (#9654 - in reply to #9653)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Thanks for the reply Keith, and your comment Robert. I am still weighing alternatives here. Tomorrow I will likely post an alternative format which removes five of the colors from the Band - I’ll explain it then.

I did comment in an earlier post about color blindness. Quite a long while ago I had a single client who struggled with that. What I discovered was that so many useful nuances had to be removed to accommodate the limitations, that it just didn’t make pragmatic sense to design “retail”-sales tools around that. I am however open to doing custom alterations per a single clients wishes - but at additional cost.

In this case, the brightness and darkness of the hue should be discernible, even if the red/green distinction is lessened. And generally a glance at the price direction should clarify if it’s bull or bear.

If anyone else has comments or suggestions, please submit them tonight, as I intend to lock this down tomorrow. Thanks!
Top of the page Bottom of the page
KeithParsons
Posted 7/1/2019 10:31 AM (#9655 - in reply to #9650)
Subject: CVW Journal & DISCUSSION



Veteran

Posts: 122
100
Location:
S.Africa: , Umgeni Park, Durban
I would go with Keith
1) yes
2) teal
3) magenta.

The chart dots for me are clear. But then of course and right now I am not under "trading pressure" However and if it was possible it would be most helpful from a visual aspect to have these colors in something like Nirvana's SetUp editor in the F.L.

I do realise that this is not possible.

Regards
Top of the page Bottom of the page
JimDean
Posted 7/1/2019 10:54 AM (#9656 - in reply to #9655)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Thanks for the reply.

You’re correct. OT does not permit custom coding that leaves the color choices open to arbitrary user assignment. It all has to be hardcoded. And, when many colors interact, meticulously planned.

Regarding clarity - the formatting I’m working on now regarding envelope crossovers will not add the five extra colors described earlier. Instead, I’ve decided to show a set of colored dots immediately under the Indicator Wave Band - a dot appears without incurring or changing that bar’s band color. A dot occurs on bars where the price crosses an envelope on the price pane. I’m in process of considering echoing the existing dots from the price pane to this new “signals row” of dots below the band. Thus, any bar with a dot in that row is one that fires some kind of order.

THEREFORE: every “Signal” has a “dot” somewhere on the Indicator pane OR the price pane (or both), and the multicolor Band clarifies progress as things progress. Also, as mentioned earlier, the user can optionally turn off the drawing on the price pane if so desired.

Top of the page Bottom of the page
JimDean
Posted 7/1/2019 3:00 PM (#9658 - in reply to #9656)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Knowing When, Why & How to Manually Place Stradicator Orders:

I believe I mentioned during the videos somewhere that the Stradicator paradigm includes the option for popup messages whenever an action(dot) appears on the Last Bar of the plotted Symbol. The message will contain detail similar to the Voteline Advisor pane (+extra) … type and size (%basis) of Order, reason for the action, and a report of prof/loss thus far in the trade (incorporating the dynamic sizing and scaling impacts). The OT voteline Advisor is not able to do this for scaling, btw.

It will also be possible for you to check on what the action (order) and trade status was for some prior Dot. I’m still debating the best way to do this … might be via modifying how the BarWndo slider works, or could be by adding another “BarsB4hre” slider (similar to MTV), or possibly by using a CSV text file to record every event so that it can be readily loaded into Excel. If I cannot figure a way to straightforwardly implement the first of those approaches, I’m more likely to gravitate to the third (Excel file) approach, rather than adding yet another slider. There are pros and cons to all three methods.

A clean and fairly simple First-method solution is explained below, and illustrated in the snapshot.

Currently, the negative-sign for the Master input has limited/doubtful value ... I could reassign the effect of that negative sign to take over what the current BarWndo negative sign does ... that is, toggling on the Equity-Vote Filtering. It actually makes a bit more sense put it at the top, anyways.

Having done that, the negative sign used with the BarWndo input could simply "reverse" the meaning of the input value for the Plot and the Return. When Plot is specified (final input pos), then a negative BarWndo value would "lock in" the number of calc'd-output bars to be 128 (the default 6mo value), but would cause the "Last Bar" calculated ... ie the right boundary of the output window ... to shift to the left ... ie into the past.

This means that the popup message about what trading-action the Dots represent would apply to the final "BarWndo" bar's dot ... to check some particular prior Dot (before the HRE), one would simply move the *negative* BarWndo slider to the left, looking deeper into the past. Each time the right edge of the window finds a bar with a Dot on it, the Popup would appear. To move on, the user clicks OK on the popup, and adjusts the slider once again.

This offers a convenient way (fewer intermediate "OK" clicks) when a particular bar is in question that's several "Dots" ago: with the Indicator Param panel open, the user first changes the Plot output slider to a non-Popup mode, then move the neg BarWndo slider until its right edge is on the desired Dot, then move the Plot output slider back to Popup mode to learn the details. This could be done repeatedly. When finished, clicking "Cancel" for the Indicator Param Pane would restore the output to its original configuration. Not *quite* as simple as clicking on a Voteline triangle to view the Advisor window, but with two huge advantages: 1) no need to recalc the strategy since Stradicator is self-contained 2) Strad Popup provides info that the Voteline Advisor simply *cannot*.

I'd value your *immediate* feedback on this idea, if you have comments. Thanks.



(Neg-Master+BarWndo Changes.png)



Attachments
Attachments Neg-Master+BarWndo Changes.png (147KB - 0 downloads)
Top of the page Bottom of the page
RobertPfoff
Posted 7/1/2019 9:20 PM (#9659 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Friend

Posts: 19
0
Location:
USA: PA, Warrendale
I think this is an excellent solution. I have found the dots to be very intuitive and the addition of this level of information, especially when paired with an equity curve will be amazing. Keep up the great work.
Top of the page Bottom of the page
JimDean
Posted 8/17/2019 8:53 PM (#9670 - in reply to #9658)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Howdy all ... finally getting back into things, after a long and slow improvement in a health issue ... and a few family issues. Hopefully, as things get rolling again, y'all will be able to respond in a timely fashion to questions posted here for your input (ie within 24 hours or less) - thanks. If I don't get timely responses, then I'll spend less time posting things. Up to you as to how much time you'll be able to spend ... any you can will be very helpful.

Today, I got the changes in my prior post implemented:

Negative Master input now acts as a flag to Engage the Equity-Filter-toggling
... note that Equity-Filter toggling is an optionally-licensed feature for *any* version
... Summary of version diff's, here: http://tradetight.org/forums/thread-view.asp?tid=1445#M9669

Negative BarWndo input now serves to "flip" the Plot vs Return application of the input value:
... Pos BarWndo for plot = width of eval, thru HRE; Neg BW for plot = #BarsB4Hre, w/128 width
... Pos BarWndo for rtn= #BarsB4Hre, w/9-bar width; Neg BW for rtn = width of eval, thru HRE

And, I formalized some licensing flags regarding the use of the optional Equity Filter toggles as well as the (newly) optional Stradicator-Filtering specs (via the two Guru inputs). Either or both of these features can be used with any of the Versions, but they'll be independently licensed for an extra fee (since they are not only powerful and unique, but also pretty tricky to code).
Top of the page Bottom of the page
JimDean
Posted 8/17/2019 11:35 PM (#9671 - in reply to #9670)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Later addendum to prior post:

If you read my prior posts carefully, you’ll note that there is another important reason for modifying the meaning of the negative-input flag for the BarWndo parameter … when the flag is negative AND a Plot Output is specified (final input>0), then that toggles ON the Popup Advisor feature - if the final output bar has any type of Signal, the Advisor explains what to do to implement the signal, in full detail (buy, sell, size, etc) - also, it explains the cause for the signal and recaps the trade progress thus far. The negative BarWndo value controls which bar is in focus (to examine the signals for the fifth bar before the HRE, input -5).

I also previously discussed the possibility of creating a log file output in CSV (Excel) format, that would essentially mirror all the Advisor info for every calc’d Signal for every symbol in the FL, for the number of bars specified. Obviously this could be very useful, but due to the potentially large amount of file-writing, it might slow things down. So, the jury is out on that one. If I do implement it, I’ll create a new Final-parameter input option to toggle the Log output - maybe via a Help panel button. Not sure yet.
Top of the page Bottom of the page
JimDean
Posted 8/18/2019 8:45 PM (#9672 - in reply to #9671)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
This post requests feedback ... please respond ASAP.
If you don't understand the Q, then please ask for clarification.

READ THE UPDATED DESCRIPTION OF FIVE OPTIONAL-LICENSE FEATURES, HERE:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9707

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

QUESTIONS:

1. Are those descriptions adequate ... do you "get it" what the flag is toggling, and do you at least roughly perceive that each of them offers a lot of potential benefit?

2. Do you think that some users might want to buy the Strad without some of those features, in order to save some money? (no idea yet but each feature might cost $200-$300 or so).

3. Any other comments are welcome. Thanks!

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

Attached snapshot shows how the first Help panel will indicate on the second line, which features are active for that user ...

(Help Panel #1 - ExtraF.png)



Attachments
Attachments Help Panel #1 - ExtraF.png (416KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 8/19/2019 3:08 AM (#9674 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
I suspect that every one of you who bought in early are interested in most all of the features.

The point of my three questions was to survey y’all re general understanding of the five descriptions (ie enough to make you want to know more or not).

Also, it would *really help* if you’d tell me what you think the broad swath of *all* future clients might want (or not want). Your best guess.

Reason: if virtually all clients will want virtually all the options, then I don’t need to offer a buffet. But if the all vs none price has a difference of say $1000 per Stradicator, do you think some clients might prefer to pick and choose some and not all?

A client will be able to try out the full-featured engine out before committing with significant money. Prospective buyers can “rent” the full-featured Stradicator for a month (or six months), at a small fraction of the cost - then once they’ve decided what features they find useful, they can purchase that particular combo. It’s easy to add more later.
Top of the page Bottom of the page
RobertPfoff
Posted 8/19/2019 10:39 AM (#9675 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Friend

Posts: 19
0
Location:
USA: PA, Warrendale
I think combining the features makes the most sense, it is hard to grasp how useful each feature is until you use it. The one that makes the most sense to break out is the Wizard-Config.

The holy grail may being configuring each of the stradicators as super inputs into the GA. It sounded like that could be done. Is that your understanding?
Top of the page Bottom of the page
JimDean
Posted 8/19/2019 11:15 AM (#9676 - in reply to #9675)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
The Strad’s can be used in a GA, but not in SETI or anything that requires uploading to N’s servers. N prohibits DLL uploads, sad to say.

However, the potentially most beneficial and profitable features of Strad’s, which are the equity-filtering and the equity-stats-based dynamic OScans, would not be applicable to GA’s.

The whole GA approach uses a nearly 180-degrees opposite methodology than Stradicators. GA is essentially a supercharged Avengers-level curve fit. Stradicators are based on cold logic, therefore can be expected to be more consistent and robust. (Jmho).

The “N method” is primarily to build cool tools that work with a static (or simplistically dynamic) focus list. The Stradicator method is to work with an extremely-insightful dynamic-Scan Focus list - that is, find the symbols that historically worked best with the rule, rather than the other way around. And redo that every day/week.
Top of the page Bottom of the page
RobertPfoff
Posted 8/19/2019 2:32 PM (#9677 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Friend

Posts: 19
0
Location:
USA: PA, Warrendale
I agree that the Strad's are significantly different from the GA, that is why I like them so much. That is also why I think they may be good inputs into the GA. I understand why they can not be uploaded to the Nirvana servers for SETI, but it seems to me that they should still be callable as individual inputs for the GA but I don't understand the inner details of how that all works. Thanks
Top of the page Bottom of the page
JimDean
Posted 8/19/2019 3:13 PM (#9678 - in reply to #9677)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Hi Rob - once they are released I’ll explain how. It’s easy - just create a simple OScript formula (Boolean or Value), which includes a function call to the Strad indicator with the appropriate return value selected. Many variants possible. You could set it up to be GA’ing for entry signals, or as a Filter.
Top of the page Bottom of the page
DonTurner
Posted 8/19/2019 7:31 PM (#9679 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Spectator

Posts: 3
0
Location:
USA: CA, Ridgecrest
Jim Dean said, "Also, it would *really help* if you’d tell me what you think the broad swath of *all* future clients might want (or not want). Your best guess."

My best guess: The probability distribution of quantity of features for future clients might be similar to the distribution of $ spent by us early adopters. I especially like the equity influenced and dynamic focus list features.
Top of the page Bottom of the page
JimDean
Posted 8/25/2019 7:25 AM (#9683 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Steve’s likely too busy to get into this - but I agree that we need better analytics. To that end, with a focus on how much useful info I can derive from a single Stradicator run on a single Symbol (especially for fitness Scans), I’ve come up with a basket of metrics that I feel will be far more representative and effective than the classic APR, PPT, MDD, Calmar, etc. These stats will be part of the Paradigm, available as Return value output choices, for Scans, Focus List columns, etc:
http://tradetight.org/forums/thread-view.asp?tid=1445#M9645

I’ll be asking Mark to fold them into the spreadsheet as well, modified appropriately to encompass multiple symbols. I’d also like to incorporate some frequency distribution and error-estimate info to help qualify them further.
Top of the page Bottom of the page
JimDean
Posted 8/25/2019 8:01 PM (#9688 - in reply to #9683)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
I just moved the last several posts that have to do with Log Files and StradFolio into a new breakout thread, here:
http://tradetight.org/forums/thread-view.asp?tid=1446

Please post about that topic in the new thread. Thanks.
Top of the page Bottom of the page
JimDean
Posted 9/9/2019 6:50 AM (#9706 - in reply to #9688)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
I just updated some of the crib sheet info and panel snapshots in the Reference thread, to reflect recent changes in how the BarWndo input works (pos vs neg, and override), including the shift of the EquityFilter toggle to the Master input. Note that the OmniScript function-call panel now has expanded detail to match. These posts were affected:

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

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

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

http://tradetight.org/forums/thread-view.asp?tid=1445#M9642
Top of the page Bottom of the page
JimDean
Posted 9/9/2019 3:24 PM (#9709 - in reply to #9706)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Revisiting the Strad-Paradigm Parameters ...

Currently, two of the fifteen param-panel rows are used for "dummy" parameters that are greyed out and serve only as separators. Their value is primarily aesthetic.

I'm thinking about stealing one of them, so that the equity-filtering feature can have a slider to allow the user to adjust it from conservative to aggressive in some way. The equity-filter watches all the results of trades for a given symbol over time (for those particular strad input-settings), and decides when the performance has for some reason become less than acceptable. At that point, it keeps on calculating all the trades "in the background", but until the performance gets better, it blocks any of those background trades from being actually processed as orders (ie outputs).

The equity-filter logic as I previously implemented uses a stack+slope voting algorithm, using the actual (background) equity curve with two MA's and some simplified rules. There are several internal variables that drive the calc, such as MA periods, Slope periods, vote thresholds, etc. The slider that I'm referring to would allow the user a "guru" type input which would adjust all those params in an appropriate manner so that the equity filter would be more or less reactive to performance changes, before it blocks the trades.

Currently, the *only* way for the user to tweak that *requires* that they own the Cstm version, and that they use a manual-input Override of the final Output (Return|Help|Plot) parameter to adjust things. I've never liked this much, for a whole lot of reasons. Here is what the current Override spec for that input looks like:
OutputReturnHelpPlot- EqtyVote IRCVS##: ##=PltRtn; S~TimeG, V~VoteG, C=Cntl
... I&R=SmartSize Invst&Risk Ntry +/-10% from ATR/5% study (RobustTP only)

Since the +/- and two of the digits must be reserved for the actual Output selection, that only leaves five to control the other specs ... and it's a pain to change them ... and when in use, that in turn makes it a pain to adjust the Output (diff Return values, diff Plot formats).

SO ... if I create a new slider dedicated to Equity Filtering (which needs to be licensed to work), it would leave the final Output slider alone for convenient output-switching, and it would provide a friendly guru-control to adjust the filtering rather than locking in on one arbitrary set of rules. This could be made available for all Versions if that makes sense to do ... and the Override would be avail only for the Cstm version ... and it would have all seven digits as well as the +/- to work with.

Seems to me to be a no brainer ... losing an aesthetic separator to improve functionality of one of the major Stradicator features.

Do you think I should steal a divider-line to make this Equity-Filter Control slider?

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

And, while I'm at it ... there's one other issue that could be handled effectively by creating yet another slider ... stealing the other aesthetic separator ... that being, an input of the Bar Length (ie 1 day, 20 min, 4 weeks, etc). This input would not actually force OT to use a different timeframe ... you have to do that with the DataPeriods table and the dropdown menu (or with the custom Strategy timeframe spec). However, there are a lot of other benefits:

1. It will significantly speed up program execution when more than one barlength is defined in DataPeriods. Currently, even though there's no need to, OT insists on running each FL symbol for every defined barlength, even if that barlength is NOT the "current" one which the chart is showing. But if the Strad has an input saying "THIS run is targeting a PARTICULAR barlength", then I can easily add code to completely skip the Strad calc for all other barlengths. This can be a major time-saver.

2. It's not at all unreasonable to presume that you might want to use a different pattern of parameter settings for different barlengths, with the same Stradicator. There could be all kinds of reasons for this. By having an input which specifies the intended Barlength, that prevents you from accidentally using that input-pattern with other barlengths that wouldn't be a good fit.

3. If the BarLength is part of the Strad's input-param list, then the "Pattern-ID" spec that is central to the TradeLog file management will contain ALL the relevant distinctions for that management. This simplifies file-naming, etc somewhat. Not a good enough reason all by itself, but a beneficial by-product.

This input, a slider from -20 to +20, will be available in all Versions. Input=0 means accept all barlengths.

Negative slider values will map to Minute-barlen's. Barlen's which divide evenly into the 390 min of a trading day= 1,2,3,5,6,10,13,15,30,65,130,195 ... round-numbers that someone might choose= 20,40,45,60,75,90,120,150. A total of 20 options. These will be mapped: -1 to -20 = 1, 2, 3, 5, 6, 10, 13, 15, 20, 30, 40, 45, 60, 65, 75, 90, 120, 130, 150, 195.

Positive slider values would be for Daily-or-higher barlen's ... including multiples of daily|weekly and fixed monthly (no mo-multiple avail). Logical limits for each will define the mapping:
1-9= #daily bars, 10-13=1-4wks, 14=1mo, 15=Volume, 16=Range, 17=3-LineBrk, 18=Renko, 19=Point&Figure, and 20=Heiken-Ashi, to correspond to OT's Periodicity -1>-3 and -5>-7.

The advantage to this mapping is that it encourages users to pick "rational" barlengths. The mapping will in a Help Popup table, and the first Help panel will indicate the actual #minutes.

Do you think I should steal a divider-line param to make this BarLen slider?
Top of the page Bottom of the page
KeithBuhl
Posted 9/9/2019 10:14 PM (#9710 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Veteran

Posts: 128
10025
Location:
USA: PA, New Hope
Equity Filter Control Slider ---- YES

BarLen Slider ----YES

Cheers,
Keith

Edited by KeithBuhl 9/9/2019 10:16 PM
Top of the page Bottom of the page
LDNewby
Posted 9/10/2019 2:52 PM (#9714 - in reply to #9709)
Subject: CVW Journal & DISCUSSION



Friend

Posts: 37
25
Location:
USA: VA, Vienna
I concur with Keith

Yes to the Equity-Filter Control Slider

Yes to Bar Length Slider.
Top of the page Bottom of the page
MarkHolstius
Posted 9/10/2019 3:09 PM (#9715 - in reply to #9709)
Subject: CVW Journal & DISCUSSION



Veteran

Posts: 209
100100
Location:
USA: IL, Sleepy Hollow
Yes to both...
Top of the page Bottom of the page
RobertPfoff
Posted 9/10/2019 9:59 PM (#9717 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Friend

Posts: 19
0
Location:
USA: PA, Warrendale
They both sound useful to me, If I had to choose I would favor the equity slider over the bar length option
Top of the page Bottom of the page
KeithParsons
Posted 9/11/2019 1:57 AM (#9718 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Veteran

Posts: 122
100
Location:
S.Africa: , Umgeni Park, Durban
Both please
Top of the page Bottom of the page
JimDean
Posted 10/2/2019 2:40 PM (#9731 - in reply to #9709)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
In light of the comments in this post:
http://tradetight.org/forums/thread-view.asp?tid=1446#M9729
... it appears that the reasons for the barlength slider (mentioned in my prior post, above) have gone away.

The rationale for the new Equity slider remains valid ... and this post:
http://tradetight.org/forums/thread-view.asp?tid=1446#M9730
... explains how the Master-input negative-sign could be quite valuable for runs using independently-tuned LongOnly and ShortOnly input-patterns.

So, the existing two gray "separator" inputs will go away. There will still be room for one more parameter in the single-column pane ... it makes sense (to me at least) to use it to visually separate the inputs that are "specific to" the particular Stradicator (CVW, ADX, etc), from the inputs that are part of the "paradigm" ... ie essentially the same meaning for all Stradicators.

In the case of CVW, that gray separation-param would be just before the VoteGuru input ... all the inputs above that are specific in meaning to CVW. (the new Equity slider would be below it, in the Paradigm section)

ALSO ... the fifth "optional features flag" mentioned here:
http://tradetight.org/forums/thread-view.asp?tid=1444#M9672
... instead of toggling "wizard mode", would activate the ability to run the dual-direction custom-models described above.

Comments welcome.
Top of the page Bottom of the page
JimDean
Posted 10/6/2019 10:43 AM (#9743 - in reply to #9731)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
This is an IMPORTANT post, for those of you who are trying to follow along ...

In a (big) nutshell, the changes mentioned in the prior post, and documented in the link it provided, were occasioned by these considerations:

1. A slider to control Equity Filtering impacts really was needed, since it's a major Stradicator Paradigm feature, and has significant impacts ... and that slider provides for manual override inputs in a logical place, rather than cumbering the OutputReturnHelpPlot slider with them, which should make it *easy* to flip between alternative plot formats, or open Help, sans manual typing.

2. TradeLog output opens up an exciting opportunity for StradFolio and StradWiz spreadsheet evaluations ... both of which can benefit from flexible control of the historical periods being backtested, and flexible spec of trade-directions allowed. The existing slider did a lot, but seemed constrained ... splitting it into two (like MTV) seemed a way to fix that ... and it provided extra "room" for CutGrab manual-overrides, albeit in a non-intuitive location. (see new idea, below).

3. The idea of allowing separate Long vs Short-Trade tuning for the four Paradigm Expert-inputs (Bgn/End/Fuz Vote & CutGrab-envelope), either via neg Master or slider-mod's, seems to have a lot of merit (tho, sadly, little team-feedback ... my bias is to make the variants transparent rather than using the neg Master approach). This is comparable to setting up an OT Strategy diagram with two "rows" each dedicated to a separate trade direction.

4. Long vs Short tuning logically should "scale" like other version-features ... the Cstm version logically should allow manual-overrides for relevant impacts. My initial attempt (see link above) to tailor that by adding "lower-case" digits to the B/E/F slider override-spec's worked out OK, *but* the complex nature of what the CutGrab slider does made it impossible to handle Long/Short override distinctions on that input alone ... I had to split out some of it to the WndoWdth and BarsB4hre sliders. Very non-intuitive ... but it was getting late. (see new idea, below).

======= improved approach after sleeping on it =======

A. BarWndo slider ... I was too hasty in expanding this to two sliders. It still may be feasible to provide both "easy-slider mode" for output ranges in "normal" situations, AND also provide sufficiently-flexible "TradeLog backtest specs" via manual-typed spec's.
Part of the issue is that a six-digit override "GggWww" (for #Width-bars and #Gap-bars) is limited to ~4 years of output-window width, &/or ~4 years historical lookback "shift". OT has daily-bar history that goes back to 2000 ... approx 20 years (5000 bars) ... and has enough intraday history to provide for a few tens of thousands of bars (N keeps changing the max ... not sure what it is right now but probably at least 20,000).
I tried to deal with that by providing four Gggg digits (push the window further back in time) ... but that still precludes a daily-bar output-window width (Www) of more than four years ... OT inputs are limited to 7-digits.

This morning I thought of a simple work-around for the backtest-window GggWww limitation ... allow an optional seventh "Multiplier" digit (MGggWww): M=0 (or 1) means Ggg & Www represent a normal # of bars ... input of "123456" (or 1123456) says to model an output window that is 456 bars wide, that ends 123 bars before the HRE.
For M > 1, the Ggg and Www spec's deal with more than single-bar increments. When M=2, a MGgg=2123 input specs a 246-bar Gap. MGgg=4321 spec's a 4*321=1284-bar Gap, and so on. Thus the max "reach" of MGggWww, using a manual override of 9999999 specs a window approximately 9000 bars wide, ending 9000 bars ago (9000 daily bars = 36 years; 9000 5-min bars = nearly six months). That provides PLENTY of range ... and it's easy to see where the "window" lies, simply by applying the MGggWww input to plot mode (with adequate DataPeriods loaded). Yes ... when M>1 there is some loss of "precision", but backtesting isn't *supposed* to be "precise".

Another important backtesting trick, especially when trying to discover what input-Pattern works for particular market conditions (ie bull or bear), is to visually search out multiple "chunks of time" when the market is behaving in the desired fashion. Determine that appropriate MGggWww spec to encompass each "chunk". Create a TradeLog file by running your Strad and Symbols for that time-chunk. Repeat this for each different MGggWww "chunk". Then, you can easily merge (concatenate) those TradeLog files together into a common StradFolio or StradWiz analysis spreadsheet. Voila!

So ... the MGggWww spec removes the broader-backtest-range need for separate sliders.

The other thing that single-slider controls is allowable Trade-Directions. Default is "Both" ... ie Long & Short trades allowed. The slider itself goes to 256 (ie one year, which is a reasonable max to view on a plot at one time ... or a reasonable max lookback to use for a FocusList-Column Return value.
The "BarWndoTrdDirL3cS6c" parameter-name reminds the user that when the (3-digit) input is 300-599, the model is LongOnly; when it's 600-899, the model is ShortOnly. The param-name hopefully makes this fairly easy to remember.
Negative 3-digit inputs simply reversed the meaning of the value based on the specified Output type: for plot, positive=width@HRE and neg=lookback(W=128); for return, pos=lookback(W=9) and neg=width@HRE. This was explained at length when I came up with it ... a clean and elegant solution that handles 95% of the uses people are likely to need.

When a manual override MGggWww is used, the earlier definition limited the model to LongOnly for positive inputs and ShortOnly for negative inputs. In retrospect, that was a poor choice, since there are probably no (successful) traders that limit themselves just to Short trades.
It makes more sense for a positive value to represent Both Long&Short, and a negative value to limit the trades to Longs Only.

But ... how can the new "separate-pattern" Long & Short models be specified, distinctively from the "common-pattern" BothLS default-approach described above?

Yesterday, the need for that distinction was part of what pushed me to split the BarWndo input into two separate sliders ... but that split, per notes above, is no longer in play. It turns out that the solution is SIMPLE, even using the single-slider ...
When the BarWndo slider (or manual override) implies "BothLS", then use a *common* pattern if none of other Strad inputs imply separate L vs S models ... but use *distinct* L vs S patterns if any of the other inputs provide those distinctions.

The "distinct L vs S input spec" could be via the neg-Master approach (if that's implemented ... looking like it won't be) ... or could be via "integer.decimal" inputs for the four Vote+Envelope Experts, as described here ... http://tradetight.org/forums/thread-view.asp?tid=1446#M9739
If any of those V+E inputs tell the Strad to evaluate Long vs Short differently, and if the BarWndo slider indicates "BothLS" modelling, then L & S trades have different entry and management rules. If none of those inputs imply separate evaluations, then L & S trades use common rules.

This solution also provides a "backdoor" way to do Shorts-Only TradeLog runs in conjunction with a BarWndo MGggWww override. Under the revised rule above, when that override is negative, it normally spec's a LongOnly model. However, if any/all of the "integer.decimal" V+E Expert inputs have nonzero decimal (Short Trade spec) and zero integer (Long Trade spec) digits, then it's logically clear that the intent is to run Shorts-Only instead of Longs-Only.
This trick is likely *only* needed when doing research to find an "optimal" input-pattern for Short trading ... in actual practice, the Strad would be set up for BothLS with separate eval's, and both integer and decimal digits would be nonzero. I realize this trick is sort of complex ... but hey, it's definitely one that only power-users might need. I'll create a how-to video explaining the whole thing, fear not.

A. Summary ... all that discussion results in the conclusion that only *one* slider is needed for BarWndo control ... it will use the same 3-digit pos & neg input rules as before ... and the manual override will implement the "M" digit for expanded range, with +override meaning BothLS, and -override meaning LongOnly (unless integer.decimal Experts have integer=0).

======= further next-morning thoughts re Expert overrides =======

B. CutGrab overrides ... as explained in #4 above, when I tried to create separate Long/Short manual-overrides for the CutGrab slider, there weren't enough digits available for that complex spec ... so I had to "rube-goldberg" it by pushing four of the necessary digits into totally unrelated sliders (the two that controlled BarWndo). However, per A above, I've decided to go back to just one BarWndo slider ... which has absolutely no extra override digits available to "help out" the CutGrab spec.
The original CutGrab-envelopes override-spec presumed the same pattern is used for both L & S trades ... it used all 7 digits to provide full user-tailoring of the powerful rules which control those envelopes ... here is the full existing spec for that input:
==pos== CutGrabGapSzSm2Lrg- pos FullX: 1-5 => incrs Gap, decrs Tytn (0=off, 6-10=CutOnly)
... InitGap ATRmult 1-5: GrabProfFX= 4x,5x,6x,7x,8x; CutLossFX= 3.2x,4x,4.8x,5.6x,6.4x
... FastTytn%InitGap/bar: 1-5= -24>-20%; Slow=half if abs(G-G1)<WTR/2; 0.x=> AllOff
==neg== CutGrabGapSzSm2Lrg- neg 1-5 same FullX C+G, plus PXit Cut+Grab (neg 6-10=CutOnly)
... PC&PG def=PXsize, gap=FX/2; PC=dkGrayPX, PG=ltGrayPX(notWarn,noAdd); FC&FG=blackFX
==ovrid== CutGrabGapSzSm2Lrg- GPFCAUT: init gap ratchets w/price & tightens with time
... T=FstTytn/bar 0-9= 0|18>26% *InitGap; G=GrbS & C=CutS XitSiz 0-5= PX|10-50%;
... Part+Full 0-9 (0=off) ATRgaps*: Grabs P= 1-4x, F=2-8x; Cuts A= .8-4x, U= 1.6-8x
... Use EndV's PXsize for G or C =0; set InitGapMult=0 to deactivate specific line(s)


Note also that even the "standard" (non-override) spec for this slider had some extra tweaks ... input-values of 1-5 specify Cut & Grab envelopes, while (parallel) 6-10 input-values limit it to just Cut envelopes, but use gap-spacing similar to 1-5. Negative slider values add Partial-Exit envelopes to the Full-Exit envelopes that pos or neg slider values define. Yes ... this is a lot to expect the user to remember ... fortunately, as the slider is adjusted, the lines appear and move around on the plot in an obvious fashion ... which makes things more intuitive.

The combo of the pos & neg slider functionality, with the powerful-but-complex 7-digit manual override makes it pretty clear, in retrospect, that the CutGrab slider really should be TWO separate sliders ... one controlling LossCuts, and the other controlling ProfitGrabs. Since there's now room for one new slider ... this is the way to go. It simplifies and clarifies the entire issue.

Also, to further simplify use, I'm bringing the CutGrab controls under the wing of the VoteGuru. That is, when either of the CutGrab sliders are set to zero, the 0-input's spec will be dictated in a logical fashion by the value of the VoteGuru "Tyt2Lax" slider (just like the Bgn/End/Fuz sliders are, now). This keeps the "Easy" version clean ... no separate CutGrab sliders will show up there (Xprt, Powr, and Cstm versions *will* show CutGrab sliders). When VoteGuru is "Tight", the envelopes are too ... when it's "Loose", so are the envelopes. Simple, and logical.

With this mapping to the VoteGuru, and also with the integer.decimal L.S rule in play, it means that the LossCuts and CutGrabs sliders will use a range of -6 to +6. Zero means "use the VoteGuru rule". Positive specifies Full-Exit envelopes; negative spec's both Partial & Full-Exit envelopes. 1 > 6 adjusts the envelopes from "Tyt2Lax" (like the VoteGuru), gradually moving them farther away from the candles. +6 turns off the adjustable Full Exit line; -6 turns off Full Exit line but keeps the Partial Exit in play; +/-6 for Cuts retain a wide-gap fixed Broker-Stop line; VoteGuru doesn't ever select +/-6 automatically ... that requires nonzero Expert input for LossCuts &/or ProfitGrabs sliders.
The +6 > -6 range is all single-digit ... therefore, the previously-discussed "integer.decimal" shortcut for distinct L vs S modelling will work fine here.

The many internal factors that affect the formula which are currently keyed to a 1-5 range, as documented above, will remain as is. But since there are two sliders now, that "makes room" for "clean" explicit Long vs Short manual overrides for all those factors.
The existing 7-digit override is GPFCAUT ... GPF applies to Grabs, CAU applies to Cuts, and T is applies to both. G/C define Partial-Exit size; P/A define Partial-Exit gap-distance; F/U define Full-Exit gap-distance; T specifies how quickly the envelope-gaps "tighten" over time. However, there is no way to indicate how these spec's should differ for L vs S trades ... and it certainly does make sense that the envelope-gaps &/or PXit-sizes &/or tightening might optimally differ for L vs S.

The new separate LossCuts and ProfitGrabs sliders can each have their own 7-digit override. It seems clear that the Full and Partial Gap-distances should be separately spec'd for L vs S (2*2=4 digits). Tightening currently is T=FstTytn/bar 0-9= 0|18>26%. PXitSize currently is 0-5= PX|10-50% (0=noPXits). The 7-digit OT limitation means that one of these can be independently L vs S controlled, but the other will function the same way for L & S.
Generally, S trades "move faster" than L trades (exceptions found in an extended bearish markets) ... there are usually fewer total bars in a S trade. This implies that there will be fewer opportunities for PXits ... arguing that they may need to be bigger for S than for L trades.
OTOH, Tightening is a relatively "fine" and somewhat arbitrary adjustment (tho considerable research went into it) ... the median value is a reduction of 24%/bar when "fast" conditions warrant (too complex to describe here). The definition of "fast" already adapts to the typical "speed differences" of L vs S moves ... therefore, a separate L vs S spec for T would be redundant.

The 7-digit override for each of the envelope sliders will be spfSPFT, where T is tightening for all cases, SPF is for Longs and spf is for shorts. S|s defines the size of partial exits; P|p defines the gap for partial exits; F|f defines the gap for full exits.
Hopefully that extended explanation is clear, and has helped you better appreciate the smarts behind these features, as well as the degree of control available to the user.

B. Summary ... the CutGrab -10 > +10 slider becomes twins: LossCut and ProfitGrab, each -6 to +6 ... they are both brought under the aegis of the VoteGuru slider mapping, when their inputs are zero, and neither shows up in the Easy version. Cstm version manual overrides are easier to understand and allow fully-distinct spec of how envelopes work for Long vs Short. Integer.Decimal inputs are allowed as well, for separate L vs S expert models.

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

WHEW! I think that finally closes the revision-loop which started off due to the separate Long vs Short idea, and the TradeLog backtesting-tool opportunities. The net result is, I believe, easier for the user to understand than before (Equity slider separate, and Cut/Grab independent but under Guru control) ... with far greater modelling flexibility.

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

Based on comments above, and extensive discussion in the TradeLogs thread, the Positive, Negative, and Override sections of the Input-Parameter Definitions have been "updated" here:

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

Comments and questions welcome ... but please read this at least twice, first ;~)
Top of the page Bottom of the page
JimDean
Posted 10/8/2019 8:20 AM (#9745 - in reply to #9743)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Almost finished with the TradeLog engine ... here are some reminders re its usefulness:

1. TLB output file provides full history of all bars of all Symbols during all Trades that use a specified Strad input-Pattern across a specified test Window for a given bar-length

2. TLS output file provides 13 metrics, both "classic" ones and TradeTight-exclusives, derived from all the trades in the parallel TLB file, listed separately for each Symbol

3. TLB output is designed to "feed" the StradFolio analysis spreadsheet ... a major expansion of Portfolio Simulator to handle the Stradicator-Paradigm's special capabilities

4. TLS output is designed to "feed" the StradWiz analysis spreadsheet ... a Stradicator-Paradigm expansion of Strategy Wizard, used to find "optimal" modelling-patterns

5. Both TLB & TLS files are in standard "csv" (comma-separated-variable) Excel-import format ... users can easily design custom spreadsheets of their own to utilize them

6. Check out the TLS file's list of an organized collection of statistical metrics which are used by StradWiz ... updated today ...
http://tradetight.org/forums/thread-view.asp?tid=1445#M9645

(many thanks to Mark Holstius for his commitment to help develop the StradFolio sheet)
Top of the page Bottom of the page
KenWilsdon
Posted 10/9/2019 8:57 AM (#9746 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Friend

Posts: 48
25
Location:
: ,
Looking at the "can be calc'd " values only, if I want a quick look at the values and for some reason do not want nor have time to run StradWiz because of other engagements, I would like to see in the file:

NetPL = SPL (can be calc'd)
ProfFac = PF (can be calc'd)
APLvsADD = APVD (can be calc'd)
Calmar = Calmar (can be calc'd)

The others could go to StradWiz as far as I am concerned (afaiac).

Thanks for the feedback. That kind of info is helpful to me re what the Return Value options should be for the Easy/Xprt versions of the Strad ... ie what the user might choose for output to the Focus List, or for use in an OmniScan.
OTOH, the TradeLog output files ... specifically TLS in this case since it provides all the stat's from each Symbol's run ... are THE SOURCE for any StradWiz analysis. As such, if a user might want to see any value in StradWiz, then that value must be present in the TLS file ... or it must be easily derive-able from other values in the StradWiz file. For instance, if StradWiz includes NetPL and also SumProfTrds, it's easy to calc SumLossTrds = NetPL-SumProfTrds.
Top of the page Bottom of the page
JimDean
Posted 10/9/2019 11:27 AM (#9747 - in reply to #9746)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Ken ... note reply in blue to your post above ... I'm trying to keep responses together in context.

I've been giving a hard look again to the Metric Stats that will be calc'd by the Stradicator, and made available individually via Return options for FocusList, OmniScan, etc function calls ... as well as en masse via the TradeLog TLS output file. I did a major revision to the post that is linked from several places ... the original content is still there but it's small and hard to read on purpose.

I hope that the revisions are a bit easier to follow.

Any of final six values are, I believe/hope, very good overall measures of the performance of a given Stradicator pattern-model, for a given Symbol, across a given test-window. Time will tell which of those I recommend most strongly. I'm not sure yet which one(s) of them will be avail to the Easy version ... the Cstm version will offer them all ... Xprt & Powr will offer intermediate subsets.

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

Note re CAGR & Calmar:
For reasons that require a long explanation ... having to do with the "evils" of Compounding for backtest analysis, and the "pitfall" of metrics that vary based on initial Account Size, and the "unrepresentative" nature of MDD & annualization ... I might decide to *eliminate* CAGR & Calmar completely. If I do include them, I will need to *modify* the CAGR formula somewhat to fit into the Stradicator Paradigm's %Basis "sizing". I've emailed a couple of you about this in detail, for comments and suggestions.

Note re "Holmark" metric:
Mark Holstius did a huge number of tests to develop an empirical formula that I'm calling "Holmark" (sounds like Calmar and hallmark, as well as Mark's name ;~). The tests were based on tens of thousands of RTM trades over many symbols and years. He restricted the terms of the formula to components that are available from PortSim outputs (HitRate, SumWins%, SumLoss%, #Trades, SumPL%, ProfPerTrade, and AvgLoss%).
I'm not sure yet if I'll include Holmark in the Return-Value options and standard TLS file output. It definitely will be part of the StradWiz and StradFolio sheets. For now at least, I'm not publishing Mark's formula. It's an excellent empirical fit ... with a huge database ... but since it's based on RTM strategies that have short hold-times and their own particular "take" on things, I'm not sure if it will work as well with other types of trades ... the confidence we have is based on visual evaluations, rather than theory. By contrast, the formulae in the linked-post above have not been tested *at all* (yet) ... but they have a clear and logical theoretical basis.
Thanks, Mark, for offering this!

Top of the page Bottom of the page
JimDean
Posted 10/12/2019 12:49 AM (#9748 - in reply to #9747)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Boy am I glad that Ken Wilsdon is back from overseas ... he is a fantastic helper, especially when I get mired down in decision-making about complex details. All of you should thank him for devoting countless hours of phone time to assist with this project!

After repeated rethinking and extended conversation with Ken, I finally feel really good about the collection of metrics that the Stradicators will calculate, and make available via Return values as well as in the TLB (StradFolio) and TLS (StradWiz) files. I've updated the reference list once again ... here is the link. This is important and to some degree groundbreaking stuff, so it would be great if many of you could chew it over and ask questions or make comments ...

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

Here are some notes about the recent decisions ...

1. For each Trade, I'm already reporting NetPL as well as WmaTR & TradeQuality (fancy denominator formula). I'm going to also report the TrdMxDD for each trade ... together, these allow simple external calc (from TLB file) of NetPL/WmaTR or NetPL/TrdMxDD if desired (TrdMxDD has a "Band" in #2)

2. I decided not to report StdDev or Variance or WiggleAvg ... all are messier to calc than I think their value is worth, especially since the TLS metrics are Symbol-specific, and in many cases the sample-population will be very small. Instead, I'm providing a "Band" value in addition to the related Average ... the Band is equal to the (Max-Min)/2 ... so, "Average+/-Band" gives a pretty good idea of what's going on, without worrying about how many trades in the population. I'm providing this for: TradeQuality, TradeMDD, and #BarsInTrade

3. I'm providing a "sorta-Calmar" with note re "focus on max sustained drawdown", as well as the "HolmarkRR" with note re "focus on RTM, from Mark Holstius" ... thanks again, Mark!

4. The final set of three pairs of RwdRsk values are much easier to understand now ... Average of Trade NetPL/MDD, and Average of Trade NetPL/WTR each have their "Ngd" PctActiv variants ... then the *composite-risk* Average of TradeQuality values ... with Ngd variant. The TradeQuality "Band" from #1 pairs logically with the overall TQ values.

==========

Re the TradeLog engine ... I'm *finishing it up today* (hurrah). It is universal, very easy to use and understand, and doesn't require a bunch of file-maintenance by the user.
Top of the page Bottom of the page
JimDean
Posted 11/1/2019 12:08 AM (#9762 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Hi all -

Lots of positive (and exciting) progress being made in the last few weeks. I’ve been at it an average of 12 h/d, 6 d/w … I’m not posting progress since it doesn’t seem to be something that y’all want to interact about. No worries - Ken Wilsdon is back and we’ve resumed the incredibly productive and insightful (and quite long) Skype sessions every day or three.

The TradeLog engine is completed. It has greater functionality, flexibility, and convenience (re user interaction) than I’d originally imagined. I’ll update the documentation on it in a while.

In the most recent week, I’ve been digging in to get the various “levels” of Trade Plans in order. There will be four: NtryTP, PXitTP, AddsTP, SmrtTP. The last one is what I’ve been referring to earlier as the “Robust” TP. The first is what I’ve been calling the Simple TP (scaled Entry and various Full Exits, but no Partial Exits or Dynamic Adds. The middle two gradually expand the NtryTP capabilities. Lots more on that later.

It was necessary to put meat on the TP bones early on, since their structure has to mesh usefully and flexibly with the Stradicator modeling, and with the slider-layouts and meanings that are locked in to the paradigm. Also, Ken has a limited time window to help out by being the TP Typist - a huge job, working from the detailed spreadsheet TP layouts and manually entering the structure into the actual OT TradePlan editor (N said they weren’t interested in helping automate this). Yo give you some perspective, the SmrtTP (most complex of the four) has ~1500 total Steps + Conditions. And there are four versions of it (one for each of four order types). The other three are significantly smaller (~350 & ~200 lines for AddsTP & PXitTP) …only the NtryTP, with ~30 lines, is “typical Nirvana-sized”. Each of those has four versions, too. Be sure to thank Ken for helping out with this - his work will parallel mine and result in delivery of the full suite of TP’s months sooner than I’d originally planned.

The third major area of recent work is locking down the paradigm regarding the Envelope slider functionality (MANY aspects controlled by just three sliders), the addition of a sixth envelope line for “stairstep” partial-profit grabs, the refinement of the “chatter+projection” logic (the “CP” of “SCP”), the ability to flexibly spec a huge spectrum of output windows (using just one slider) - up to a range of ~200k historical bars (that’s about two years of one-minute bars).

The fourth area of planning and coding has addressed the natural desire that an experienced trader has, to tweak the way that Long versus Short trades are managed. The Strad Paradigm has been enhanced to make this easy and natural. You’ll now have four choices instead of the standard three offered by Nirvana: LongsOnly, ShortsOnly, Long Plus Short using the same analysis settings … and the new option is Long plus Short using alternative settings. The implementation is simple - if you want a 1-9 slider to use a 3 for Longs and a 6 for shorts, you just manually type in the two values rather than using a single digit input. This capability will focus on the paradigm-sliders, rather than the sliders that affect the individual core Strad logic. Same playing field, but different “response times” and “threshold levels”, etc for the two different trade directions.

One of the most exciting things came up today as Ken and I were chatting. I realized that the paradigm-trick that I had planned for open-ended, user-choice integration of external filters via a single manual value in one of the Guru inputs … that feature can also be used to collect the analysis and trade management for any number of disparate Stradicators, together under one umbrella. Sort of like OmniVest in some regards. Nutshell: you might have 3-4 or more *different* Strad’s (SCP, CVW, HAT, etc) all engaged at the same time, working over the same Focus List … and/or multiple instances of the same Strad with different input-patterns. Each of these will include individual equity-tracking and filtering … on a symbol by symbol basis.

What this means is that for any given symbol, there can be multiple Strad’s seeking potential trades at once - and only those Strad’s whose recent performance has been good *on that Symbol* will offer up live trade candidates. If there are more than one of the Strad’s which present an opportunity for a given bar, the decision on which to hand the control of that trade off to will be based on the really comprehensive Equity Stats that I detailed earlier. Once a Strad is chosen to trade that Symbol, it will manage the trade independently till conclusion - then the free for all begins anew to see which of the Strad-team will come up with the next trade. This is continuously going on for all the symbols in the Focus List.

Not only that, but the “collective Stradicator ménage” of trades for each Symbol will employ an over-arching Equity tracker+filter, whose main purpose is to decide whether that Symbol should stay live on the Focus List, or be temporarily dropped due to poor performance.

There’s a lot more too but I hope you get the picture. Intensive work, careful planning, and additional synergistic benefits. Hang in there - this is going to be IN-credible stuff!
Top of the page Bottom of the page
JimDean
Posted 11/3/2019 1:48 PM (#9766 - in reply to #9762)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
I've just created another "Documentation" thread, focused on the special TradePlans used with Stradicators. Like the other "Reference" thread, it's dedicated for explanations, so you can't post on it. However, please feel free to post comments and questions in THIS thread ... if necessary, with links to the specific post in the other thread that you're talking about.

Here's the new thread:
http://tradetight.org/forums/thread-view.asp?tid=1450
Top of the page Bottom of the page
JimDean
Posted 2/27/2020 12:00 PM (#9774 - in reply to #9766)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Hi, all ...

It's been a while since I've posted about progress. Three of you have emailed me queries in the past couple of months ... I just got one today. Here's the explanation and status, in full detail.

Nutshell ... extended corporal & computer health issues really slowed things down, BUT both are (nearly) back to normal, and I'm once again charging ahead in my typical intensive manner.

=======

There are several reasons for the hiatus in postings:

1. I was getting very little feedback to questions, and usually what feedback I got was significantly delayed (versus my speed of progress), and/or very non-specific.

2. Once Ken Wilsdon got back from overseas, I was able to work directly with him as I have in the past, via (long) Skype sessions and emails several times a week. That was very beneficial, but no one else in the group had that kind of time available. So, forum postings tailed off since he was the only one "engaged" ... in a more direct manner.

3. Around December, Ken picked up some new activities and was no longer able to participate regularly. Without that interaction, and with the other issues (below), progress slowed.

4. About that time, I started having *serious* computer issues, and spent many hours (70+?) on phone with Dell support ... several hardware fixes (motherboard twice, etc) ... multiple Windows & Driver re-installations, etc. This continued off and on up until mid-February ... for two months my machine was essentially non-functional. Finally, a Dell "Resolution Manager" took ownership and agreed to replace my 3-yr-old high-end machine with a brand new (much better) one. Due to COVID-19, their build-deliver time is extended ... but I should be getting the new machine (Precision 7540) in mid-March.

5. Along the way in #4 process, I was able to "cobble together" enough functionality (had to move back to Win7 since Win10 could not be made to work adequately) so that I could work on programming. However, the huge frustration of the #4 process (which initially started back in Sept-Oct) affected my "head space" ... I didn't want to even *look* at the machine. Dumb, I know, but real.

6. Some might ask ... just one computer? I have a working desktop works but it's in a room that my son has taken over for one of those "temporary" (nearly a year now) "move back in during cross-country job-transition" situations. I like having him here, but really don't have room for him. Since his work/sleep sched is about 6-8 hours different than mine, I haven't been able to use the computer in "his" room.

7. Ever since last spring, I've been beleaguered with nearly-continuous migraine-like headaches (plus intermittent vertigo). Neurologist helped some, but said if I followed his spec'd regimen, it could take a year (or more) to get more or less back to normal. It's working out that way. This mostly knocked me out of effective coding, during late spring / early summer, and slowed me down a LOT in the late summer / early fall (exacerbated by #4). When the headaches were bad, it was effectively impractical to program or do anything else requiring extended concentrated focus. Thankfully, the last couple of months have been meaningfully better ... and hopefully the slow improvement will continue.

=======

Perfect example of the aphorism: "When it rains, it pours".

=======

The GOOD news is that:

A. Headaches/vertigo issue is infrequent and much milder now ... no longer a debilitating problem.

B. I have gotten the laptop to "adequately function" in (out of support but stable) Win7 ... thanks to the Resolution Manager, I don't need to keep rebuilding and talking interminably with Dell Support ... and the brand new laptop is coming in 2-3 weeks (if all goes per projections).

C. Generally, I'm "back in gear" ... spending my typical 8-12 hour days coding etc now.

========

When I did get back in gear, I decided that I had to deal with the MTV fixes/updates that I've been putting off for 18 months or so ... this affects core code that I use for Stradicators also. I have been contacted by MTV clients on several occasions about this.
Last release was for OT2018 ... I found out that I had to fix an insidious licensing-algorithm bug that only showed up for one client ... but totally locked him out ... plus do normal recompilations ... and update for Zacks, plus a cool new composite-metric option. Icing on the cake ... Nirvana decided with OT2020 to release their own "MTV" ... "multi-timeframe-vision" ... which forces me to come up with a new name (for clarity). Sigh.

The "breaks in continuity" on the Stradicator work ... created by the computer hassles ... made this an appropriate time to get the MTV thing off my plate. I've got maybe another couple of weeks and that will be completed. About a third of that work affects "core" code that also will be used for all Stradicators. Another quarter of that work affects the planned "PVT" Stradicator (changing the name to "STV"). ALSO, the new MTV (to be renamed "PTV") will be designed for integral implementation as a very powerful Filter, that can be used integrally with any Stradicator. I'm very excited about that. (prior posts here discussed that feature in general)

========

I've only received inquiries from three people, and I answered each to explain the situation. I'm very happy that THIS explanation, though definitely the "longest" ... has finally got some good news, and the corner has been turned.

My hope/expectation is that I'll be coincidentally finishing up the MTV stuff when the new computer arrives (mid-March). Couple of days to get it set up with apps etc, then back to regular Stradicator work.

At that time, I'll "survey" the y'all to see who really truly wants to get regular forum postings, AND is willing to commit to read them and respond meaningfully to them in a *timely* fashion. Timely means at least *some* on-topic responses within 1-3 hours ... or if my post was at end-of-day, responses ready early the next day. The reason for the quick-feedback need is that I'm usually working on the very thing that I'm posting *about* ... and a delay of even just one full day usually means that I'm long past the point of being able to actually *use* the feedback, without having to waste time backtracking.

=========

There ya go ... definitely "TMI" but I hope it assuages any concerns y'all might have. If corporal and computer "health issues" had not so rudely interrupted me over the past ten months, I would have been much further along by now. But I am excited to be back in gear now ... and even more enthused with the Stradicator plans.

Thanks again for your support!
Top of the page Bottom of the page
MarkHolstius
Posted 2/28/2020 8:00 AM (#9775 - in reply to #9774)
Subject: CVW Journal & DISCUSSION



Veteran

Posts: 209
100100
Location:
USA: IL, Sleepy Hollow
Sooo glad to hear things are starting to get better, Jim!

Your health is more important than any project you might have committed to.

Be well, my friend...

Mark
Top of the page Bottom of the page
JimDean
Posted 3/1/2020 1:42 PM (#9785 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
I've spent the last 3-4 days digging deeply into the various changes N has made in Industry Group support. We now (finally) have Zacks, and that info is being updated frequently. Also, we have the "ZR" and "ZIR" Zacks-proprietary ranking, fwiw. The MG info is still out there, but that structure has been "frozen" for about 6-7 years now ... and even though N will likely keep it around for legacy support, it likely won't ever be updated further.

At the core of MTV ... being renamed as "PTV" , which is what I'm working on now per prior post, is the "SymsMap" routine and database text file which not only allows PTV to do amazing multi-tier filtering stuff ... such as a filter that is based on the weighted PTV scores for, say, the SPY, and the Sector, and the Group, and the SubGroup, and the Symbol itself ... this is something that is not possible in native OT, but PTV makes it easy. The key is the SymsMap lookup ... the second Parameter of PTV ... which is a big table holding cross-reference info for all useful Indexes, and all Industry Average symbols (the old MGsig and soon, the new ZGsssiiiggg where s= sector#, i=group/industry#, and g=subgroup#) ... plus every one of the US Stocks and ETFs that are mapped to *any* of the MG or ZG industries.

I have to do some extensive work to update the SymsMap table, in order to get Zacks supported ... the structure allows for it, but a bunch of manual screen-capturing and pre-processing is needed, since N tables themselves are a bit wonky. And of course that means the PTV routine needs its Help popup lists updated, and so on.

A related mini-project that I considered doing when MTV first came out, and that I'm revisiting now, is to automate the identification of Lead-Lag symbol-pairs, such that when an entry/exit Signal is created for a Leading Symbol, it's used to *trade* an offset-correlated Lagging Symbol (providing the Lagging Symbol is not hugely counter-indicated). This is *not* "pair-trading" ... N has a plugin for that. It's a way to get in/out of a trade EARLY. I've got a procedure mapped out for how to do it, which I'm pretty confident about.

----------

That's a lot of busywork ... and I want to find ways to leverage it as much as possible, either making PTV smarter than MTV was ... or (if it makes more sense), enhancing the existing but lesser-known "SymsNfo" routine to provide a powerful tool to draw upon the expanded SymsMap database.

SO ... QUESTIONS for each of you ...

1. Are any of you *particularly interested* in trading methods based on "tiered filtering" such as I mentioned earlier?
(a strat filter using weighted SPY, MG#, MG##, MG###, Sym)

2. Are any of you *particularly interested* in trading methods based on "lead-lag" dual-symbol relationships described above? (ie using one sym's leading sig to trade a lagging sym)

-----------

If you are interested in either or both, please email me, or reply here ... tell me specifically for each of those two:
a. Presuming that it works well, you'd be interested in buying it (not part of Strad pricing)
b. You have time available during the next few weeks to actively participate in devel discussions.

I need responses back SOON, please, so I can map out my activities. Thanks!


Top of the page Bottom of the page
MarkHolstius
Posted 3/1/2020 2:05 PM (#9786 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Veteran

Posts: 209
100100
Location:
USA: IL, Sleepy Hollow
Jim,
Both ideas sound interesting - and I’ll invest in anything you develop that works...
Unfortunately, I don’t have the time to contribute to the process.
Mark
Top of the page Bottom of the page
JimDean
Posted 3/1/2020 3:22 PM (#9787 - in reply to #9786)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Thanks for the quick reply, Mark ... I hope others will get back to me soon too.

I forgot about one other thing. A few of you might recall that a couple of years ago, I worked on a tool that I called "ListRank". It was designed to be generic for any "guru-list", but was supposed to be initially "fed" by the IBD-100 rankings. A client had committed to providing the list-data to me on a weekly basis, if I provided the tool to him in compensation. IIRC, I got the tool working, and pretty well polished, but there was an issue getting adequate IBD back-history ... and another issue with getting timely week by week submissions.

So, the project languished. But the code is still out there, and I could resurrect it without much trouble.

The reason I mention this is *not* to solicit another "IBD-100" info-supplier ... that ship has sailed ... but rather to redirect the algorithm to be driven by the brand-spanking-new Zacks Rankings. There are two of them that OT supports: the focus-list columns are labelled "ZR" and "ZIR" ... and, as usual for N but even moreso in this case, there is NO documentation.

I've found out that the function-call (ie Indicator) for ZR is "ZRank()", and for ZIR it's "ZIndRank()". You can plot them as Quick Indicators ... and you'll see why documentation is needed. I've written Barry for details, but I'm very optimistic and enthused about what these offer.

Afaik, these are "proprietary" Zacks values, sort of like IBD ranks or ones avail from many other sources. The KEY piece of info is that they are *time series*, not just HRE fundamentals. They can be plotted, or evaluated in OLang.

So ... I can resurrect the ListRank tool, but use the ZR and ZIR ranks to drive the logic, so no manual weekly data input is needed. Huzzah!

-------

The QUESTION is ... are any of you interested in buying a tool that uses ZR& ZIR information in a clever and sophisticated manner, to create Entry &/or Exit signals? (or filters).

The logic is not just simple threshold crossovers. It looks at the progression of the values over time, as well as the place in the rankings, as well as the performance of the next step up.

And, it's back-testable.

This ties in with the SymsMap rebuild I'm working on now, btw.

So:
1. If the tool is created, are y'all interested in that kind of logic to help drive your trading?
and,
2. If you're interested, do you have time avail during the next few weeks to participate in devel discussions?


Again, a quick reply here or via email would be much appreciated.
Top of the page Bottom of the page
RobertPfoff
Posted 3/1/2020 9:37 PM (#9788 - in reply to #9641)
Subject: CVW Journal & DISCUSSION



Friend

Posts: 19
0
Location:
USA: PA, Warrendale
They both sound interesting to me but of the 2 I am more interested in the lead-lag indicator
Top of the page Bottom of the page
KenWilsdon
Posted 3/1/2020 11:19 PM (#9789 - in reply to #9787)
Subject: CVW Journal & DISCUSSION



Friend

Posts: 48
25
Location:
: ,
Hi Jim,

It's good to have you back in the saddle.

I like the idea, and would be interested in that logic to drive trading.

I have been delayed getting back to Nepal, so I have parts of about 2 or 3 days a week that could be used for discussion, at least for the next 3 or 4 weeks (maybe longer depending on the Corona virus in that part of the world, and if I am still delayed by other circumstances beyond my control). Of course, when I get back to Nepal, I will be unavailable. Email me and we can arrange something.

Maybe that could get you started with some feedback for the initial phase of the project.
Top of the page Bottom of the page
LDNewby
Posted 3/2/2020 12:45 AM (#9790 - in reply to #9787)
Subject: CVW Journal & DISCUSSION



Friend

Posts: 37
25
Location:
USA: VA, Vienna
Hello Jim

Welcome back. My level of interest is:

1. List Rank Update - "High Level" - willing to participate in any development Work

2. Tiered Filtering - "Low interest"

3. Lead Lag Dual System - "Very Low Interest"


In my preferred style of trading (Momentum), I have seen major improvements in the results based on list selection. I don't currently have any positive experiences with tiered filtering and Lead/Lag Systems. However, I have been known to change my mind from time to time.

LD

Top of the page Bottom of the page
JimDean
Posted 3/2/2020 8:03 AM (#9791 - in reply to #9790)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Thanks for your replies and interest. As I suspected, each idea appeals to some but not all of you - everyone has a different perspective and approach to trading.

I’ll continue to flesh out each area as long as I don’t hit significant snags. My primary goal right now is to get the MTV=>PTV upgrade done, which necessarily calls for a SymsMap rebuild, and likely SymsNfo to go along with it.

Here are a few more thots to feed the kitty …

1. The tiered filtering approach doesn’t actually require any special new coding - it’s inherent in existing MTV, if the strategy that uses the MTV filter is constructed appropriately. All it needs is the SymsMap database … updated for Zacks of course. The goal of this is to block “chatter” and to help find trades that might be sustainable for longer periods (ie with lots of inertia). Probably not crucial with the volatility and dare I say bearish flavor we’re encountering now - but the only thing certain, as they say, is change. The only important aspect to this feature is the ability for the Stradicator paradigm to incorporate the Filter rules within the full strategy-in-an-indicator envelope … so that equity curve control, and smart scanning, and other Strad features all work properly. I’ve already created the architecture for that via the “Guru-override” Filter inputs, which link to external nested Indicators that powerfully implement any Filters you might want. So, this feature won’t require any extra work at this point, beyond the Zacks SymsMap update.

2. The lead-lag method is, by contrast, potentially the most time intensive to “birth”. However if it works out to be viable, I could see it becoming a “standard” optional feature within the Strad paradigm. If the user toggles it on, then it would first find out if there is currently a meaningfully-“leading” symbol within that Industry (or ETF?) which can be used as a proxy for the current symbol. Determining that will be the “trick” - requiring a bunch of nested-loop correlation studies (maybe a bit of a CPU hog). If it finds a leader that has sufficient (offset) correlation to the current symbol, then:
A. The Strad logic will be applied to the leader-proxy, with nominal “filter” type checks on the current symbol actually being traded (this is the most aggressive approach, primarily for early Entries) … and/or …
B. The Strad logic will trade the current symbol, but include the leader-proxy symbol’s “filter” state in the decision making (this could assist with early Exits at times when a radical reversal is shaping up).
… lots there to mull over …
The key factors to keep in mind with lead-lag are that things change continuously. An given lead-lag pair might be ideal at one time, so-so a bit later, or useless as time rolls on. My original idea years ago was to preprocess the correl studies and incorporate the pairs in the SymsMap text file. This would have required users to “subscribe” to weekly or monthly updates to the file … and required me to regularly do the busywork of rebuilding it. However, since I hate busywork, and users hate repetitive updating, even though the extant SymsMap file architecture provides for lead lag inclusion, I *don't* think I’ll go that route.
Rather, if I can build a viable and efficient engine to do the lead lad correlation searches and confirmations “on the fly”, that would seem the most attractive approach. This may well include an external text file to store historical “finds” and speed things up … remains to be seen.
So - although this idea holds a lot of promise, it’s definitely the most time intensive. Since it’s essentially a separate “module” of code, for the immediate set of tasks, my plan is to modify the SymsMap file and I/O code to get rid of the provision for pairs-subscriptions … and to leave necessary “hooks” in the Strad architecture so that it can be included later. This may well be done via the versatile “Guru-override” Filter inputs (not sure yet).

3. The ListRank approach, using OT-piped ZR and ZIR rankings, draws on my prior work for the decision-logic, but probably dispenses with the “universal guru-list” database-text-file mechanism which I worked so hard on, a couple of years ago. Sigh. Not much use for it, if there are no timely data updates. However if I can leave a “hook” for it to be implemented later, I will. There are a lot of guru lists out there besides Zacks - and if someone is enamored with one, this tool would definitely be the ticket.
For the immediate future, the key is to utilize the list-analysis logic to optimally eval the ZR and ZIR ranking dataseries (I’m waiting on some extra info from Barry to do that). Again, although this could be an independently tradeable entry/exit thing on its own, I suspect that it will serve much better as a filter for Entries and possibly as a backstop “watch out here comes a reversal” check for exits.
This will only require a moderate amount of work, if all goes well. And, if it’s implemented as an Entry/Exit adjunct filter, part of the work might be defer-able.

=========

Again, my immediate goal is to finalize SymsMap architecture, and repopulate that database to fully support Zacks. After that, the next target is to get the MTV=>PTV upgrade completed usefully but quickly. It seems fairly likely that one or more of these three ideas might “slot in” nicely with PTV … but otherwise, presuming they are viable … they would become additional Filter-Indicators, structured to work naturally with any of the Stradicators (as PTV will be).

Whew! Ok enough words for this morning. These posts take a while. But hopefully is brings things more into focus for y’all who are interested.
Top of the page Bottom of the page
JimDean
Posted 3/5/2020 1:43 PM (#9800 - in reply to #9791)
Subject: CVW Journal & DISCUSSION



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Update …

During the past several days I’ve dived in deep, figuring out the inner workings (and bugs) related to the Zacks implementation for SIG categories and Rankings of stocks and ETFs - Z is the vendor that now supplies the ETF components, as it turns out. I must have exchanged 40+ emails with Barry along the way - documenting bugs, asking for clarifications, etc. As usual, he’s been a real trouper. There are some definite bugs (lots and lots of popup errors), and Cose is taking a look at it “when he has time”. I’m holding off now - hopefully I’ll get some hints tomorrow about what and when things might be fixed.

The reason for doing all this now, as mentioned in prior posts, is that I need to rebuild the massive SymsMap data file that MTV=>PTV uses, to include Zacks structure … and also to possibly include info re constituents of ETF’s.

That big file, and the SymsNFo engine that accesses it, will drive not only extant PTV functionality (in the upgraded version), but also will be the backend resource for any Lead/Lag algorithm. The L/L could be solely Zacks/MG oriented - but I think it would be great if it could also draw from the bundled ETF constituent lists.

I’ll be happy to get past this phase - lots of mind-numbing gruntwork, PgDn-ing thru huge focus lists, and screen-scraping text-capture of info that OT doesn’t have Export options for. One good thing that might come from this is that maaaybe I’ll be able to convince Cose to add a Reports export option to include Group Trader columns. That would really kick this into high gear.

That’s the status. Stay healthy, everyone!

ALSO: in case you missed it, check out the new thread I created to serve as a knowledge base doc for Zacks, here … http://tradetight.org/forums/thread-view.asp?tid=1453
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.