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 Cor 9:8 (NET) ... And God is able to make all grace overflow to you so that because you have enough of everything in every way at all times, you will overflow in every good work.


Cumulative Volume Indicator DISCUSSION
Jump to page : 1 2 3 4 5
Now viewing page 5 [50 msgs/pg]
Jump to room :
SalimHira
Posted 5/2/2019 2:45 PM (#9578 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
Hi Jim:

You said:

"So, *during* the buffer zone, the code first searches for a navy-blue bar ... that is, a neutral bar not (apparently) in a wave. Once it's found that navy bar, then it continues to search, waiting for a full begin-to-end-wave to *complete* ... at which point, a "fully legit and stable" output can be expected."

<<So, basically, this is a hold placement of some sort of "erratic" behavior of Volume while it is playing it out within itself, until it becomes ruly. >>

The thin line is white until a navy bar is found. The thin line is black after the navy, until the end of a subsequent complete trade is found.

<<When these lines appear, I assume it be noted that no trades are to be taken under these circumstances. Buyer/Seller caution placement "at your own risk".>

The third snapshot shows the same 3-mo window, but with the buffer hard-coded to its *normal* value of 40 bars ... this allowed enough pre-output warmup to assure stability throughout the entire requested window, so no black or white centerline appears.

<< Here, I am confused as to why a shorter #of bars shows up with the thin lines, while larger #of bars assures stability, well-noted keeping in mind the warm-up periods.>>

QUESTION: does this sound like a sensible approach? Do you understand its importance?

<<Yes, but kind of concerned with the "speed of calcs". Meaning, if you minimize the #of bars, the thin lines begin to appear, maximize the bars, and speed slows it down. Otherwise, yes, the importance is duly noted, and the appearances of thin lines surely helps understand what may be happening behind the scenes (Bars). >>

Top of the page Bottom of the page
JimDean
Posted 5/2/2019 2:47 PM (#9579 - in reply to #9577)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
further thinking about buffer evaluations ...

I think I missed a bet in my earlier posts - the buffer can be smaller, since the "instability" situation is not as bad as I originally described.

What I need to search for in the pre-output buffer is a bar that is *surely* not part of any existing trade ... ie a navy bar that will be navy regardless of how much historical running-start is evaluated. Once that is hit, then any subsequent wave-inceptions will be certain ones.

Thus far, I have two ways of finding that:

1. a bar where all three strips are zero ... this works, without searching for anything else, since that condition ALWAYS ENDS any trade, regardless of what direction it's headed

2. one full previous "apparent" trade ... starting after a maybe-navy, and ending with any of the rules that can end a trade ... which can be count-related, vote-related, or due to cut/grab bands

I've got both of those functioning just fine. However, it seems to require about 60 bars of buffer-warmup, mainly due to occasional very long trend-trades that start before the buffer does. That not only eats up extra calc time, but sometimes may toss out the next historically-valid trade after the long one ends. So ... cogitating some more about it ...

Say that a bull=green Wave is in progress when the buffer begins ... that is, no initial navy bar ... the first bar of the buffer window meets the BgnVot requirement and away it goes. That bright green bar *could* be the actual first one of the wave (if infinite history used) ... or it *could* be a bar somewhere in the midst of a wave that started earlier (ie buffer starts mid-wave). If it is in fact a midwave bright-green that's "pretending" to be a wave-begin, then DOES THAT MEAN the apparent end of that partial-wave is a "legit" end?

I'm thinking now, maybe so ... and if so, then the buffer can be smaller.

What ends a wave?

a. if all three Slope/Stack/BarV strips each =0 (case 1 above) ... valid even with midwave begin
b. if OppositeVotes count hits threshold ... and that would be valid even with midwave begin
c. if Warn-count hits FullX threshold ... midwave begin might make that later, but not earlier
d. if Reversal bar hits ... ie net Vote >= BgnVot in opposite dir'n ... valid even if midwave bgn
e. if Close crosses outside full Grab | Cut outer lines ... maybe later if midwave, but not earlier

... so far so good ... but ...

f. if sum of Entry+Adds-PXits-PCuts-PGrabs drops to zero (ie no more shares in trade), trade is over

THIS is a potential gotcha. If the buffer-window partial-wave begins *after* the "real, full" wave would have (if there was more data analyzed), then some ADDS might not be accounted for. Also, the size of the initial Entry is a function of the net Votes that start the wave ... or related to ToeIn rules. The combos of the Entry size with possible Adds are unpredictable. So, we don't know in the case of the mid-wave-start during the buffer, whether the PX+PC+PG share-reductions are enough to kill off the total shares.

THEREFORE ... it would seem that all of the rules a-e above which end a mid-wave-begin buffer case would be *reliable* flags to indicate that subsequent trades are "legit" and "stable" for output and scan and equity eval purposes.

So ... I'm going to simply turn off that "f" method of ending a wave, UNTIL one of the other a-e methods have ended the wave. This means that the buffer-window can be smaller - I'm changing it to 40 bars ... prelim tests indicate that will be adequate in nearly all cases (30 is so-so).

It also means that the center-line color will work a bit differently. If none of the a-e rules are satisfied during the buffer (unlikely), a white centerline will appear in the output-window Band. If any of those rules have been hit, then any subsequent trade is legit ... and from that point on, all rules, including f, will be active. So, no need for a "black" line.

QUESTION: Can you think of any logical cases that I've missed?
Top of the page Bottom of the page
JimDean
Posted 5/2/2019 3:03 PM (#9580 - in reply to #9578)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
Hi, Salim

Here are answers to your prior post, which I didn't see till after my last one:

So, basically, this is a hold placement of some sort of "erratic" behavior of Volume while it is playing it out within itself, until it becomes ruly.

Not really, if I understand you. It's not that the volume is erratic or unruly, nor that the price is. Navy indicates that the three subtotals of the votes are each zero ... or one of the other "end-wave" rules has previously hit, without adequate netVotes to begin a new wave yet.

When these lines appear, I assume it be noted that no trades are to be taken under these circumstances. Buyer/Seller caution placement "at your own risk".

Well ... first, the lines will not appear very often. With the expanded rules that I just posted, that will only happen if the first bars in the output zone are green or red (ie in a wave). If that's the case, AND if the initial bar is bright, then you *could* start the trade if you wanted to. Maybe it would be a late start, maybe not. However, if you're looking at a recent chart (just last 3mo's), then it's very likely that the bright center line will NOT make it all the way to the HRE ... any wave on the left will have almost certainly have ended before the HRE. So ... this is imho a NON-problem, for a trader working from the HRE bar.

Here, I am confused as to why a shorter #of bars shows up with the thin lines, while larger #of bars assures stability, well-noted keeping in mind the warm-up periods.

You've drawn the wrong conclusions. The number of bars visible on the output has NOTHING to do with stability. What matters is what happened BEFORE the FIRST (leftmost) output bar. I showed the final chart just to "reveal" what happened before the first bar of the prior three charts.

Yes, but kind of concerned with the "speed of calcs". Meaning, if you minimize the #of bars, the thin lines begin to appear, maximize the bars, and speed slows it down. Otherwise, yes, the importance is duly noted, and the appearances of thin lines surely helps understand what may be happening behind the scenes (Bars).

IMPORTANT! DO NOT conclude from this that "more bars is better" in terms of the desired output range that you set with the slider. That input should be set for whatever historical window you consider useful and relevant ... in the rare case where a white line appears, an automated strategy will skip that wave ... if you're doing discretionary chart-based trades, as long as the white line doesn't extend all the way to the HRE, you're OK. The "more bars" thing is all happening AUTOMATICALLY, internally, INDEPENDENTLY of your input value. I'd set it at 60 initially ... now I'm using 40 ... and only about 3-5% of the cases have a white line showing up at all ... and in those, it only lasts a few bars then all following ones are "legit".

And, don't fret so much about speed. I'm much more "sensitized" to that than a typical trader might be. I won't distribute a program if it's un-useably slow, at least for "reasonable uses". Most of the robust N strategies will bog down if you create a FL with 3000 symbols, using RT data with 1-min bars. My goal is to assure that TT routines are better than that "typical Nirvana standard".
Top of the page Bottom of the page
JimDean
Posted 5/3/2019 11:38 AM (#9581 - in reply to #9579)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
... mulling-over & consolidating prior ideas into an updated plan ...

The biggest thing is the potential addition of yet another "version" to the pile:
Easy = two Gurus, no expert inputs, no negative slider ranges, no manual-typed overrides
Xprt = Easy + expert inputs with positive sliders only + extra plot option + extra return options
Powr = Xprt + negative slider ranges for guru & expert & CumV inputs + extra plot + extra return
Cstm = Powr + option to manually type overrides for *very* detailed spec's in every area

Main reason for fourth level is that the negative-slider CumV & TymFrm group aren't really "crucial" ... and the negative-slider CutGrab Vote group require the "Robust" TradePlan (supporting Adds & Partial Exits of various types) ... that TP won't be available till much later (this year?). This means that all previous posts that describe the "negative" CutGrab and Vote-group sliders to be "turning off" Partials and Adds and Toe+Cnfrm *now* are *flipped* ... that is, *positive* slider ranges will be the simple non-Add, non-Partial, non-Toe alternates ... Easy and Xprt versions will *only* need to support the simple (standard TP) approach.

This allows me to phase in the features ... I can release Easy and Xprt initially, and later allow people to upgrade to Powr or Cstm once the code and TP's are ready. I'll need to decide whether to move to other routines such as HAT and ADX etc before Powr & Cstm CVW ... since the Robust TP will take a lot of time, it seems likely that the other routines will come first. The biggest downside to this is that once I go to Powr & Cstm for CVW, "porting" those changes over to be echoed in HAT, etc will be messier than if I did the full set of four CVW versions first. Sigh. Need to cogitate on that.

QUESTION: do you think that the insertion of the fourth "Powr" version is unwise. If you do, please explain why in light of the various considerations above.

Also, I need to decide where the "equity filter toggle" feature fits into the set of four versions. That is, the ability for the routine to override entry/exit signals based on how well it's been performing "recently" with those param settings for that particular symbol. This is a big deal since N code *cannot* do it for *any* of their strat's in OT/VT ... and the OV platform calc's are flawed enough to be unusable for this on a strat-by-strat basis. Thus, a unique TT feature that will very likely improve performance. BUT ... there is a lot of code involved to implement this. My leaning at this point is to include it in all four versions of CVW (and in HAT, etc). But I need to do it quickly and cleanly.

The "OScan" feature, which has return-outputs for the various summed-stat's ... used to select symbols for the FL with "decent price-volume-action personalities" in the recent past ... is also a unique TradeTight stradicator feature ... and particularly applicable for Dynamic Scans as well. This is not as complex to code as the equity filter toggling, so I'll get it in right away.

Ideally, most if not all of the internal coding for Powr (and maybe Cstm) can be done during the initial release work ... this makes the code efficiently portable to other HAT, etc routines ... and, as long as one of the outputs specifies the position-size-pct for each scaling-related order (visible in the FL), it could be traded "manually-mechanically" ... that is, the signals etc would be implemented by manual orders to the broker rather than using a Trade Plan. This would *allow* Powr & Cstm to be released early, but I'm not sure if it's wise to do that, since the Robust TP will be delayed a while. The biggest reason to do the coding now is so that the "portable code" for HAT, etc doesn't need to be added (inefficiently) later as a second phase.

So ... I guess that I'll move forward with trying to quickly implement the full scope of Powr & Cstm features now, unless I get bogged down ... fallback to Easy + Xprt only, in that case.

Whatever route I take, I'm still planning for the "version paradigm" to extend to other routines as well ... maybe some routines will not "need" all four, but the conceptual boundaries will be similar re the names.
Top of the page Bottom of the page
JimDean
Posted 5/3/2019 11:50 AM (#9582 - in reply to #9581)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
... updated at the end, since initial emailed post ...

Relative to the prior "big picture" post, I have one thing I need to sort out, for the Easy &/or Xprt versions: Toe + Confirm entry, versus Full entry.

T+C requires a non-standard but not-hairy TradePlan, which I can create (with some effort) in the fairly near term. If I do that, it also will incorporate SmartSizing (see prior posts). It would not support Adds or Partial Exits.

The *biggest deal* re T+C is that it allows blue/purple-band Alerts to initiate a trade, rather than waiting for bright green/red. The Alert fires the "Toe" entry ... significantly smaller than a "full" entry ... and if no green/red appears before a navy, then trade exits on navy without ever being very big.

Another aspect to T+C is that when the first bar is green/red (ie not an alert), then the entry on that bar is the Toe portion ... and the Confirm shares are only ordered if the following bar is also a bright green/red, within reasonable price-limits. So, T+C can minimize losses from "nuisance" trades where a brief move does not follow through ... or when a big gap occurs, it can delay adding in extra shares, until a pullback occurs. This is with the "Simple TP" ... fancier than a standard one, but way less complex than the Robust version.

IMPORTANT NOTE: if T+C is not active, then my plan is to NOT show Alerts on the plot-band or provide Alert-return signal outputs. That is, Alerts are a useless feature (for mechanical trading) unless the TP can *do* something with them. When T+C is not active, trade-entries follow the classical pattern of "all in" on the first bright green/red bar.

SO ... with that background ... the big question is HOW to TOGGLE the T+C vs All-In feature, in the Easy and Xprt versions. Currently, T+C is toggled on when the Fuzzy Xprt slider is Negative (it's N/A in Easy, and only Positive in Xprt). When the GuruVote slider is negative, it defaults the Fuzzy slider to negative ... but the Guru slider is only Positive in Easy & Xprt. The options are:

1. Don't allow T+C at all in Easy & Xprt ... just use the standard TP fill All-In and no Alerts
2. Standardize T+C for Easy & Xprt ... *always* using Toe for initial entry (no All-In option)
3. Somehow toggle All-In vs T+C for Easy & Xprt - if so, using what input?

QUESTION: do you advise 1, 2, or 3? If 3, then how would it be toggled?

Later note ...

This T+C vs All-In option will be part of the "standard portable paradigm", therefore it must be tied to one of the standardized inputs that will be echoed in other programs. Those are the Vote + Fuzzy + CutGrab set (Guru + Experts), as well as the final two that spec bar-window and output type. Specifically, it *cannot* be toggled by any of the TymFrm Guru+Expert sliders, nor by the CumV method slider, since those are specific to CVW.
Top of the page Bottom of the page
JimDean
Posted 5/3/2019 2:25 PM (#9583 - in reply to #9582)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
... read prior post first ... this suggests a possible solution ... updated since emailed ...

Currently, the BgnVot expert controls the way that Adds work, in addition to the BgnVote (and alert) threshold and ALSO the T+C vs All-In entry share-sizing percentages ... that's a *lot* in one input.
Its positive/negative range (Powr+Cstm only), toggles Adds off/on, but *doesn't* toggle T+C.

Currently, the Fuzz expert slider controls how big the fuzz band is ... essentially shifting the waves to the right and filtering out some nuisance trades, for higher slider-fuzz inputs. Its pos/neg range (in Powr+Cstm) toggles T+C vs All-In ... somewhat arbitrary (not really a "fuzz" kind of thing).

Maybe, if I switch the toggling and control of Adds to the Fuzzy slider, and limit the effect of the BgnVot slider to just control Votes and T+C toggle, that would solve this problem:

========

The TradePlan for positive-slider-only Easy+Xprt versions will support a *choice* of All-In or T+C (Easy has no BgnVot slider, but the +1>+6 GuruVot slider maps directly to it, internally). The TP for this will need fewer conditions and steps than the full-smartsizing approach would require, since there are fewer permutations of percentages.
When I get round to releasing TP's for the Powr+Cstm versions, the additional conditions and steps for the negative-slider "smartsizing" would be included.
For Cstm, the current "VFTAX" override (earlier post) will be simplified to "TFV", such that if T=0, All-In is used ... if the override is negative, then smartsizing would be implemented, as some kind of dynamic variant on the specified V,F,T.

BgnVot mapping from +1 to +6 for Xprt, retains the paired many-to-few vote-spec for 1+2=6V and 3+4=5V and 5+6=4V ... with 1,3,5 using T+C and 2,4,6 using All-In ... but *removing* any relationship to Adds-spec or use. Since the VoteGuru "maps" directly to BgnVot expert, this would mean that both Easy & Xprt would be able to toggle T+C off or on, without needing negative slider inputs or manual typed custom inputs.

The *positive* BgnVot slider range would use *fixed* entry sizes: BgnVot slider = 1,3,5 (req's 6,5,4 NetVotes) = All-In at 100,80,60 pct (ie more shares for greater vote-certainty); BgnVot = slider = 2,4,6 (req's 6,5,4 NetVotes) = Toe+Cnfrm at 40+60, 20+60, 20+40 pct.

For Powr & Cstm, the *negative* BgnVot slider range makes the entry size "smart", related to the magnitude of the actual NetVote of the bar: when the NetVote is >= the 6,5,4V (slider=-2,-4,-6) threshold, then the bar's actual NetVote (7-4) will spec "All-In" cases to use 120,100,80,60 pct.
If the Powr slider specifies T+C (-1,-3,-5), then smartsizing maps a Toe-Alert (or first-bright-Toe) to: 40,20,20 percent based on the *BgnVot* thresh (6,5,4V) ... and the followup Confirm bright (if any) would *increase* the position by 80,60,40,20 pct based on the confirm-bar's *NetVote*=7,6,5,4 ... thus the T+C overall entry size could be anywhere from 40T+80C=120% to 20T+noC=20%, depending on how each trade unfolds.

Note that the number of Steps and Conditions in the "Robust TP" increases *significantly* as the maximum-possible total-Entry (ie sum of Toe+Confirm) gets bigger. Dynamic sizing (above) permits a max of 120% ... if more shares are desired, then the "OT base size" (ie shares equiv to 100%) should be increased. Also note that to keep the number of TP steps manageable, all Entry and Add options are in increments of 20%. Although theoretically the Cstm-override for the BgnVot input (below) could spec a total of >120%, the override-spec and rules keep it within that 120% limit.

The Cstm BgnVot-input override supports pos=fixed and neg=dynamic as well: type in TFV where V=the BgnVot threshold = 7-4V (Toe-Alert is one less=6-3, if T>0); T= fixed ToeIn size 0-3, where T=0 turns off ToeIn, and 1-3=20,40,60% ToeIn. For *positive* TFV overrides, F= maximum Final size 1-6 (*20%) ... if T=0 (=> All-In), then F=1-6 means Entry=20-120% ... if T>0 (=> Toe+Confirm), then Cnfrm= (F-T)*20 ... i.e. anywhere from 100%(if F=6,T=1) to 0%(if F<=T).

For Cstm BgnVot *negative* (dynamic-sizing) TFV overrides, T=1-3 ToeIn's work the same (20-60% fixed-size) as described above. If T=0 (All-in, noToe), or when F=Full(2-6) is > T(1-3) (Confirm after a Toe), then the Confirm (or All-In) size is Dynamic, based on the actual NetVote of the Entry|Confirm bar. However, the *Total* (T+C|All-In) entry must be <= 120% (see italics above). Since the highest Confirm size occurs when the bar's NetVote=7, the F-T size is "mapped" to NetVote=7 ... any fewer NetVotes that are >= BgnVote threshold reduce that F-T confirm-size by 20%/vote. Examples:
When dynamic(negative input) with T=0 (All-in) and F=6, then NetV=7-4 creates All-In sizes= 120, 100, 80, 60; if F=3, then NetV=7-4 All-In sizes= 60, 40, 20, 20 (minimum=20). Note that since T=0, Alerts are *not* active ... this All-In entry occurs on the first bright green/red bar.
When dynamic(negative input) with T>0 (Toe+Confirm): if T=1 & F=6, then ToeIn is always 20%, and Confirm-size for bar-NetV=7-4 =100, 80, 60,40; if T=1 & F=3, then NetV=7-4 Confirm sizes= 20, 0, 0, 0 (=> Confirm starts the official green/red wave logic, but shares remain at the Toe size without increasing); if T=2 & F=5, then ToeIn is always 40%, and NetV=7-4 Confirm sizes = 60, 40, 20, 0. Yes, this is sort of confusing, but it's logical and very flexible ... note that only the *Cstm* user needs to understand it, and Help Popup will verify what's going on for any given override input.

------

That BgnVot change will result in moving the Adds-control options to the Fuzz slider ... this *sort of* makes sense, since larger Fuzz settings *shift the wave left* and makes it "more dangerous" to allow many Adds, since it's more likely some would come too late in the trend.

The new Fuzz slider *positive* range would be the same as it is now, with NO Adds active (which fits Easy+Xprt limitations ... the Simple TP doesn't support Adds or PXits. For Easy, the VoteGuru would drive Fuzzy settings as it does now, with no Adds.

The new Fuzz slider *negative* range (Powr+Cstm using Robust TP) would activate Adds. Currently, BgnVot varies Adds sizing, alternating between 60% and 80%, which was fairly arbitrary and occasioned a lot of back and forth discussion (should it be 40/60 instead?). The new approach would use a fixed 60% for the initial Add when the Fuzz slider is negative ... making the max #Adds using Powr-version alternatives be 3 instead of 4 (reduces by 20% each time) ... I feel better about that anyways. This shortens the Robust-TP needed for Powr significantly (steps and conditions).

The Cstm version for the Fuzz input would "inherit" the "AX" override that used to be part of the BgnVot override. "A" explicitly defines the initial Add% to be 0,20,40,60 or 80%; "X" specifies max# adds either explicitly or indirectly by varying the per-Add reduction (20,40 or 60%). The existing PpHhh override would likely change to HhhPpAX. Note that the Cstm version will therefore require a much longer TP, to support all possible Add permutations.

Possibly ... the Cstm Fuzz spec could "lose" the Hhh periods spec, since it's pretty arbitrary ... it defaults to the CumPds which can be overridden via the MAslope input anyways. If I do that, then it would allow the "F" to be moved from the EndVot Cstm override spec "VPMWF", to join the other Add-related specs in the Fuzz field: PpAXF ... F specifies the size of the PXit required before an Add can be triggered, as a fraction of the Add size. This simplifies the EndV override and groups things more sensibly.

==========

Finally, since this calls for BgnVot to go from +1 to +6 (instead of +5), then in order to make the mapping from the Guru simple, I'll expand the VoteGuru range to +6 also.

That in turn calls for the other Vote experts to expand to +6 (and -6): EndVot +6 will spec 4V, and the #M,#W pattern used for 1-4 will be extended into 5-6, rather than using an intermediate value. Negative EndV still will activate partial-exits based on Warns.

The Fuzz input similarly would expand to +6 (and -6) ... re-map the fuzz percentages to allow more refinement and a slightly-tighter percent-range: 0,10,20,30,40,50 (prev was 0-60%)

==========

OK ... I think that solves it.

Yes ... it's messy to describe but, hey, it was messy before, just in a different way ;~)

Benefits:

1. Main thing: allows Easy+Xprt to offer All-In vs T+C, within the scope of positive-only sliders.

2. Distinction between All-In vs T+C(w/Alerts) is more valuable than Add=60% vs Add=80%.

3. Smartsizing distinction for Entries is a nifty feature, deserving of it's own (neg BgnVot) toggle.

4. Big-Fuzz impact on waves semi-logically calls for fewer Adds, ~moreso than #BgnVotes.

5. Adds are "spec'd" by Fuzz, *after* EndVot => more logical since Adds require PXits.

6. Fuzz-input Cstm-override PpAXF groups all Add-related stuff into one entry.

7. I haven't yet implemented the earlier approach, so changing this won't waste time.


QUESTION: do you follow the logic? Is this better or worse?
Top of the page Bottom of the page
JimDean
Posted 5/3/2019 5:37 PM (#9584 - in reply to #9583)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
... crib-sheet updated and moved to 5/8/19 post ~12:50 PM ...

The attached snap shows the updated parameter pane:

Yellow highlight shows all places that param/label names changed.
Blue highlight shows param's that use -6 to +6 ranges (0 to +6 for Easy|Xprt)
Green highlight shows param's that use -5 to +5 ranges (0 to +5 for Easy|Xprt)

Notes:

1. Biggest change is that I moved CutGrab out of the VoteGuru section (per prior posts). I changed the final section label accordingly. Note that this entire section is part of the portable paradigm.

2. BgnVotNetNatcMny2Fw ... "Natc" is a reminder that besides setting the begin-vote threshold, this also spec's eNtry type as either "All" or "ToeCnfrm". See description in prior post ... Neg inputs activate smartsizing rules.

3. EndVotOpXmwFw2Mny ... "Xmw" is a reminder that besides setting the end-vote threshold, this also counts M's & W's to create eXits. PXits only active with neg inputs

4. FuzBandAddCutSm2Lrg ... since "Sm2Lrg" applies to how the slider affects the Fuzzy Band width, I described how the slider affects Adds by "cutting" their use a small to large amount ... that is, a "large" slider input spec's a wide fuzzy band and a limited number of small Adds (ie Adds are "cut" a lot). This is not ideal but it's the best I could come up with. Adds only active with neg inputs.

Comments?

(Params renamed & rearranged.png)



Attachments
Attachments Params renamed & rearranged.png (193KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/4/2019 11:17 AM (#9587 - in reply to #9584)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
I've meaningfully updated the prior post with the "crib sheet" definitions for the inputs, adding the Cstm section (*lots* of detail), expanding info for Cuts & Grabs, and extending def's for BgnV, EndV, Fuzz inputs to represent the full -6 > +6 range.

Also, I updated the prior post (4/4/2019 3:23 PM #9558) that explains how the Cuts & Grabs lines are spec'd and managed (blue). Crib sheet summarizes that, but it's an important post ... as are the two posts that immediately follow it.

Plot Options: 1=Band, 2=Band+3Strips, 3=Equity, 4=Band+2Hists, 5=MA+Hist Detail ... Easy=1-3, Xprt=1-4, Powr&Cstm=1-5. Pricepane plots: dots on all but 1=Band-Only; C&G lines always if C&G active (input=0 turns them off). So, plot=1 is handy for "filter-only" cases.

Add rule was modified in (4/3/2019 10:28 AM #9552) post - see RED paragraph: Adds (allowed if Fuz slider negative) use next-bar SM orders in RobustTP to assure decent fills, fired from prior-bar signal, as long its C (for Longs) was less than lowest of: highC since bgnTrd, or (C1-PartGrabLine)/2 ... that is, only if the signal-bar C was not exceptionally high. Adds will use next-bar StopMkt-Orders with level set to the Close of the prior bar that signaled the Add ... which usually will prevent a poor price-fill, but definitely prevents a partial-fill (since SM becomes Mkt when triggered).

Mentioned earlier but worthy of repeat: now that the BgnV 1-6 slider alternates between All-In vs Toe+Confirm pairs, note that Alert (blue/purple Band) bars will ONLY be shown (or return-signalled) when that slider spec's Toe+Confirm.

After some further eyeball testing, I tweaked the sequence of MAcalcTypes a bit:
pos1-5= WH, WH&E, WH&EH, EH&W, EH; neg1-5= Wma, W&E, Ema, W&E&S, W&S
... after trying some other combos -6 to +6, it became clear that the extra two were of no use.

=======

Re Equity-Plot option#3 (all versions):

Previously described in posts on 3/28/2019 10:32 AM #9490 and 4/1/2019 4:50 PM #9544 ... here is updated recap ...

Always shown, even if Equity-Vote-Filtering is turned off:

Wide-Band green-to-red ATR-P/L increments = progress of each trade, incl any Add/PX impacts
... Band will be at Zero-line: y-axis will be forced to always extend down (or up) to zero
... Thin vertical lime/forestgrn/dkorng/magenta lines identify Entry/Add/Pxit/FullX bars
Cumulative-Equity line (unbounded y-axis, based on normalized-Equity)
... Normalized/Share: ((XitC$-NtrC$)/NtrC$) / (NtrWTR$/NtrC$) = (XitC$-NtrC$) / NtrWTR$
... Tracking = running sum w/variable shares: %NomShrs * (Cls$-PrvCls$) / BarWTR$
... ... any time Shrs Add|Xit, adjust Eqty sum: +|- Delta%NomShrs * Cls$ / BarWTR$

ALSO shown, when Equity-Voted Signal-toggle mode is active:

When this is active, then prev-described "voting" of slope&stack from Equity-curve MA's will either allow or block "unfiltered" Trades from appearing on price-pane or as return-signals. The equity calc's will continue in the background for *all* trades for that symbol, but the trades will not be "triggered" (via return), nor will they show up on the PricePane, *unless* the filter-voting indicates that the strat+sym performance has recently been *improving* in profitability.

The "fat" trade-progress Zero-Band and Equity-curves will appear as described above, but:
... Only the "triggered" trades will have thin vertical lines (echoed on PricePane by dots+bands)
... Any trades (full or partial) *excluded* by the filter have a thin white line thru the Zero-Band
Two additional Equity-MA lines will appear (based on all "background" trades)
... Equity Wma calcs *ignore* non-trade gaps (via pointer-chain)
... Fast=Wma(X), Slow=Wma(Y), where X=2,3,4 & Y=4,5,6 as func(SlowCumMA pds)
... Eqty & MA slope-colors: Eqty= Lrs(Y+2); FastMA Wma(Lrs(2),2); SlowMA Lrs(3)
... ... implies that max of current + 5 prev E's must be pointer-accessible for Wma & Lrs calcs
"Triggered-Trade" net-Equity Histogram:
... Histo colors: green/red= rising/falling NetE; blue= flat NetE (typically means not in trade)
Background full-height wallpaper (histo):
... Colors re trades: darkgreen=allowed, darkred=blocked, darkgray= late-start/early-end
... mid-trade start/end based on the "C" control override parameter setting
Top of the page Bottom of the page
JimDean
Posted 5/6/2019 5:30 PM (#9588 - in reply to #9584)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
Lots of progress over the last couple of days ...

First: significant changes (refinements) to the "crib sheet" a couple of posts ago (5/3/2019 5:37 PM #9584) ... not just syntax ... the actual rules have been enhanced as well as the descriptions.

I've done the busywork to get all the negative-range Powr variants and all the manual-typed Cstm-overrides properly "parsed" from the input, with appropriate checking for validity, along with a bunch of pop-up error messages that inform a user if they've entered a value that is invalid for a given Version ... negatives only for Power, typed overrides only for Custom, etc.

I found a BUG (!) that apparently crept in a couple months ago, regarding how the Stacking votes were being handled (your beta VOLeval was correct). It was a typo that involved a grand total of six characters ... but once fixed, it made a *major* change to the output (for the better) ... in general, both entries and exits skootched left a bit. Hooray!

Once I got that fixed, I double-checked the CumMethods, and it became VERY clear that the "raw volume" (CumMeth input +6) was pretty much useless. Since CumMeth -6 was also pretty silly (average of 8 other methods), I cut that slider down to -5 > +5.

I fiddled with expanding the range of the TymFrm Guru & its Experts to -6 to +6, but decided to keep them as is. I feel very confident about those sliders now.

The Warmup Buffer took considerable effort, but it's working well now, with a "minimal" (typically 40) number of extra pre-output bars ... the white line shows up rarely, and even then, only for a few bars on the far left of the chart. When used with the Both / LongOnly / ShortOnly distinctions (BarWndo slider), I allow "both" during the buffer to get earliest possible stability, then switch to LO|SO if requested by BarWndo. Nifty.

Full day spent on refining the rules related to BgnVot, EndVot, and FuzBnd ... with their associated , Dynamic-Entry-Sizing, Partial-Exit and Add-On negative-slider toggles. And their extensive+flexible manual overrides. The parsing process forced me to think the entire paradigm through very thoroughly, yet again. Several tweaks, all for the good. Shifting the Add-spec over to the Fuzz slider
turned out very nicely ... the Bgn slider now spec's All-In vs Toe+Confirm, and Dynamic Sizing.

I reviewed the conversions from Med-to-Warn and Warn-to-FullX very carefully, and found a case I'd overlooked before: an "Alert reversal". It had been possible for a blue/purple Alert to be active, and immediately switch to the opposite Alert color, or to the opposite Wave color. If Toe+Confirm was active, the TP could not handle the "pure reversal" ... so the code now forces a black bar between the two, allowing one trade to exit and the next to start.


The only input that I've just got rudimentary support for so far is the new CutGrab slider and its manual overrides. I've fully defined the override spec (which is the heart of the CG algorithm). I plan to finish that tomorrow AND hopefully get the code written to draw the four lines on the pricepane. Fingers crossed!

REQUEST: please carefully review the updated "crib sheet" and tell me what is hardest to understand.

Top of the page Bottom of the page
JimDean
Posted 5/7/2019 7:24 PM (#9589 - in reply to #9588)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
... I got a bit sidetracked today, but in a useful way. I had some thoughts last night about improving the error-checking, to make it more detailed and portable. In process of doing that, I realized that I should lock down how the optional typed-in "filter" spec will work ...

All Stradicators will have at least one "Guru" (the VoteGuru is part of the standard paradigm). Guru's will always by nature be simple inputs, with sliders no wider than -9 to +9 (here, they have limits of 5 and 6). So, I'm using Guru param's as places where the user can optionally type in a 7-digit number, to define how an external filter's analysis should be folded in to the Stradicator logic. Think of this as specifying a filter in the OT Strategy Filter block ... Stradicators provide that same flexibility ... and can therefore include the impacts of the external filter in it's various Equity-stat's and Equity-Vote toggling. Vereee cool, since this means I can sell separate licensed "general-use" filters (ie that work on a standalone basis), which the Stradicator user can "call" (via the typed Guru input). This means I will *not* have to add that filter-code to each Strad that might use it ... and it means in theory that the number of filters are unlimited.

It's tricky to do this and keep the execution time efficient, due to how the OLang Parser handles external function calls. I've documented the "rules" about that elsewhere ... the comments below refer to them ... but suffice to say that this structure absolutely minimizes any "time waste" for unused-but-available filters, to effectively nothing.

Most likely, I will initially offer two filters (ConZone and BigJump) that users can choose to buy. They can be used separately (they plot meaningfully and return helpful values) ... or they can be called by CVW or any future TT Stradicator. If they are called by a Strad, they *cannot plot* any output (that's an OLang limitation) ... but their net effects will be known by the Strad and appropriately utilized (typically, to block or delay an Entry).

If the user spec's one of them in the Strad's Guru-input, but also wants to *see* what that Filter is *doing* with the selected param's, all the user needs to do is to separately plot that Filter as an indicator ... its effects will be seen on the chart (which presumably also has the Strad plotted). If the user has specified more than just one Filter for the Strad, then they can plot whichever one(s) they wish on the chart. The plotted version is disconnected from the operation of the Strad ... and it's up to the user to make sure the same param's are spec'd for the Strad's filter-call (via Guru input), as are used in the separate plotted filter.

The comments in the snapshot below (from the 5P routine) explain things pretty well. It's the first case I've known that uses a seven-level nesting of OLang Indicator calls (the 0-param filters are the seventh, and the initial first-level call is made to TTndGetFltr5P from the Stradicator) I'll distribute these six "GetFltr" routines as OLang source-code Indicators which the user can tailor if they want. Per the instructions, they would manually revise one or more of the case 1-9 "Return = 0" statements with a call to a TradeTight DLL, or to one of their own custom OLang routines (which in turn could be based on a Nirvana indicator, I suppose).

I've attached a Zip file that has all 6 nested routines, ready to go :~) Of course, once I get ConZone and BigJump (or other TT filters) ready, then I'll specify them as 5P case 1 & 2, etc.


(Comments Snapshot from 5P.png)



Attachments
Attachments Comments Snapshot from 5P.png (72KB - 0 downloads)
Attachments GetFlltr Sextet.zip (8KB - 1 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/7/2019 8:06 PM (#9590 - in reply to #9589)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
I think that last night I came up with a good approach for the Master slider, which if I don't use any pre-testing, will provide a handy one-slider "journey" through the full spectrum of Easy-version input-permutations ... at *most*, there are 5 CumMeth * 5 TimeGuru * 6 VoteGuru * 6 CutGrab = 900 permutations. Since these inputs are in ALL the versions, the same (hardcoded) Master arrangement could be used for all of them.

If it turns out from testing that a large portion of those 900 have relatively little effective difference, then *hopefully* I'll shrink the Master-spectrum (in an orderly way). That is, maybe I'd leave out the Time=2 & 5, &/or Vote=1 & 6, &/or CutGrab 1 & 6 (refer to crib-sheet comments above, to see why those would be the ones I'd initially target). Eliminating all of those would reduce the canned Master-set to 5 * 3 * 4 * 4 = 240 cases (much more manageable).

Later on, if time permits and user-interest warrants, I could do extensive studies starting from those 900, then applying Expert-input fine-tuning, on literally hundreds of thousands of other permutations, to come up with some "recommended" patterns for various scenarios. Those would be sold to users optionally via a licensed Text file ... they'd be accessed via a typed negative Master-param input. I described in detail how those tests would be automated, in a post some time back. Selah.

The *arrangement* of the canned Master-slider options likely would be "tiered", with the "default" being in the center: Master# = 120 would represent CumMeth=3 (average), TimeGuru=3, VoteGuru=3, and CutGap=3 (ie if all Guru and Expert inputs are zero).

With that as a starting point, I will likely expand outwards to the right (ie Master=121+) by increasing Time, and to the left by decreasing Time (at the top level of permutation-tiers), using Time inputs of of 1,3,5 (or maybe 2,3,4 if 1 & 5 are too extreme).

Within each Time-Tier, I'd likely vary the VoteGuru next (values of 2,3,4,5). Within each Vote-Tier, I'd vary the CutGrab values (2,3,4,5). And within each CutGrab-Tier, I'd vary the CumMeth values (1,2,3,4,5).

Another approach might be to use the CumMeth's as the Top tier ... hard to say ... when I asked about this a long while back in a post about more SBAS testing, I seem to recall that Ken(?) thought it would be better on the bottom.

If I want to cut the Master-Set permutations further, from 240 to 192, then I'd reduce the CutGrab tests to 2,3,4 ... note (from the crib sheet) that those inputs are "in pairs", so 1~2, 2~3, 3~4 ... where 1,3,5 "time-tighten" quicker than 2,4,6. If I cut out anything else, it would mean either that the Master set didn't contain the "basic default pattern" at all ... or it would mean that some key "logical" distinction would have an unbalanced representation (such as All-In vs Toe+Confirm, or Fosback vs Granville).

Final option ... I could vary CutGrab WITH VoteGuru ... that is, when VoteGuru=3, CutGrab also would =3. I'd model all six in that case ... all logical distinctions within a given param would be represented, but NOT all the permutations. That way, the MasterSet would have either 5 CumMeth * 5 TimeGuru * 6 VoteGuru+CutGrab = 150 permutations, our would have 5 CumMeth * 3 TimeGuru * 6 VoteGuru+CutGrab = 75 permutations.

QUESTION (please answer asap): do you think I should set up Master for 900, 240, 192, 150, or 75 options, per the description above?

Note: I don't have time to do a bunch of testing first. So, please thoughtfully study the crib sheet and logic it out. Please spend at least 20 min thinking about it before responding. Thanks!
Top of the page Bottom of the page
JimDean
Posted 5/8/2019 10:16 AM (#9591 - in reply to #9590)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
... Salim preferred the 240 or 75 options, re the question in the prior post ...

While creating the Master-Set lookup table, I realized that my earlier decision to expand the BgnVot from +1 > +5 to +1 > +6 so that "Toe+Cnfrm" and "All-In" each had three options (which domino'd to increasing EndVot to +1 > +6 and increasing FuzAdds to +1 > +6) has ended up creating a "conceptual problem" (at least from my pov).

The concept that I typically use is to set up the sliders so that the "center" value (ie 3 in range of 1-5) represents the "recommended generic default". With the TymFrm group and the CumMeth slider all going from 1 > 5, that works fine. But with the VoteSpec group and the CutGrab slider going from 1-6, it becomes "awkward" since there is no clear "center".

This really showed up as an "issue" when I used Excel to map out the Master-set variants. No matter which of the options (900, 240, 192, or 75) that I used, the "center" of the Master range was NOT the "recommended generic default" setting of 3,3,3,3.

So ... I went back to the original post (5/3/2019 2:25 PM #9583) where I discussed the change from BgnVot 1-5 to BgnVot 1-6 ... as mentioned above, the "logical trigger" for that change was the presumption that, by using the slider-range to not only choose BgnVot thresholds but also to toggle between Toe+Cnfrm & All-In Entries, that I should EQUALLY represent both of those Entry methods ... thus three pairs of two.

From that decision, all the other changes flowed (see prior post for details). HOWEVER, upon rethinking it today, I am coming to the opinion that there is *no need* to equally emphasize the two Entry methods in the slider-range ... especially since I need to pick ONE of them as the "recommended generic default". And, if I'm using one as the "recommended" case, then it follows that if either of the two methods should have a bit of "extra" emphasis in the slider range, it should be that default.

So ... my own (conservative) bias, especially since it can be handled by a relatively simple initial-release TP, is that the Toe+Cnfrm approach is better, for two reasons:
1. since it activates "Alerts", that means a decent # of trades actually start a bit earlier
2. it emphasizes the "money management" bias that I want TradeTight to champion

Based on that, and since I want the "center" value = 3 to be the "recommended" one, and since I want the Master slider's center value to be the 3,3,3,3 case ... I'm going to change the BgnVot, EndVot, FuzAdd, and CutGrab sliders "back" to a 1-5 range. Specifically:
1. BgnVot 6 gone ... BgnVot 1-5 remain as-is w/ 3:2 bias for Toe+Cnfrm, and 2:1 bias for 6,5V vs 4V
2. EndVot 6 gone ... EndVot 1-5 remain as-is (EndVot 5 uses 4V,4m,4w,30% ... reasonable endpoint)
3. FuzAdd revised "back" to 1-5 ... FuzPct=0,15,30,45,60 (was 0-50); Initial-Add%=80,60,60,40,40 (removed final 20); PX% req B4 next Add #8ths = 2,3,4,5,6 (removed final 7).

The *overrides* for these three *remain the same* re rules and range, so in the big picture (Cstm version), there is no loss in flexibility.

Finally, the new CutGrab slider also needs the 1-5 range (for similar center=3 reasons). It has not yet been coded (so it's "easy" to change) ... its **current** 1-6 definition is:
=== CutGrabGapSzSm2Lrg- positive 0-6 Full CutGrab incrsg InitGap & decrsg Tytn (0=off)
... ATRgaps: 1&2= 4xFG,2xPG,1.6xPC; 3&4= 6xFG,3xPG,2.4xPC; 5&6= 8xFG,4xPG,3.2xPC
... PC,PG,FG FastTytn%InitGap/bar: 1,3,5=-24%; 2,4,6=-20%; Med=half if abs(G-G1)<ATR/2
... FC BrokerInitSMgap 1-6= 2.4x to 6.4x; @addTytns -0.3 to -0.8 (no FC Tytn/bar)

Again, this slider offered "pairs" where 1,3,5 tightened faster than 2,4,6 ... and each pair had a "thin and wide" gap-option which in retrospect was sort of a knee-jerk reaction to how BgnVot and EndVot were set up. Since the CutGrab "Bands" slider is really independent of the rest of the program's logic, there's no need for this. So, I'll modify the CutGrab definition to be "smooth" from 1-5, which remains in line with the spreadsheet-study that I did:
=== CutGrabGapSzSm2Lrg- positive 0-5 Full CutGrab incrsg InitGap & decrsg Tytn (0=off)
... ATRgaps 1-5: FG=4x,5x,6x,7x,8x; PG=2x,2.5x,3x,3.5x,4x; PC=1.6x,2x,2.4x,2.8x,3.2x
... PC,PG,FG Fast Tytn%InitGap/bar: -24%,-23%,-22%,-21%,-20%; Med=half if abs(G-G1)<ATR/2
... FC BrokerInitSMgap 1-5= 3.2x to 6.4x; @addTytns -0.4 to -0.8 (no FC Tytn/bar broker orders)

========= New Master-param Name: MasterTymVotGapMeth ============

The new Master param-name reminds the user of the "sort tiers" that are the basis of the sequence.
The Master slider center will have "center=3" values that are the recommended ones. The updated Master-slider layout options are:

Full: 5 Time * 5 Vote * 5 Band * 5 Method = 625 in all, with center=313
... a bit large, but no corners cut, so handy for optimization-studies

SML: 1,3,5 Time * 1,3,5 Vote * 1,3,5 Band * 5 Method = 135 in all, with center=68
... nice intermediate number, but 1,3,5 Vote *only* uses T+C entry (not sure if that's OK or not)

Balanced: 1,3,5 Time * 5 Vote * 1,3,5 Band * 5 Method = 225 in all, with center=113
... this includes the "All-In"; since Time & Band use "smooth" logic, 2 & 4 skip is OK

ALSO, if I use the balanced approach, it's very easy for me to expand the Master-set slider to negative values (-1 to -225) for the Powr & Cstm versions (which model Adds & PXits and PCuts+BGrabs) ... having a Master set for those variants offers optimization-run benefits.

Comments? Do you concur with the decisions to return to 1-5 range for Vote and Band sliders, and to use the 225-option "Balanced" Master?

... attached spreadsheet maps out the various Master sets that I considered ...

Attachments
Attachments CVW Master Tables.xlsx (255KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/8/2019 9:00 PM (#9592 - in reply to #9591)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
Here is an updated version of the crib-sheet input-summaries, by version. Removed from earlier post since things changed a lot here. This includes new lines for the Master input, as well as updates for everything that changed from 1>6 to 1>5 (see prior post). I'm attaching an updated snap of the param pane also.

========= crib sheets for XPRT positive +POWR negative +CSTM overrides ===========

*** LIST OF XPRT POSITIVE-SLIDER OPTIONS *** (save)

MasterTymVotGapMeth- pos 1-225= 4-tiered-seq-map: TymFrm > VotSpec > CGgap > CumMeth
... def=113= 3,3,3,3; Outer>Tym=1,3,5; Vot=1,2,3,4,5; Gap=1,3,5; Inner>Meth=1,2,3,4,5
CumMethBasic2Refined- GranOBV, FsbkVPT, 3=avg(4), ChaikAD, BostNtraNtnsNdx

=== GURU_TymFrmFst2Slo- positive maps directly to positive of three Experts
MAvgSpeedPdsSm2Lrg- positive 1-5 uses identical FMS pds for Ema=>Sma+Wma & EmH=>WmH
MAvgTypSnug2Gradual- positive 1-5 = WmH, WmH&EmH, WmH&E, EmH, EmH&W calc methods
MASlopePdsLess2More- positive 1-5 = 2L, 2WL, 3L, 3WL, 4L (WL=wma(lrs))

=== GURU_VotSpecTyt2Lax- positive maps to experts: w/NO SmartSize, Adds, or PXits
BgnVotNetNatcMny2Fw- positive 1-5 NetVotes+Ntry: 6t+c, 6full, 5t+c, 5full, 4t+c
EndVotOpXmwFw2Mny- pos 1-5 OpposVotes+MWcnt: 2V3m2w, 2V4m2w, 3V3m3w, 3V4m3w, 4V4m4w
FuzBandAddCutSm2Lrg- positive 1-5 FuzzBand for neg/~0/pos evals: off,15,30,45,60%

=== CutGrabGapSzSm2Lrg- positive 0-5 Full CutGrab incrsg InitGap & decrsg Tytn (0=off)
... ATRgaps 1-5: FG=4x,5x,6x,7x,8x; PG=2x,2.5x,3x,3.5x,4x; PC=1.6x,2x,2.4x,2.8x,3.2x
... PC,PG,FG FastTytn%InitGap/bar: -24,-23,-22,-21,-20%; Med=half, if abs(G-G1)<ATR/2
... FC BrokerInitSMgap 1-5= 3.2x to 6.4x; @addTytns -0.4 to -0.8 (no FC Tytn/bar)
BarWndoTrdDirL3cS6c- Plot=Wdth(>Hre), Rtn=Bb4Hre(9wide); Longs@300+, Shorts@600+
OutputReturnHelpPlot- positive 1-5= Plot Band, B+3Strp, Eqty, B+2Hist, Detail (0=Help)


*** LIST OF POWR NEGATIVE-SLIDER OPTIONS *** (save)

MasterTymVotGapMeth- negative 1-225= same sequence, but assigns negative values
CumMethBasic2Refined- negative uses Guts & TrueRange; -3=avg(4)

=== GURU_TymFrmFst2Slo- negative maps directly to negative of three Experts
MAvgSpeedPdsSm2Lrg- negative 1-5 "visually similar" FMS pds for S,W,E and WmH,EmH
MAvgTypSnug2Gradual- negative 1-5 = Wma, W&E, Ema, W&E&S, W&S calc methods
MASlopePdsLess2More- negative 1-5 = slower slopes 4WL,5L,5WL,6L,6WL (WL=wma(lrs))

=== GURU_VotSpecTyt2Lax- negative allows Adds and PX,PG,PC (ie Robust TP)
BgnVotNetNatcMny2Fw- negative 1-5 same ReqV+Ntry, but uses MOC instead of MOO orders
... undocumented Powr MOC override -MmB: B= neg-slider val; Mm=#minB4barC (see Cstm)
EndVotOpXmwFw2Mny- neg 1-5 allow logic-PExits (not PC,PG) w/Sz: 50%,40%,40%,30%,30%
FuzBandAddCutSm2Lrg- negative 1-5 same Fuzz% plus activates reducing-Adds option
... neg1-5: InitAdd%=80,60,60,40,40 (@nxtAdd-20%); PX%ofNxtAdd reqB4add 10,30,50,70,90

=== CutGrabGapSzSm2Lrg- negative 1-5 same 2 Full C+G, plus Partial Cuts & Grabs lines
... PC&PG def=PXsize; PC=dkGray WarnPX, PG=ltGrayPX(notWarn,noAdd); FC&FG=blackFX
BarWndoTrdDirL3cS6c- neg toggles on Equity-Vote Filter (req's license) ... all vers
OutputReturnHelpPlot- neg specifies Return type (pos=Plot,0=Help) ... all versions


*** LIST OF CSTM MANUAL-INPUT OVERRIDES *** (save)

MasterTymVotGapMeth- typed #### reads 10-param tuned sets from (licensed) text file
CumMethBasic2Refined- CCCM: M=CumMethInp, CCC= CC.C CapVmult (100+ => Capping off)

=== GURU_TymFrmFst2Slo- Fltr1=PPPPPFG: G=GuruInp; F=FltrID, PPPPP=parms (Shell Indic)
MAvgSpeedPdsSm2Lrg- FfMmSs: Ff,Mm,Ss = fast,med,slow MApds (neg=same)
MAvgTypSnug2Gradual- GCT: T=MAtypInp; G=#SigFig digits; C<>0 => Hull StkV uses Wma+Ema
MASlopePdsLess2More- WwwL: L=SlopePdsInp; Www= CumWndoPds (neg=slower-slope-set)

=== GURU_VotSpecTyt2Lax- Fltr2=PPPPPFG: G=GuruInp; F=FltrID, PPPPP=parms (Shell Indic)
BgnVotNetNatcMny2Fw- TFVMm: BgnV=7-4; FullNtr=0-6*20%; ToeNtr=0-3*20%; Mm=#minB4barC:
... ignore for MOO(pos); negMOC Daily def=15m; negIntraday def=BarLen/10, >=1min
EndVotOpXmwFw2Mny- PMWV: EndV=2-5; Med2Wrn#, Wrn2FX#; PXsz=0-5*10% (neg=usePXits)
FuzBandAddCutSm2Lrg- QMAPBb: Bb=0-99%, P=1-9*20pd; Add=0-4*20%, M=CtlMth, Q=1-9=QualPX
... M= 0-4: 0-3= decrem@Add-20%, 1-3= Lmt#ofAdds; 4= decrem@Add-40%
... Q= Frac(NxtAdd) reqPXb4Add 0-9= 1/12, 1/6, 1/4, 1/3, 5/12, 1/2, 5/8, 3/4, 7/8, 1/1

=== CutGrabGapSzSm2Lrg- GRFCUBT: FstTytn 1-9= 18>26%InitGap/bar; Grab&Cut XitSiz 1-6= 0-50%;
... Part+Full ATRgaps 0-9 (0=off): Grabs R+F=1-5 (F adds to R); Cuts Part U=.8-4,
... B=BrkrFXinitSMgap 1-5= 3.2,4.0,4.8,5.6,6.4 (@addTytns -0.4,-0.5,-0.6,-0.7,-0.8)
BarWndoTrdDirL3cS6c- BbbTWww: Www=WndoWdth, Bbb=#Bb4Hre; T=0-5=B/L/S & FWeStatUse
OutputReturnHelpPlot- EqtyVote IRCVS##: ##=PltRtn; S~TimeG, V~VoteG, C=Cntl
... I&R=SmartSize Invst&Risk Ntry +/-10% from ATR/5% study (RobustTP only)


(CVWeval V2 Parameters.png)



Attachments
Attachments CVWeval V2 Parameters.png (179KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/9/2019 2:16 PM (#9593 - in reply to #9592)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
Two new things ... one simple, one pretty cool ...

When Toe+Confirm is on, current definition says that the first bright green/red after a navy, which starts a wave, will be the Toe size ... and if another bright immediately follows that, it will be the Confirm (otherwise size remains Toe). I'm changing the Band color to represent that:
If Toe is on, the first bright grn/red bar of a new Wave will be lightblue/violet ... ie a brighter version of the related "Alert-Toe" color. Also, the Return signal will identify that bar as a Toe.

=========

I've been studying these CumV charts and formulae soooo long now, that I've realized I think I can create my own "Dean" formula for CumV that will blend the best features of all the others, and incorporate a bit of extra smarts along the way. Here are the considerations for how I'll create a hybrid price- direction & magnitude multiplier:

1. OBV and VPT are "purely" inter-bar. AD & III are "purely" intra-bar. The Dean variant should incorporate *both* inter (current vs previous) and intra (OHLC of current) smarts.

2. I've long believed, and have proven, that the Guts price is more representative of the bar as a whole than the Close is ... the core of that thinking is that what happens during the Body of the bar is more significant than what happens in the tails. The Dean variant should incorporate a bias from what the Body is doing (open to close), moreso than what the H & L or gap are contributing.

3. Aside from the time of the Close, on most days, the second most liquid time is at the Open, as prices adjust for overnight changes. Therefore, the opening gap (prior-close to current open) magnitude and direction should influence the CumV, not just the price action on the current day.

Those three considerations were the basis for my initial formula, which weighted the Body effect twice as much as the opening Gap effect. The resulting formula is fairly simple:

denominator = H-L + abs(C-O) + abs(O-C1) ... "doubles up" the body portion of the H-L range, and adds the absolute value of the overnight gap
... previously I'd used TruRng+abs(C-O) ... this new version is sometimes a bit smaller, when O is not at the extreme C1-side of the current bar's range. All the positive-slider options are nominally based on H-L rather than True Range, so I tweaked this to make that clearer.

numerator = Body*2 + opening-gap ... idea is that most of the action occurs during the day, within the body prices, but a meaningful amount also occurs at the open. The numerator is directional (denominator uses abs to remove directionality).
... so, numerator = (C-O)*2 + (O-C1)

Combined
( (C-O)*2 + (O-C1) ) / ( H-L + abs(C-O) + abs(O-C1) )
... which simplifies to: ( 2*C -O -C1 ) / ( H-L + abs(C-O) + abs(O-C1) )

I call this the "Dean BG" (BodyGap) method.

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

However, as I studied the charts and effects more carefully during reversals, paying special attention to Doji's, I saw a third factor that seemed worthy of considering ...

4. The relative length of the tails (wick and shadow) have a significantly useful predictive impact ... good examples are Gravestone (long wick) & Dragonfly (long shadow) Doji's. If price "tries" to move a long ways in one direction within a bar, but *fails and returns*, that's an indication of weakening or reversal in the attempted direction. Probably (imho) the volume during that process is greater when the price *returns* from the failed excursion, than it was when it made the initial attempt. Therefore, the Dean variant should take that effect into account.

5. The relative weighting of these factors in the numerator should be: most = Body, moderate = opening gap, minor = tail excursions. The denominator should be representatively weighted to normalize the combo of those three, but be unsigned.

Folding those ideas in with the ones used in the BG equation above ... slightly different denominator (since the negative slider options *do* use True Range), plus an extra half-weighted term for numerator:

denominator = TrueRange + H-L ... this "doubles up" the body-portion of the TrueRange, which includes the overnight gap (if any) ... it also "doubles up" the tails portion of TR, to balance out the absolute value of the Dragonfly|Gravestone "RevTails" component.
... TrueRange = max(H,C1) - min(L,C1):

numerator = Body*2 + OpeningGap*1 + RevTails/2 ... double-weighted Body, std-weight Gap, and half-weighted "doji-tail" effect, to represent the theoretical volume associated with each:
... RevTails = ( max(O,C) - H ) + ( L - min(O,C) ) ... which is equivalent to: L - H + abs(C-O)
... so, numerator = (C-O)*2 + (O-C1) + RevTails/2 ...
... ... (expanded) = ( 2*C -O -C1 ) + ( max(O,C) - H ) + ( L - min(O,C) ) /2
... ... and since max(O,C) - min(O,C) is exactly the same as abs(C-O), then ...
... numerator = ( 2*C -O -C1 ) + ( L - H + abs(C-O) ) /2

Combining numerator and denominator:
... ( 2*C -O -C1 + ( L-H-abs(C-O) )/2 ) / ( TrueRange + H-L )

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

I've tested these out on a bunch of charts and they both seem to have noticeable advantages over any single one of the other four formulae. Between the two, the BG had a bit less entry/exit lag, and the TrueRange version of it had a bit less nuisance chop.

So, I created a THIRD version, which simply averaged the two (using the TrueRange denominator which is very similar to the BG denominator, as noted above) ...

( ( 2*C -O -C1 + 2*C -O -C1 + ( L-H-abs(C-O) )/2 ) / 2 / ( TrueRange + H-L) )
... combining terms ... ( 4*C -2*O -2*C1 +(L-H-abs(C-O))/2 ) / 2 / ( TrueRange + H-L)
... "simplified": ( 2*C -O -C1 + (L-H-abs(C-O))/4 ) / ( TrueRange + H-L )

Admittedly this formula looks like gobbledegook ... but hopefully the step by step rationale is clear.

I'll call the combined version the "Dean BGT" (Body, Gap & Tails) method ;~)

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

I'm still pondering which of these to use in CVW, and where.

Comments? Is my logic sensible? Is my math correct? What do you think the slider should map to?
Top of the page Bottom of the page
JimDean
Posted 5/10/2019 10:50 AM (#9600 - in reply to #9593)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
... reposting ... I modified the order (explained below) and tweaked the formulae (prior post) and names ...

I developed two alternate hybrid CumV Method formulae (described in detail in earlier post), which "bridge the gap" between the inter-day OBV & VPT versus the intra-day AcDst & III. I previously posted a bunch of charts that used ONE of those formulae, and Salim's review indicated that it was worthwhile and should be utilized.

I did further more in-depth review on my own, comparing the three versions of the formula described in the earlier post ... and I concluded that the one which Salim reviewed ... now named BGT (Body,Gap&Tail) was a keeper ... but also another formula ... the simplest one that I call "Body & Gap" ... is a tad bit better for some cases (less lag, tho sometimes it breaks a long run in the middle, that the other formula didn't).

So, I'm implementing the simple "Dean Body Gap" (BG) formula in-between the positive-slider interday VPT and intraday AcDst. And I'm implementing the other more-complex BGT formula between the negative-slider inter and intra-day "Guts|TruR" versions of VPT and AcDst.

Finally ... since there's agreement that the "simple average" of all the formulae variants is also useful, I'm keeping that as well (expanded to 5 methods from original 4) ... there is one average for the pos 1>5 variants and another for the neg 1-5 variants.

With this addition, the CumV Method slider now goes from -6 to +6. I've been going back and forth about where to put the Avg(5) in the sequence ... when I first posted this, I put it at the end (#6), making Dean #3 to be the default.

Rethinking it this morning, I'm gravitating more to making the Avg(5) to be the default, thus assigning it to #3.

So, the question that remains is:

Should the new Dean BG (pos) and Dean BGT (neg) be #4 or #6?
... logically:
on the one hand, the Dean formulae bridge between inter and intra-day, so should be #4
on the other hand, the Dean formulae are more "complex" than the others, so should be #6

I suppose that since the Avg is *FAR* more complex a formula than any of its individual components, and since it's in the middle of the pack, that "complexity" should not be a reason for placement of the Dean formula. So, I'll insert it as #4, between inter (+Avg) and intra-day variants.

I have updated the Master Slider to include the CumMeth #6 in the permutations ... now 270 instead of 225. The default center = 135, which represents Meth=3(Avg), Time=3, Vote=3, CGband=3 ... but the Dean-Meth #4 is very "close-by" ... it's #134: Meth=4(Dean), Time=3, Vote=3, CGband=3. I've updated the attached XLS in the earlier post, as well.

As far as I can tell from my SBAS of the 15 test symbols that I'm currently using, the Dean formula seems to be more consistently reliable and profitable than any single one of the other four. But it appears that maaaaybe the Avg(5) is a skosh better. It will take more rigorous testing to know. At least the new mapping of the Master has them right next door to one another ;~)

Here is the official and final list for the various CumV Methods ... the formulae are abbreviated so they can fit on the popup Help screen. Abbrev notes: absBody = abs(C-O) & absGap = abs(O-C1) ... these simply are abs() echoes of the terms in the numerator; TR & TruR and TruRng all mean the true range of that bar (not ATR) = max(H,C1) - min(L,C1). If these aren't relatively memorable once explained, please let me know.

... positive slider:
+1. Granville On-Balance-Vol: if C > C1 use +V, else -V
+2. Fosback Volume Price Trend (VPT): (C-C1) / C1 x V
+3. Mixed Avg(5+): BG & Cls|H-L w/ OBV, VPT, AcDst & III
+4. Dean BG: (2*C-O-C1) / (H-L+abs(C-O)+abs(O-C1)) x V
+5. Chaiken Accumulation-Distribution: (C-O) / (H-L) x V
+6. Bostian Intraday Intensity Index: (2*C-L-H)/(H-L) x V

... negative slider:
-1. Granville OBV w/C=>Guts: if G > G1 use +V, else -V
-2. Fosback Volume Price Trend w/Guts: (G-G1) / G1 x V
-3. Mixed Avg(5-): BGT & Gut|TR w/ OBV, VPT, AcDst & III
-4. Dean BGT: (2*C-O-C1 +(L-H-Body)/4) / (TruR+H-L) x V
-5. Chaiken AccumDst w/TruRng: (C-(O+C1)/2)/TruR x V
-6. Bostian III w/TR: (2*C-min(C1,L)-max(C1,H))/TruR x V

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

I've created another Zip file with 15 chart snapshots to review ... this replaces the earlier zip since the formulae are different. There are four CVW Bands per chart ... it's set up to compare the positive Dean vs positive Avg(5), and also the negative Dean vs negative Avg(5).

Focusing mainly on the FIRST pair (+3 Avg and +4 Dean BG), which one is "better" overall?

Now, focusing on the Second pair (-3 Avg and -4 Dean BGT), which one is "better" overall?

... as you do the comparisons, keep in mind that medium-blue is an early entry, small-size ToeIn ... OR, if there's no active alert, the first bright green bar is a ToeIn size (similar for purple and pink) ...

Attachments
Attachments Charts Comparing Avg to Dean Methods, for 15 Syms.zip (391KB - 1 downloads)
Top of the page Bottom of the page
SalimHira
Posted 5/10/2019 3:34 PM (#9602 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
+3
Focusing mainly on the FIRST pair (+3 Avg and +4 Dean BG), which one is "better" overall?

-4
Now, focusing on the Second pair (-3 Avg and -4 Dean BGT), which one is "better" overall?

This respond, I am reviewing again - still leery as very, very close to each other, but my bias still leans towards -4... but than, again, it calls for a specific situation for that "little edge" that is throwing me off, that I cannot seem to nail what it could be where they differ btwn -3 & -4.... while processing thru my mindset.

... finally, which seems better: +3 Avg(5+), or -4 Dean BGT ?

It's a tough one, but I lean toward -4.
Top of the page Bottom of the page
JimDean
Posted 5/11/2019 9:07 AM (#9605 - in reply to #9602)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
... Important ... four new Band colors ... confirm understanding and visual distinctions ...

Recall that the new BgnVot slider specifies Toe+Confirm for inputs 1,3,5 and specifies FullEntry for inputs 2,4. Alerts are turned OFF when the input is 2,4 since they don't *do* anything. Alerts are ON for 1,3,5 since they indicate a ToeIn-sized Trade. But also, if there is was no Alert active on the bar just before the first Bright grn/red of a new Wave, then if T+C is spec'd, the *first* Bright grn/red is *sized* as a ToeIn ... and *if* the *very next* bar also meets the Bright NetVote >= BgnVote rule, then it becomes a *Confirm* order that "boosts" the position size. However, if the next bar after the first-bright-Toe does not meet that rule, then the Wave continues, but it's only using the Toe size. Either way ... later in the Wave, after a Warn has hit followed by a bright, there could be an Add ... but that's unrelated to the T+C.

So ... a while back when I formalized the T+C option as a part of the slider, I mentioned that I was going to create a new pair of Band colors, to indicate *when* the first-bright grn/red of a new Wave was to be sized as a ToeIn, rather than a full-Entry.

As I was implementing this, I realized that in the case where T+C is active, then there *also* needs to be yet another new pair of Band colors to indicate when a Confirm bar occurs ... it's either the first (>=BgnVot) bar of a wave, just after an Alert ... or it's the second (>=BgnVot) bar of a Wave that started with a >=BgnVot Toe. Just the fact that it takes that many words to describe it, is evidence of the *need* for distinct colors to remind the user what's what, for T+C models.

That's in place now. The colors for the "normal" Alerts (which are sized as ToeIns) remain unchanged ... purple and blue. The new colors for ToeIn from the first bright of a new Wave that doesn't have an Alert preceding it are *lighter shades* of purple and blue ... VB knows them as "mediumpurple" and "dodgerblue". And, the new colors for a Confirm (described in prior paragraph) are bright purple ("thistle") and bright blue ("deepskyblue"). All the other colors are the same.

This does NOT affect any colors or bars, when the BgnVot slider = 2,4 ... that is, if a Wave begins with a bright-green or bright-red as before, then a Full-Entry size order is associated with it.

Note that the Return values also have been modified to clearly distinguish between Toe-sized, Confirm-sized orders and Full-sized orders (I'll detail those distinctions some other time ;~)

I'm attaching two identical charts for you to review. The first one is annotated, noting which bars changed ... the second one is clean so that you can view it unobstructed.

1. Are these color distinctions clear?
2. Can you clearly tell the difference between the new mediumpurple & dodgerblue and the previously-used Alert colors?
3. Are the new ToeIn colors sufficiently different from the other Wave colors that you can distinguish them?
4. Are the new Confirm colors (thistle & deepskyblue) sufficiently distinct from the other colors that might be adjacent to them?
5. Is the overall color-scheme nifty and pleasing, or is it too confusing?


PS: there are now a total of 18 colors (!) used in the Band. I'm pretty pleased about the mix ... and what seems to me to be very clear way it communicates what's going on. This color-mix will be a part of the "standard paradigm", so it's important to be "picky" about shades and hues. Thanks for your help!

(New Toe & Confirm Colors, annotated.png)



(New Toe & Confirm Colors.png)



Attachments
Attachments New Toe & Confirm Colors, annotated.png (63KB - 0 downloads)
Attachments New Toe & Confirm Colors.png (21KB - 0 downloads)
Top of the page Bottom of the page
SalimHira
Posted 5/11/2019 10:17 AM (#9606 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
1. Are these color distinctions clear? YES.

2. Can you clearly tell the difference between the new mediumpurple & dodgerblue and the previously-used Alert colors? YES

3. Are the new ToeIn colors sufficiently different from the other Wave colors that you can distinguish them? NOT THE MEDPURPLE - tends to blend in, having trouble with that - not strong enough (distinguish as the medblue).

4. Are the new Confirm colors (thistle & deepskyblue) sufficiently distinct from the other colors that might be adjacent to them? YES

5. Is the overall color-scheme nifty and pleasing, or is it too confusing? YES, NIFTY... matter of getting used to it.

consolidated from later ... regarding the followup post below, with 15 more charts
I concur with your thoughts, and plot 3 visuals are sound and seems like winner. Btwn plot 4 and 5, my leaning is towards 4. Hope it helps. Thanks.
Top of the page Bottom of the page
JimDean
Posted 5/11/2019 10:27 AM (#9607 - in reply to #9606)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
I want to keep "families" a similar gradient-hue. That is, Bull is greenish with its alert-confirm bluish. Bear is reddish with its alert-confirm purplish. It wouldn't fit to use yellow or white or brown, for instance. For future reference, I'm attaching a color chart to this post so that you can see all the choices.

(A9F50EAE-FEEA-4960-85EE-5E3602F2C33A.png)



Attachments
Attachments A9F50EAE-FEEA-4960-85EE-5E3602F2C33A.png (153KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/11/2019 11:23 AM (#9609 - in reply to #9600)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
OK ... this is the LAST post about this ... but it's VERY important imho so I want to get it right.

Currently, per prior posts, I've expanded the CumMethod options to -6 > +6 range, where -4=Dean BGT, -3=Avg(5negs), +3=Avg(5pos), +4=DeanBG.

Prior responses have indicated that +3 (avg of 5pos) is better than +4 (simple Dean), and that -4 (fancy Dean) is (a bit) better than -3 (avg of 5neg's). My opinion differs a bit ... I think the Simple Dean BG has some nuances to it that make it more attractive (related to Warn PXits and Toe entries) than I think may have been considered. But the jury is still out ;~)

I would like to SIMPLIFY, by removing things that really don't contribute a useful distinction, if possible ... it would be nice to go back to a Method range of -5 to +5 (for several reasons). And btw ... switching the code back is pretty straightforward so that is not an issue.

So, I've attached a zip file with **15** charts in it (please review them all). I'm attaching just one, with a "legend" for interpreting the 5 plots per chart. Note that the third plot is a brand new one that you've not seen before ... its the average of NINE calcs ... the Dean BGT plus the four Classics (positive) and the four Guts/TruRng negative-variants of those classics.

Note that these charts all use the new Toe/Confirm colors, which should help clarify your evaluations ... note that when a wave (usually short) just starts with a Toe and no Confirm appears, then the impact of that wave (usually not very profitable) is lessened, since the size is smaller.

Also, pay attention to where the dark-green/red bars occur ... those are partial-exits, and their placement should be a factor in your evaluation. For example, in the HAS chart, a long Jan trade shows two dark green PXits at very useful places, for plot #5 (that are not present on the other options).


I would like to eliminate two of the current options ... my initial thought is (using prior responses as the basis ... I haven't done my own review yet) that if the Dean BGT is as good as the prior opinions seem to indicate (or maybe the Dean BG), then I can make that the +3 default ... if so, I'd use the new Avg of Nine as the new -3 value ... the Dean BG (or BGT) and the two separate Avg's would go away, and the CumV slider would be back to a more-manageable -5 to +5.

If I make the change, then plot #3 and either (plot#4 or plot#5) will be the "keepers"

However, if it doesn't work out and if there's clear benefit to keeping it as is, I can do that too.

I promise that this is the LAST go-around on this. I'm pretty enthused about my own CumV formula creations, naturally ... but I won't be insulted if I need to kill them off ;~)

(Attempt at Meth=-5 to+5 range - QCOM.png)



Attachments
Attachments Attempt at Meth=-5 to+5 range - QCOM.png (43KB - 0 downloads)
Attachments Attempt at Meth=-5 to+5 range - 15 syms.zip (380KB - 1 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/12/2019 7:30 AM (#9613 - in reply to #9609)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
I haven't heard from Ken (understandably). Salim, thank you for the time you spent reviewing this. It's clearly *the* most important input. In a way, I'm glad it's such a close call between the options ... that means presumably that all of them are workable. I'm going back to the original -6 to +6 arrangement, with Avg's as #3 default, and Dean adjacent to them as #4 (http://tradetight.org/forums/thread-view.asp?tid=1432#M9600). Selah. Moving on ...

Getting ready (probably later today) to implement the four bands for Cut and Grab. Partials only if neg sliders, Full Bands always.

Our plan was to do Full Grabs (furthest below Long price) differently re tightening, so it could be a broker stop; unchanging gap with each new PX-order Step, only changing (tightening) with each Add. Broker stops use TP Order-menu gaps (smaller for each Add). So, the line would be less fluid and spend a lot more time a lot further away from price (for a profitable run) than the others.

But I hadn't considered the Broker line would work for a no-Adds Simple TP model. Sigh.

For the Simple TP, the Full Grab Broker line will be a *fixed* stop based on the last Step where an Entry was made (Toe, Confirm, or Single). It won’t rise with price since there are no Add steps to reset it. So - the “Broker Full Cut” line will really just be a “Fixed Stop Loss” line, for Simple TP - with maybe one small, early ratchet up on the Confirm Step (if T+C used).

So - I’m thinking that the planned model needs to change. I think that the Full Cuts line should be virtual using Mkt orders like the other three lines. Additionally, a Fixed-Stop line based on Broker stops as described above can be implemented. So, if Full and Partial Cuts and Grabs are all active, there would be five lines, four of which "track intelligently" with price.

ALSO: I’m trying to figure a way, using only the slider, to toggle “just Cuts” vs “Cuts and Grabs”. Maybe using "staggered pairs" sort of like Bgn and End Vote (1=24%gap,C+G, 2=24%,Conly, 3=22%,C+G, 4=22%,Conly, 5=20%C+G, 6=20%Conly. That would change the slider to -6 > +6, but the Master sampling would still be 1,3,5 I think (with C+G).

Or, I could extend the range so 1-5 is both C+G (24%,23%,22%,21%,20%), and 6-10 is just Cuts. I don’t see any logic in offering just Grabs w/o Cuts. (Of course the neg/pos slider already toggles Partial C+G on/off).

The PROBLEM either way is that I need to decide if the Master-mapping needs to grow, to represent both C+G and Conly options. If I just use -6 to +6, then 1,3,5 would have both G&C, and those COULD be the ones used by the Master, with Conly not represented in Master patterns.

Do you think that Just Cuts is an important toggle for the non-Custom user?

Do you prefer the paired 1-6 option, or the extended 1-10 option, and do you think Master needs to include samplings of Conly as well as C&G?
Top of the page Bottom of the page
JimDean
Posted 5/12/2019 8:23 AM (#9614 - in reply to #9613)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
Regarding Medium-to-Warn counting.

Currently, when the Med2Wrn count-threshold is met and a Med triggers a Warn, the Med-count is reset to half of the threshold. That is, if the threshold for Med2Wrn = 4, after it creates a Warn, the count moves back to 2 ... requiring two more Med's to create another Warn ... that assures at least one med between successive count-gen'd Warns. If the threshold =3, the reset goes back to 1.

I'm rethinking this ... I think that it's too loose. Instead of resetting the count back to half of the threshold, I think it makes more sense to just decrement the count by one. That way, if another Med (decreasing) fires right away, another Warn is generated. Otoh, if a bright (increasing) appears before another Med, then yet another decrement is applied to the count, so after that it takes more Meds to create a Warn.

Similarly, if a Warn fires due to the OppVotes hitting the Warn threshold (unrelated to Med2Wrn counting), the current logic resets the Med2Wrn count (whatever it may have been) to half the threshold. Again, I think I should tighten that up ... if a Warn fires due to OppVote count, then I think I should force the Med2Wrn count arbitrarily to the Threshold-1.

These two changes will mean that more "back to back" Warns will occur, when the NetVote is consistently getting worse. This will create earlier exits and maybe a bit more chop. Keep in mind that the Med2Warn = 3,4,3,4,4, as the EndVote slider goes 1,2,3,4,5.

I've tested this on the 15 charts for EndVot slider= 1 & 3, new version vs current. In *many* cases, the change provides a beneficially-earlier full exit (by one bar). In a *very few* cases, for the Slider=1 input, the change causes a continuous run to get chopped in half (ie exit then immediate re-entry). And in some of those cases, price was fairly flat anyways during the brief hiatus.

So, it looks like this tweak is a good one.

No changes to the Wrn2FullX rules ... they currently only decrement by one when a bright occurs.
Top of the page Bottom of the page
JimDean
Posted 5/12/2019 11:47 AM (#9616 - in reply to #9614)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
I'm moving into the trade-modelling stuff now. A *crucial* aspect to this, both re plotted "dots" and re equity calcs, is to know whether the order type for Entry/Exit is MOO (ie order fires on Open of bar just after the Signal bar), or MOC (ie order fires at Close of the Signal bar).

MOO is the "goto" N solution, for all its platforms. Calc's are done overnight (for daily bars), and responded to at the next open. For intraday (such as 10 min) bars, the equivalent is a BOO order.

MOC is possible in OT for daily-bar *entries* using AutoTrade to download data and run the calcs at a predetermined time of day (say, 3:45pm for a 4pm close). However, AutoTrade does NOT explicitly control times for Exit orders ... technically, any time a download and recalc is done during the day, then the so-far-Last price of the bar "looks like" a Close price to the calcs ... and therefore if an exit rule is met by that Last price, OT could trigger an Exit order *long before* the Close (if say a download and recalc was done at 11am or 1pm or whatever).

So, for the Stradicator to properly handle MOC orders in an "unknown" environment, it needs to know NOT to fire Exits too early. Presumably (I haven't tested this yet), if AutoTrade is set up to process potential new Entries at say 3:45pm, then that same download/recalc would ALSO cause the TradePlan to do its thing. So ... making sure a download+recalc *IS* done each day at an appropriate time before the Close is AutoTrade's job. But ... making sure that orders don't fire due to arbitrary-user-initiated download/recalcs BEFORE that time is the Stradicator's job.

Fortunately, OT has an internal table for when Sessions begin and end for each Exchange, and each day of the week. Also fortunately, OLang's native time functions are keyed off of the BAR's time, not the computer's System Clock. So, handled properly, OLang can exercise the necessary control for Daily bars without requiring the user to tell the Stradicator about their time zone or exchange sessions. This post outlines how those time functions work:
http://tradetight.org/forums/thread-view.asp?tid=1441#M9615

There is no equivalent "BOC" order type, for intraday bars ... just BOO. However, there is no actual time gap between the close and open of two intraday bars (on the same date), so the distinction is arbitrary anyway.

*** Which brings me to the main reason for this post ***

I think that the "standard Stradicator paradigm" should somehow EASILY allow the user to choose between MOO and MOC order-types and times, for daily bars. Intraday bars would use BOO orders instead of MOO, and would use specially-managed Mkt orders to simulate a "BOC" order (up to user to assure that machine is fast enough to do the calcs in whatever pre-end-timegap is made available for intraday-bars.

If I can get the managed-Mkt BOC thing to work for intraday, then it could most likely be used also for daily bars (EOD or RT), which would simplify things significantly. So that's what I'll shoot for.

The user needs to somehow SPECIFY which (MOO or MOC) to implement. And I don't think this should be relegated solely to the Cstm user ... it needs somehow to be part of one of the "paradigm" sliders. The last two sliders are already chock-full of positive vs negative and override features, so they are out. The CutGrab is similarly replete with features, so it's not a candidate. Fuzzy neg toggles on Adds, and EndVot neg toggles on PXits ... both of those are crucial so I can't mess with them.

What's left is BgnVot. Currently, when BgnVot < 0, it toggles the "cutesy" Dynamic Sizing thing described in an earlier post ... ie the Confirm and All-In size%'s are a function of how many actual NetVotes appear on the bar. But imho that's not very important and actually could be counterproductive. Also, there's a later potential (with Robust TP and maybe Simple TP too) to vary the sizing based on a more intelligent mechanism, related to SmartSizing volatility vs price. So, it's no biggie to pass on the Dynamic Sizing thing.

Therefore, when BgnVot is negative, I can make it toggle on MOC logic, with positive being the N-goto choice of MOO. Of course this means the user must purchase Powr or Cstm version, but that makes sense ... it's a useful option that warrants a few extra $$.

I'm modifying the prior crib sheet post accordingly.

The BgnVot override for the Cstm user had been "TFV" (Toe size, Full size, and reqd BgnVote), so there are 4 more characters available. These will specify the order type, AND, for MOC (aka BOC), will specify how much time before the end of the bar needs to be reserved for calculations: "TFVMm", where "Mm" specifies the number of minutes before the Close of the bar that MOC orders need for calculation and submission. Note that Mm is independent of the bar-timeframe chosen ... it's related solely to user-specific things like machine speed, number of FL symbols, feed-firing-frequency, whether there is any delay-time or not, etc.

The default for Mm, if the BgnVot slider is negative, and Daily bars are used, will be 15 minutes before the Close. That means the machine must be fast enough and the FL must be short enough so that the total time for a download+recalc to complete is no more than 15 minutes. If you think, from actual experience, that is too short, please let me know. "Just in case", I'll allow the Powr user to type in a -BMm override, but I won't document that ... I'll just tell people how to do it, if they tell me 15min is too little time (-B will be the slider-value to use).

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

Note: I'm not for-sure-positive about how AutoTrade works, re already-active TP's that might be firing Adds or PXits or FullX's. Logically, with EOD feed, if the "dedicated trading machine" is not fussed with by the user during the Session, then the ONLY time a download and recalc will be done is during the AutoTrade Window ... which would manage the timing of both the entry and exit MOC signals. I'm writing Barry to confirm this.

For RT feed with Daily bars, AutoTrade can be used in the same fashion as above ... a tight time window before the Close can be spec'd, and Entry orders would be restricted to that time period ... without the 20-min delayed data that EOD is saddled with. But Barry told me a while back that active-trade TP's with RT feed DO allow active-trade orders (ie Add or PX or FX) to fire outside the specified AutoTrade window. So, to prevent that from happening before the final time-window, OLang has to check the time internally and block any MOC signals from firing too early in the day.

However, for RT feed with Daily bars, *IF* we wanted to allow the H/L to trigger a Cut or Grab, then OLang could allow Mkt (not MOC) event-driven orders to fire before the final time window. The special text-file-management for bar-control of the Robust TP would be needed for this. Therefore, all coding for the Cuts and Grabs lines (except the "distant" SM Broker stop) will be based on MOC orders.

For RT feed with Intraday bars, since the Close and following Open are just a nanosecond apart, the order type doesn't really matter ... BOO will be used so that the backtest modelling will more closely match what's happening at the HRE. However, even with Intraday bars, it's important to "try" to use the full-current-bar info in the calc that might trigger a BOO order on the next bar ... so the OLang code needs to "manage" that timing as well. I believe that with judicious use of the "Time" functions included in the above link, that's possible. The "start the calcs time" would just be adjusted for each new bar, to the last few minutes of that upcoming bar.

When Intraday RT is used with TOO short of a "time window" for the calc's to complete before the next bar begins, the routine will "seem" to run OK, but actually some of the symbols' calcs won't be processed until after the next bar starts. Usually that's no biggie. In theory, I could set up some logic to track that, and output a report for the "washover to next bar" calcs. But that's overkill imho. The user can solve the problem by changing the "Mm" setting, or by making his intraday bars last a bit longer.

For Intraday RT feed, I can check the barlength using Periodicity and Compression. Based on that, I can make the default Mm value be shorter than 15 min for intraday bars. The OT function calls don't permit seconds to be specified. Also, it seems unlikely that even a fairly fast machine with a not-too-long Focus List could always be relied upon to complete the calcs in less than a minute. So ... for Intraday bars, I'll set the default Mm to be ten percent of the bar length, rounded off to the nearest minute (no less than one minute). That is, a 30min bar would do it's calcs in the final 3 min of the bar; a 20min bar in the final 2 min, a 13min or 10min bar in the final one min ... and a 5min or 3min bar in the final 1 min. Obviously, it would be silly to try to use this feature for a 1-2min bar. But it would work ... it just would have a lot of "washover to the next bar" cases, and the historical backtest would not match well.

I think that covers it. I've updated the crib sheet to reflect this change ...
http://tradetight.org/forums/thread-view.asp?tid=1432#M9592
Top of the page Bottom of the page
JimDean
Posted 5/13/2019 3:32 PM (#9619 - in reply to #9616)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
Adds are tricky. I've mentioned before that I'm *very* concerned about Adds occurring late in the trade, followed shortly by a full exit from a final pullback, with a net loss for the most recently Added shares.
I'm similarly concerned about bright-bar Adds occurring after a warn-pullback, when the bright bar is associated with a big jump which would be a poor entry price for the Add.
I'm also *a bit * concerned about Adds that might appear early in a trade that is just wiggling unprofitably and (as yet, anyway) seeming to go nowhere.
In summary, although the code PERMITS Adds (when the Fuzzy-slider is negative), I want them to be fairly *rare*, and nearly always *indisputably wise*.

I already had four rules in place to "qualify" an Add:
1. A non-entry bright(strengthening-vote) bar during an existing trade,
2. Sum of prior warn/pxit(s) sizes must be >= some spec'd % of the next-Add size
... subsequently I changed this to be at least one PX of any size must precede an Add ...
3. Nominal Add-size auto-decrements by 20% after each Add, so later-trade Adds reduce, to 0%
... there is also an override-rule option that limits the total #Adds, or decrements by 40% ...

Even with those rules, Adds were appearing at what in retrospect were "ungood" times. So, I created three more rules:
4. For Longs: Close <= (Highest Prior GutsPrice since last Entry|Add) - 1*ATR (Short: C >= Lowest + ATR)
... after testing, I removed the +/- ATR ...
5. Close of potential Add signal bar must show a profit *since* the most-recent Entry|Add's Close
6. If rules #1-3 are met, *decrement* the next-Add size even if #4+5 are *not* met

The #6 rule helps assure that late-in-trade Adds are *small* (even if prior failed possibilities weren't used, the decrements occur) ... while #2 assures that the "net" of (Added shares - PriorPXit shares) is not too big ... required priorPX size-sum varies with slider. The #5 rule prevents "doubling down" thinking ... if trade (or most recent leg) is a loser, then don't add more shares!

I'm not certain yet, but I might used a StopMkt order, with threshold = PrevClose of the Signal bar ... in the RobustTP for MoO (positive BgnVot) models, which would assure that the Add is only taken if the following bar does not "pop up". However, since it makes more sense to use MoC orders for the Robust model's Adds and PXits, I may not create a Robust TP for MoO. At least not unless there's a demand for it. The Simple TP should work fine for MoO.

Taken together, these rules *eliminate* a large percentage of the Adds that would have appeared with just #1-#3. Which is a good thing imho. I believe that the Toe+Confirm approach represents what *most* people think of as an "Add" ... ie in the first few bars of the trade. Most traders don't consider Adding more shares once a trade is "rolling along" ... they wait for the trade to end and then maybe re-enter.

I don't mean to say that mid-trade Adds are bad, but rather that they should be taken very cautiously, and sized wisely.
Top of the page Bottom of the page
JimDean
Posted 5/13/2019 5:40 PM (#9620 - in reply to #9619)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
The dots are appearing!

I've been working on an essential and "touchy" part of the code ... validating all the "rules" for "Signals" to be legit ... and plotting dots on the pricepane to indicate when and what they are.

Things seem to be working well, for the positive VoteGuru (no Adds or PXits).

Now I'm testing the negative-slider combos of EndVotPXit and FuzBndAdds ... and it's making me re-evaluate the rules I had in place, as I'm seeing the dots appear.

The first major issue was that Adds were occurring way, way too often, and most of them were not in places where a trader would in retrospect agree was wise. I added some rules (prior post) and think I've pretty much solved that by making "qualified" Adds fairly rare.

NOW, I'm working on the various rules that *use* the actual *sizes* of the entry/pxit/add/fullx process. And I think I may need to make one of the rules smarter.

Currently, the Add sizes automatically decrease after each add, by 20%. I've changed the Fuzz slider -1 to -5 to allow the first Add to be 60,40,40,20,20 (was 80>40). So, if the first Add is 60%, the next is 40%, and the next is 20% (final since next "would" be 0%). However, if some variant of the mod's proposed below is used, it's unlikely that actual Adds will be more than 20% anyways ... (read on). Currently, the PXit size is determined by the EndVot slider (-1 to -5 = big to small).

1. The farther along you get in a trade, the more likely it is for it's profit/bar slope to have slowed down, and the more likely it is to reverse or go into "freaky swings". So, maybe it would be better to use small PXit sizes at first, and let them grow as the trade progresses (ie the first PX=20%, and ultimately through one means or another, it becomes 100% and the trade ends).

2. If Toe/Confirm is active (recommended), and if only the Toe entry has occurred, and the price doesn't continue to improve right away to warrant a Confirm (maybe 30% of the time?), then even a fairly small PXit size will cut a relatively large chunk out of the Toe-Entry position. However, if price moved enough for a Confirm, then it seems less likely that a sudden loss will occur, with price dropping below even the original Toe entry ... so, the small starting PXit size may not be an issue.

3. If All-In is being used (which means there are no Alert bars), then many of the questionable-zone trades are gone, so what's left *should* be the more reliable trades that don't need relatively "big" PXit sizes at first.

4. The Wrn2FullX spec limits how many PXits can occur in a row, before terminating the trade. So, if the PXsize starts at say 10|20|30|40% and grows by 10% after each PXit, then even when Wrn2FullX=4 (EndVot= -5), the max PXit would be 50|60|70|80%.

5. The EndVote slider defines the starting point for the PX size ... currently slider -1 to -5 goes 50,40,40,30,30 ... but I'll change that to a "starting point" of 30,20,20,10,10. Toe-Ins are from BgnVot 1-5= 40,40,20,20,20% ... so any of those PXit sizes would take a decent chunk out of the Toe state.

6. Once the Confirm order hit, there will be more shares in the account (BgnVot 1-5 Confirm = 60,60,60,60,40 ... so total shares from T+C = All-In = 100,100,80,80,60. But in either T+C or All-In situations, the presumption is that the entry is by then a reasonably reliable signal that won't need rapid scaling-out immediately.

7. Ongoing PXits would grow by 10% each time ... so a T+C (or All-In) entry size of 100|80|60 would in *any* slider-combo cases be emptied by four successive PXits ... 10+20+30+40 = 100%.

---------

8. NOW ... consider what happens when an Add occurs. Part of the current Add rule is that the PXit(s) before it must be some spec'd % of what the next Add will be - if prior PXit size is insufficient, the Add is skipped. Also, the current Add rule is that each new Add is 20% smaller than the prior one. Using the enhanced qualifier-rules in the last post, the "dots" show that qualified Adds occur very infrequently ... so I can't rely on the 20%-reduction-per-Add rule to help much.

9. SINCE PXits seem to be a *better gauge* of how the trade is progressing ... I'm thinking of enhancing the "Add size control", by gradually reducing the "max total position size" (mentioned above), based on PXits. That is, whenever a PXit fires, the max-position-limit is reduced by 10% (and never goes up again).

10. I think that I need to "focus" the Add paradigm a bit ... maybe the new rule should be that the Add *never causes the total position size* to be greater than the T+C|All-In Entry size. The examples below illustrate this.

Extended Example: If Entry total = 100%, and initial PX(#1) = 20%, then the first exit would cut the actual size to 80%, and the total allowed would be cut to 90%. If the potential for an Add (that met all the Add requirements in prior post) came up right away, the available headroom to the limit = 90-80=10% ... which is too small (Adds are only increments of 20%). However, if another 20% PX(#2) hit before that Add, then the actual size would be cut to 60% and the max-limit size would drop again, to 80%. If a qualified-Add (#1) hit right after that, its max size could be only 80-60=20% ... bringing the net back up to 80%. The next 20% PX(#3) would cut the max-allowed to 70% and the actual to 60% ... too small for an immediate add ... so another 20% PX(#4) would need to hit first, cutting the max-limit to 60% and the actual to 40%. If the thing happens again ... a maxed-Add (#2) of 20% => actual=60%, then two 20%-PX's(#5,6) => actual = 20% and max-limit=40%. Another Add(#3) takes the actual to 40%, and the next two PX's(#7,8) would zero out all the shares of the trade.
Summary: in this example, there were three small (20%) Adds, and eight small (20%) PXits. The overall position size decreased gradually to the very end. Presumably, the "early" part of the trade contained the most profitable price-improvement, with small PX-pullbacks followed by new-leg Adds that resumed but with a smaller size. Wave-theory suggests that each new leg usually has a lower price-improvement velocity.

Quicker Example: If Entry total = 60%, and initial PX(#1) = 30%, then the first exit would cut the actual size to 30%, and the total allowed would be cut to 50%. A qualified-Add (#1) hitting right after that brings actual back up to 50%. The next 30% PX(#2) cut the max-allowed to 40% and the actual to 10%. If yet another qualified-Add appears (#2), there's 40-10=30% headroom but largest 20%-multiple Add = 20% => actual=30%, then the next 30% PX(#3) zeros out all the shares of the trade.
Summary: in this 60%-entry example, there were two small (20%) Adds, and three medium (30%) PXits. The trade presumably was much shorter than the prior example.

IMPORTANT to note: those two examples are NEVER likely to happen ... they call for Adds to be "available" after most any PXit ... but the reality is (see prior post) that the Add rules are pretty restrictive, so the two examples would more likely go like this:

Realistic 100%-entry, 20%-PXit example: The first PX(#1) cuts actual to 80%, and the total allowed to 90%. Then PX(#2) takes out another 20%, so actual=60% and limit=80%. This time, no qualified Add appears, so the next 20% PX(#3) cuts the max-allowed to 70% and the actual to 40%. If an Add qualifies now, it can only be 20% since 70-40=30 isn't a 20-multiple ... actual = 60%. Three more 20% PX's (#4,5,6) without a qualifying add after #5 wipe out all the rest of the shares.

Realistic 60%-entry, 30%-PXit example: The first PX(#1) cuts actual size to 30%, and the max-limit to 50%. The next 30% PXit would kill the trade, so assume a qualified-Add of 50-30=20% (#1) hit right after that, bringing the actual back to only 40%. The next 30% PX(#2) would cut the max-allowed to 40% and the actual to 10%. Without another (rare) qualifying Add, one more PX(#3) ends the trade.

-----

This calls for more thought.
Top of the page Bottom of the page
JimDean
Posted 5/14/2019 11:48 AM (#9623 - in reply to #9620)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
Okay ... new day, fresh re-read of the prior two posts, and some refined plans ...

First ... I modified the 2nd post back a bit, clarifying rules #2&3 and adding some italics. No biggie. And I switched #9 & #10 in the prior post.

Second ... the prior post items #1-#7 re increasing PXit sizes is actually an alternative to #8+, and I've decided *not* to implement 1-7. Reasons:
a. fairly complex to code, esp re maybe decrementing the sum due to bright bars, etc
b. it does not even approximately match the Med2Warn and Warn2FullX counting logic
c. would require significant override modifications of some sort
d. would likely be confusing, not knowing what % is used for a given warn/pxit
e. the CutGrab lines tighten during the trade, which sort of serve the same purpose
f. the Robust TP would be significantly bigger &/or more complex, to implement this

What I'm going to do (outgrowth of prior-post #8-#10 items):

A. Re #8 ... since the examples in #10 show that the likely Add sizes are already small in this new approach, and since we *want* Adds to be "biased" to occur early rather than late in the trade (if at all), I am changing the rule about the PXit size prior to the Add having to be a certain % of that Add. The new rule (matching the non-size W before A rule) will be that *any size* PXit will be required before any Add. Reason: the main purpose of requiring a PX before an Add is to help identify places where a pullback-weakening has occurred (as measured by CumV Votes, not solely price), followed by strengthening (implying resumption of the wave-trend). Also, this will simplify the code as well as the Cstm overrides, since that "required %" will not need to be specified or dealt with.

B. Re #9 ... I think the idea about reducing the allowed-max-limit is a good one ... it reflects whether or not there have been a lot of temporary-but-likely-indicative weakening instances during the trade, and presumes that the most profitable part of the trade is at the beginning. Decreasing the limit by 10% at a time makes it unlikely that the limit would ever get to 0 ... I'll include logic to prevent the limit from being less than the specified PXit size ... in that state, any kind of PXit will act like a full Exit, and no further Adds would be possible. However, since this often will limit the "utilized size" of Adds, I'm also going to make the Entry Size percentage options 20% larger:
1. BgnVot 1-5 Total Size = 120,120,100,100,80 (1,3,5=Toe+Confirm and 2,4=All-In)
2. BgnVot 1,3,5 Toe-In Size = 60,40,20 ... this reflects the "uncertainty" of the initial ToeIn
3. BgnVot 2,4 Confirm Size = 60,60,60 ... shares added only with timely bright-bar followup

... maaaybe I will use this instead ... PLEASE COMMENT re B.1-3 vs B.4-6:

4. BgnVot 1-5 Total Size = 140,120,120,100,80 (1,3,5=Toe+Confirm and 2,4=All-In)
5. BgnVot 1,3,5 Toe-In Size = 60, 40, 20 ... ToeIn = 40% of Total in all cases
6. BgnVot 2,4 Confirm Size = 80, 80, 80 ... trades w/Confirmation are more reliable than All-In

... in either case, the "All-In" options are #2=120% and #4=100%
... in either case, the #5 smaller size represents minimal required initiation (BgnVot= only 4 of 7)
... in all cases, the user can adjust what "100%" means, via the TradeCalculator shares input

C. Re #10 ... not allowing an Add to increase the size above the max-limit ... this sort of goes hand in hand with the existence of a max limit at all, but there are "issues":

1. Since Adds (and Entries) are always even multiples of 20%, while PXits are always even multiples of 10% ... this rule is mainly related to Robust TP complexities for more granular Add options ... that means PXit size choices that aren't 20%-multiples will cause "rounding down" for actual Adds.

2. Also, since PXits are usually smaller than the initial-add spec (depending on slider and overrides), that means an Add following a PXit will often be "clipped" ... which sort of emasculates the spec of the initial Add in the first place. Logically, if the user specs a larger initial Add, they are hinting that they are willing for the total position size to get larger even after the Confirm and the first PXit which is needed before the first Add (since the first PXit never wipes out the full Confirm, unless the override PX size spec is unwisely out of the ordinary.)

3. A reasonable solution to this is to keep the max-limit rule and the PX-reduces-max rule, but redefine what the initial max-limit is. The prior post uses initial max = Total Entry (ie Toe+Confirm, or All-In size). In order to allow Adds to potentially be their "spec'd" size, then the initial max-limit should be larger than the Total Entry ... increase it by the difference between the Initial Add and the PXit size.

4. As an adjunct to that, the "rounding" rule for the "actual size" of the Add used will allow rounding UP ... that is, if there is only 30% headroom available between Actual and Max, and if the Add *could* be (per spec) 40% or more at that point, then it will be allowed to be 40%, talking the actual-position-size 10% beyond the max-limit. In no cases will the Add be allowed to push the max limit by more than an extra 10%.

5. However, the code will remember that #4 "violation", and the next PXit, whatever it is, will reduce the Actual by an EXTRA 10% (as well as the normal max-limit PX of 10%) ... thus keeping the max-limit reduction "on track", and bringing the actual size back *within* that limit at the time of the PX. The benefit of this is that it's at least *possible* for the Init-Add size to be honored, but it won't affect the overall duration of the trade.

===== with all that in place, here are three examples =====

Big EntryAdd, Small-PXit Example: (using sliders) would be T+C (or All-In)=120%, InitAdd=60% and PXit=10%, which increases the Init Max by 50% to 170%. After the T+C, with *just one* PXit (which cuts Max by 10% always, to 160% here, and cuts Actual by 10% due to PX=10%, to 110%) ... then an immediate Add appears that meets all the (tough) rules, the first add would be the as-spec'd 60% (violating the limit by 10%), taking the actual size up to 170% ... so for a short while, the actual exceeds the max. However, the very next PXit lowers the Max Limit by its normal 10% to 150% ... and the PX itself is 10% bigger this one time ... so the actual size drops by 20% to 150%, equal to the max.
If a "qualified" Add hit right away, then the 10%-max-limit-extension-option would not allow the Add to even be 20% since Actual=Max at that point ... so the Add would have size=0 and be skipped ... but the Add size decrement would *still* happen (per rule #6 of 2 posts ago), reducing the potential Add size to 40% if and when the qualifications are met again.
HOWEVER, this example has a "trick" to it ... since the extremely-small fixed-PX size cuts the Actual only by 10%, and since the max reduces by 10% each PX, and since at this point in the trade the Max = Actual ... then no matter how many PX's occur after that, *no more Adds* will occur, since each PXit will reduce the Max and Actual in lockstep.
RESULT: only One Add, and it happens very early in the trade ... impossible for more Adds later on. Good ... just what we are shooting for.
WHAT-IF: assume that no potential Add (not even satisfying the simple 1-3 rules of two posts ago) is avail after the first PX, so a 2nd (or third, etc) PX hits. Since PX=10%, this lowers both the Max and Actual *equally*, maintaining the 50% differential, so when/if a qualified-Add appears, the same thing would happen (one Add, then no more), but later on in the trade. HOWEVER, this is *unlikely*, since the #2 PX rule *is* met and the #1 "bright bar" rule is *very* likely to hit, and rule #3 doesn't apply to the 1st Add ... therefore, when the *very likely* in-between-PX's bright bars hit ... and if the "tough" rules 4-6 aren't met in those cases, then the nominal-Add decrement kicks in ... which quickly reduces and soon zero-outs the potential for ANY adds ... so, even in this case, a single mid/late-trade Add is unlikely, and if it occurs, it will be small. Good ... what we wanted.

Small EntryAdd, Big-PXit Example: (using sliders) would be T+C (or All-In)=80%, InitAdd=20% and PXit=30%. In this case, since InitAdd < PXit, the Init Max just = Entry = 80%. After the T+C, with *just one* PXit (which cuts Max by 10% always, to 70% here, and cuts Actual by 30% due to PX=30%, to 50%) ... then an immediate Add appears that meets all the (tough) rules, the first add would be the as-spec'd 20% (Limit-Actual=70-50), taking the Actual up to the Limit 70%. The next PXit lowers the Max to 60% and Actual to 40%, thus allowing another Add ... BUT, due to the sequential-Add decrement rule, the next Add would be @0%-20%=0.
RESULT: just as in the example above, this allows ONE Add only ... the main reason being the sequential-Add-decrement rule. Good ... what we wanted.
WHAT-IF: assume that no potential Add (not even satisfying rules 1-3 of two posts ago) is avail after the first PX, so a 2nd PX hits. Since PX=30%, this lowers the Max to 60% and Actual to 20%. If a third PX hits with no Add, it zaps the position. But if before that, all Add-qualifiers are met, the first Add pushes Actual to 40%. The next PX drops Max to 50% and Actual to 10%. However, even if all the qualifiers for a second Add were met, none would occur, since the nominal-Add size decremented to zero. Good ... just one Add, after only 2 PX's, *if* qualifiers met.

Intermediate Example: (using sliders) would be T+C (or All-In)=120%, InitAdd=40% and PXit=20%, which increases the Init Max by 40-20=20% to 140%. After the T+C, with *just one* PXit (which cuts Max by 10% always, to 130% here, and cuts Actual by 20% due to PX=20%, to 100%) ... then an immediate Add appears that meets all the (tough) rules, the first add would be the as-spec'd 40% (violating the limit by 10%), taking the actual size up to 140% ... so for a short while, the actual exceeds the max.
However, the very next PXit lowers the Max Limit by its normal 10% to 120% ... and the PX itself is 10% bigger for catch-up ... so the Actual drops by 30% to 110%, a bit less than the max. If (unlikely) all the qualifications for a *second* Add hits right after that one PX, the Add would have a nominal size of 20%, due to the sequential-adds 20%-decrement. That Add would be allowed to "violate" the max-limit by 10%, taking the Actual to 130%.
The next PXit lowers the Max by its normal 10% to 110%, and lowers the Actual by 20% plus catch-up 10% to 100%. So it would seem that there's barely enough room for another Add ... BUT, the sequential Add-decrement hits again, lowering the next-Add nominal size to 0% ... therefore there will be no more Adds.
RESULT: this allows only two Adds (if all tough qualifiers met), mainly due to the Init being 40%, in combo with the sequential-decrement rule.
WHAT-IF: assume that no potential Add (not even a simple bright bar) is avail after the first PX, so a 2nd PX hits. Since PX=20%, this lowers the Actual to 80% and Max to 120%. If a qualified 40% 1stAdd appears now, Actual = Max = 120%, and decrement rule sets next Add nominal to 20%. When the third PX hits, the Max drops to 110% and Actual to 100%. Another tough-to-qualify Add appears, and the extra-10%-max rule allows it: Max=110 and Actual=120%. The next PX does 20+10% catch-up ... Max = 100% and Actual drops to 90%. At this point, no more Adds are possible, since the second decrement makes the nominal=0. If no FullX rules appear (there are several possibilities), then presumably the trade keeps moving profitably, and it will take five PX's to wipe out the position size. Good ... Adds only at the start, with plenty of room for ongoing profit moves to utilize the "extra" shares.

Of course there are other slider-combos of Entry, Add and PX ... but this long-winded set of three examples + "what-ifs" should have adequately explained how the rules work, and also proven that the normal way things play out will limit Adds to the early part of the trade, which is my key concern ... and the rules 1-6 will limit the Adds to a profitably-moving trade, with decent buy-in prices.
Top of the page Bottom of the page
JimDean
Posted 5/14/2019 2:35 PM (#9624 - in reply to #9623)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
A. With all of that in mind, I'm considering modifying the Initial-Add slider-size options to its original range: FuzzAdd slider -1 to -5 = 80,60,60,40,40 ... ie 20% higher than the prior set of examples used. The reasons for the "staggered" sizes (rather than 100,80,60,40,20) are:

1. 100% seems like an inordinately large Add, and 20% seems silly-small for a "first and only" Add
2. the slider is also varying Fuzz% = 0,15,30,45,60%, so the stagger allows the same Add size to be modelled for two different Fuzz%'s
3. if the GuruVot slider (Powr) is used from -1 to -5, the staggering here logically matches up nicely with the T+C vs All-In and 6,6,5,5,4-NetVot stagger for the BgnVote-slider, and the 50%,40%,40%,30%,30% PX-size and 2,2,3,3,4-OppVot stagger for the EndVote-slider.
4. I'm allowing the override to spec InitAdd=80%, so the RobustTP has to support it, so it might as well be represented in the slider (even if just for slider=1)

B. Also, I'm revising the EndVot-slider PXit-size options halfway back to where they were earlier ... last post assumed 30,20,20,10,10 ... earlier they were 50,40,40,30,30 ... I'm changing them hopefully for the last time to 40,30,30,20,20. Reasons:

1. 50% seems too big, wiping out the trade with just two PX's, and 10% seems silly-small - hardly worth paying the commission
2. the slider is also varying OppEndVotReg=2,2,3,3,4 ... so the percent stagger matches up two different PX sizes with the same #votes, making for more, interesting combinations.
3. the slider also varies Med2Wrn#, Wrn2FX# thresholds: 3m2w, 4m2w, 3m3w, 4m3w, 4m4w ... each is different but the #Warns>Full staggers like the Votes do, pairing with differing PX%'s ... again, making more interesting combinations.
4. A "larger smallest" PX% of 20% will scale out of unsuccessful trades more quickly than 10%.

C. But before adding that extra 20% to the nominal InitAdd sizes and 10% to the PXits, I should probably see how those changes impact the Examples. Without further ado, here they are, revised for that other range (and note that the prior examples still are possible, especially if you consider overrides):

======

Big EntryAdd, Small-PXit Example: (using sliders) would be T+C (or All-In)=120%, InitAdd=80% and PXit=20%, which increases the Init Max by 80-20=60% to 180%. After the T+C, with *just one* PXit (which cuts Max by 10% always, to 170% here, and cuts Actual by 20% due to PX=20%, to 100%) ... then an immediate Add appears that meets all the (tough) rules, the first add would be the as-spec'd 80% (violating the limit by 10%), taking the actual size up to 180% ... so for a short while, the actual exceeds the max. However, the very next PXit lowers the Max Limit by its normal 10% to 160% ... and the PX itself is also 10% bigger this one time ... so the actual size drops by 30% to 150%. If a second Add that meets all the rules appears, although its sequentially-reduced nominal is 60%, the 160-150 headroom limits it to only 20%, leaving the Limit=160 and Actual=170
Another PX lowers Limit to 150% and Actual to 150%, which means no reduced-to-40%-nominal Add is possible.
Yet another PX (2 in a row now) drops Limit to 140% and Actual to 130%, allowing an unlikely-to-qualify-yet-again Add, but again headroom-limited to only 20% ... leaving Limit=140 and Actual=150.
The fourth PX of the trade sets Limit=130 and cuts Actual to 130 ... so even if an Add qualified, the zero-headroom would block it. A fifth PX and Limit=120, Actual=110 ... the sequentially-reduced nominal-20% Add barely fits ... new Limit-120 and Actual=130. The next catch-up PX drops them to Limit=110 and Actual=110.
No further Adds are possible, since the next sequential drop takes the nominal Add size to zero. So, if none of the several possible FullX events occur, then the trade can last a lot longer ... it will take 6 PX's before all the shares are gone.
RESULT: in this very unlikely example, all four possible Adds fired (80,20,20,20), but the various rules prevented even this extreme case from applying anything other than the smallest possible Adds after the first one ... and after they were done, the trade potentially lasts a *long* time. If you have a crystal ball, THIS is the set of size-choices you should use!
WHAT-IF: it's far more likely that the bright-bar between PX's that triggered the example-Adds would in some (or all) cases NOT satisfy the "tough" Add rules 4-6 ... in which case the nominal-Add size would still decrement, but no Add would occur. And note that when the 4-6 rules are met, there's a very good likelihood of the Add entry price being a fairly good one.

Small EntryAdd, Big-PXit Example: (using sliders) would be T+C (or All-In)=80%, InitAdd=40% and PXit=40%. In this case, since InitAdd = PXit, the Init Max just = Entry = 80%. After the T+C, *just one* PXit cuts Max by 10% to 70%, and cuts Actual by 40% to 40%) ... then if an immediate 40%-nominal Initial Add appears that meets all the (tough) rules, it would barely make it since the rule allows the max-limit to stretch by 10%, bringing the Actual to 80%. The next PXit lowers the Max to 60% and subtracts 40%+ catch-up 10% =50% from the Actual, to 30%.
The next Add decremented nominal =20%, which works (if all qualifying rules met) ... Actual goes up to 50%. The next PX drops Limit to 50% and Actual to 10%. Even though there's headroom, there are no further Adds since the nominal decrement has dropped to zero. Just one more PX kills the trade.
RESULT: this case has two Adds totaling 60% with two PXits after them that end the trade. The Adds are small ... one at beginning and one in the middle. It's unlikely since the difficult rules 4-6 usually aren't met.
WHAT-IF: assume that no potential Add (not even satisfying rules 1-3 of two posts ago) is avail after the first PX, so a 2nd 40% PX hits ... that kills the trade. Or, assume that the first Add hits and the second one is never fully qualified ... the 80% net after the first Add is cut to 50% due to catchup with the next PX ... and two more PX's kill the trade. Either of these cases (or no Add at all) are much more likely than the both-Adds-fully-qualified first case.

Intermediate Example: (using sliders) would be T+C (or All-In)=120%, InitAdd=60% and PXit=30%, which increases the Init Max by 60-30=30% to 150%. After the T+C, with *just one* PXit (which cuts Max by 10% to 140%, also cuts Actual by 30% to 90%). The first tough-to-qualify nominal-60% Add squeak past the limit by 10%, taking the actual size up to 150%.
The next PXit lowers the Max Limit to 130%, and the Actual drops by 30%+10% to 110%. If (unlikely) all the qualifications for a second Add hits right after that PX, the sequentially-reduced-nominal-40% Add would only be allowed 20% execution, taking the Actual to 130%.
The next PXit lowers Max to 120% and Actual to 100%. If (very unlikely) fully-qualified third Add with nominal size of 20% hits, it raises the Actual to 120%. But after that, the Add-decrement rule has dropped to 0, so no further Adds. Four more PXits end the trade, if no FullX rules intervene.
RESULT: this allows all three (60,20,20) Adds (if all tough qualifiers met), but only the first is nominal. Four PXits after that imply those Adds are all in the first half of a long trade. Good.
WHAT-IF: as suggested many times, the likelihood of all the Add-qualifier rules being met on even one Add is tough ... but for them to happen two (or three) times in a row is nearly ridiculous. So, if the prior example had a bright-bar sequential-nominal-Add reduction instead of the first add, then when the second Add rolled around after another PX (Limit=130% and Actual=60%), the Add would only be 40% ... so Actual goes to 100% and the nominal cuts to 20% for the next Add. Next PX makes Limit=120% and Actual=70% ... and if we assume the unlikely qualified bright after that Adds 20% (our last possible Add), the Actual becomes 50% and two more PX's kill the trade. Note that in these a-bit-more-likely scenarios (actually, no Adds is the most likely), even with mid-trade Adds, the net position size isn't very big. So, we're still good.

Keep in mind that the 3rd example on the prior post (and its whatif's) is still a valid slider-combo even with both the Add and PXit sizes having been raised here. The first and second prior-post examples are "legit" cases if either the Add or the PXit size used a Cstm-version override.

Whew. Congratulations for reading all that! I'll save these explanations for formal documentation.
Top of the page Bottom of the page
JimDean
Posted 5/14/2019 6:14 PM (#9625 - in reply to #9624)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
... Time for another crib-sheet update ... I'll leave the prior one, for comparison ...

========= crib sheets for XPRT positive +POWR negative +CSTM overrides ===========

*** LIST OF XPRT POSITIVE-SLIDER OPTIONS *** (save)

MasterTymVotGapMeth- pos 1-225= 4-tiered-seq-map: TymFrm > VotSpec > CGgap > CumMeth
... def=113= 3,3,3,3; Outer>Tym=1,3,5; Vot=1,2,3,4,5; Gap=1,3,5; Inner>Meth=1,2,3,4,5
CumMethBasic2Refined- GranOBV, FsbkVPT, 3=avg(5), DeanBG, ChaikAD, BostNtraNtnsNdx

=== GURU_TymFrmFst2Slo- positive maps directly to positive of three Experts
MAvgSpeedPdsSm2Lrg- positive 1-5 uses identical FMS pds for Ema=>Sma+Wma & EmH=>WmH
MAvgTypSnug2Gradual- positive 1-5 = WmH, WmH&EmH, WmH&E, EmH, EmH&W calc methods
MASlopePdsLess2More- pos 1-5 = Lrs(2), Wma(Lrs(2),2), Lrs(3), Wma(Lrs(3),2), Lrs(4)

=== GURU_VotSpecTyt2Lax- positive maps to experts: w/NO SmartSize, Adds, or PXits
BgnVotNetNatcMny2Fw- positive 1-5 NetVotes+Ntry: 6t+c, 6full, 5t+c, 5full, 4t+c
... 1-5 SizePcts: All-In=140,120,120,100,80; Toe-In=60,0,40,0,20; Confirm=80,0,80,0,80
EndVotOpXmwFw2Mny- pos 1-5 OpposVotes+MWcnt: 2V2m2w, 2V3m2w, 3V3m3w, 3V4m3w, 4V4m4w
FuzBandAddCutSm2Lrg- positive 1-5 FuzzBand for neg/~0/pos evals: off,15,30,45,60%

=== 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
BarWndoTrdDirL3cS6c- Plot=Wdth(>Hre), Rtn=Bb4Hre(9wide); Longs@300+, Shorts@600+
OutputReturnHelpPlot- positive 1-5= Plot Band, B+3Strp, Eqty, B+2Hist, Detail (0=Help)

*** LIST OF POWR NEGATIVE-SLIDER OPTIONS *** (save)

MasterTymVotGapMeth- negative 1-225= same sequence, but assigns negative values
CumMethBasic2Refined- negative uses Guts & TrueRange; -3=avg(5)

=== GURU_TymFrmFst2Slo- negative maps directly to negative of three Experts
MAvgSpeedPdsSm2Lrg- negative 1-5 "visually similar" FMS pds for S,W,E and WmH,EmH
MAvgTypSnug2Gradual- negative 1-5 = Wma, W&E, Ema, W&E&S, W&S calc methods
MASlopePdsLess2More- neg 1-5 (slower) = Wma(Lrs(4),2), Lrs(5), Wma(Lrs(5),2), Lrs(6)

=== GURU_VotSpecTyt2Lax- negative allows Adds and PX,PG,PC (ie Robust TP)
BgnVotNetNatcMny2Fw- negative 1-5 same ReqV+Ntry, but uses MOC instead of MOO orders
... undocumented Powr MOC override -MmB: B= neg-slider val; Mm=#minB4barC (see Cstm)
EndVotOpXmwFw2Mny- neg 1-5 allow logic-PExits (not PC,PG) w/Sz: 40%,30%,30%,20%,20%
FuzBandAddCutSm2Lrg- negative 1-5 same Fuzz% plus activates reducing-Adds option
... neg1-5: InitAdd%=80,60,60,40,40 (@nxtAdd-20%); Adds req: Bright w/prev Warn/PX,
... 3 prc rules, possible Pct-Lim by max-TradeSize= TotNtry+InitAdd-PXit (poss +10%)

=== CutGrabGapSzSm2Lrg- neg 1-5 same FullX C+G, plus PXit Cut+Grab (neg 6-10=CutOnly)
... PC&PG def=PXsize; PC= dkGray WarnPX, PG= ltGrayPX (notWarn,noAdd); FC&FG= blackFX
BarWndoTrdDirL3cS6c- neg toggles on Equity-Vote Filter (req's license) ... all vers
OutputReturnHelpPlot- neg specifies Return type (pos=Plot,0=Help) ... all versions

*** LIST OF CSTM MANUAL-INPUT OVERRIDES *** (save)

MasterTymVotGapMeth- typed #### reads 10-param tuned sets from (licensed) text file
CumMethBasic2Refined- CCCM: M=CumMethInp, CCC= CC.C CapVmult (100+ => Capping off)

=== GURU_TymFrmFst2Slo- Fltr1=PPPPPFG: G=GuruInp; F=FltrID, PPPPP=parms (Shell Indic)
MAvgSpeedPdsSm2Lrg- FfMmSs: Ff,Mm,Ss = fast,med,slow MApds (neg=same)
MAvgTypSnug2Gradual- GCT: T=MAtypInp; G=#SigFig digits; C<>0 => Hull StkV uses Wma+Ema
MASlopePdsLess2More- WwwL: L=SlopePdsInp; Www= CumWndoPds (neg=slower-slope-set)

=== GURU_VotSpecTyt2Lax- Fltr2=PPPPPFG: G=GuruInp; F=FltrID, PPPPP=parms (Shell Indic)
BgnVotNetNatcMny2Fw- TFVMm: BgnV=7-4; FullNtr=0-7*20%; ToeNtr=0-3*20%; Mm=#minB4barC:
... ignore for MOO(pos); negMOC Daily def=20m; negIntraday def=BarLen/10, >=1min
EndVotOpXmwFw2Mny- PMWV: EndV=2-5; Med2Wrn#, Wrn2FX#; PXsz=0-5*10% (neg=usePXits)
FuzBandAddCutSm2Lrg-MAWBb: Bb=0-99%, W=1-9*20pds; Add=0-4*20%, M=AddLimitMethod
... M= 0-4: 0-3= decrem@Add -20%, 1-3= Limit Max#ofAdds; 4= decrem@Add -40%

=== 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)
BarWndoTrdDirL3cS6c- BbbTWww: Www=WndoWdth, Bbb=#Bb4Hre; T=0-5=B/L/S & FWeStatUse
OutputReturnHelpPlot- EqtyVote IRCVS##: ##=PltRtn; S~TimeG, V~VoteG, C=Cntl
... I&R=SmartSize Invst&Risk Ntry +/-10% from ATR/5% study (RobustTP only)
Top of the page Bottom of the page
SalimHira
Posted 5/15/2019 5:41 AM (#9626 - in reply to #9624)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
Hi Jim:

I looked at the writeups and examples, and do not have much to comment - it all looks good, everytime I re-read, something else continues and pops in mind :-) to reflect upon. Lots of ideas.

In beginning, it kind of intimidating as everything new to someone never exposed too this concept (including myself, and never used these kind of methodology). So, one suggestion, to launch thought-process - I'd like to view, in addition, to the various examples you have provided in %'s, to include one-simple example as starters with how when individual starting with actual "share numbers", i.e., 100 shares, bought & than, partial sold (#'s), shares Added (how many), etc. etc... till full exit "# of shares", (left 0), scenario in a real life kind of situation that may unfold with Adds, PXit, etc. would work that they can relate too, that includes with providing the percentage examples. I believe, from there upon, the individual should be able to follow the rest of your %'s examples and explanations you have provided.

Some areas, I can see someone can get tangled up in thought with the %'s, that only, will make them come back to you for a refresher :-). In short, one real life example that a user may relate too for them to launch off.

Thanks, Salim ...
I’m glad to hear that there was only one word (percent) that you had issues with.

Please re-read/skim, but everywhere you see “%” read “shares”. Or, if you prefer, “dollars”. The explanation is exactly the same with any of the three words.

When I finally have time to write things up, I might add one more example, with a snippet of a chart, and arrows pointing to bars. The huge, huge problem with doing that is the true “rarity” of Adds as things now stand. It be practically impossible to find actual cases of all the examples, re how they play out.
Top of the page Bottom of the page
JimDean
Posted 5/15/2019 6:59 PM (#9631 - in reply to #9626)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
I'm tweaking the Ntr/Add/PX/FX "dot-signals" today, as I review the impacts of the rules ... so this post will "grow" during the day. Please watch for bolded questions and answer ASAP if you can.

===== Initial thoughts:

A. Some bugs to work through, but it appears at this point that the "sizing" rules for PX's => FX's are chopping up the Waves a bit more than I'd like. Also, there are VERY few Adds appearing ... I tested all 15 symbols with 25 permutations of EndVPX and FuzAdd negative-sliders, and only found three bars ... all on AAPL, where Adds ever appeared. They were in just the right "kind" of locations, but I expected them not to be quite *that* rare. This needs more review, but there are three things to try:
... 1. consider loosening up the "tough" Add rules #4-6 somewhat.
... 2. consider making the PX's smaller (30-10% instead of 40-20%)
... 3. consider logic-mod's so late Adds are *more* discouraged, for Shorts
When the "D" mods were made, the charts didn't look so problematic. I'll keep an eye on it though

B. Too many of the "short" trades initiated as a Toe are also Confirming on the second bar, even though the trade is in a chatter-zone and really should not be in play. So, I'm thinking about changing the Confirm rule to require that the bright which fires the confirm is always the *2nd* bright after the Toe/Alert. opinions?
Major fixes and tweaks and qualifiers for T+C logic during "E" seem to have resolved this ... I'll keep an eye on it


==== Second Check-In:

C. Just noticed that the current code allows cases where the Confirm-bar Close is actually *less* than the Toe-bar Close. That is, the Confirm is an "Up" bar, but it comes after enough of a "Down" leg since the Toe, that even though it's bright, it's not really confirming anything about the trade direction. And that's what Confirm is supposed to be about. So, I'm adding that rule for Confirms ... the Confirm-entry ONLY is permitted (w/existing rules), if the Close of the Confirm bar shows a profit vs the Close of the Toe bar.
... I could also require the Confirm Close to be better than the prior Close - should I?
... and/or, I could require the Confirm candle (O-to-C) to be green/red for L/S - should I?
... &/or, I coud require both of those conditions ALSO for the Toe-In bar - should I?


For now, I'm implementing the Conf C better than Toe C, and I'm going to test out using *either/or* of the rules in bold above, for both T & C. That is, for Longs, if C > C1 OR if C > O for the T|C candidate, it passes the test.
I ended up using "and" ... ie both rules ... I modified the C vs C1 to allow ATR/20 as a fuzzy overlap. This seems to nicely eliminate some chatter-trades.

D. Currently, the EndVotPX slider 1-5 assigns: 2V3m2w, 2V4m2w, 3V3m3w, 3V4m3w, 4V4m4w
... and when the slider is neg, it also sets PXit sizes to: 40%, 30%, 30%, 20%, 20%

The idea for this and the BgnVot slider is for 1&2 and 3&4 pairs to be identical re #Votes, but have the other "nuances" for PXits & T+C|All-In vary within each pair in a logical fashion. For EndVotPX, the nuanced variants are M,W,PX%. PX% applies when a Warn is created (for whatever reason) ... the current mapping has two diff PX%'s for each pair, as it should be ... AND, the PX% gradually decrease as the slider increases. Good.

However, the M's (ie #Meds to create a Warn) currently "stagger": 3,4,3,4,4 ... there are two options per pair but the sequence is not smooth. Since M>W is the "count" equivalent of the PX% size (ie when M succeeds, a W is gen'd using PX size), the sequence should be similar. I've noticed this on the chart, too, now that PX dots show up.

The W's are in a sensible progression ... they create fullX's, so they "relate" to the Votes and don't vary within a "pair" ... W's are just different logic for ending a trade ... 2,2,3,3,4 is fine as is.

Therefore, I'm changing the M-list to 2,3,3,4,4 ... the only "issue" with this is that "2m2w" means that a succession of three M's without any brights between them will create a full exit ... second M is converted to a Warn, and third M makes another Warn which auto-converts internally to a FullX. That's not a bad thing ... it is after all the "1" input ... but it's pretty scaredy-cat logic.

So the overall EndVotPX 1-5 Vmw map becomes: 2V2m2w, 2V3m2w, 3V3m3w, 3V4m3w, 4V4m4w
I've tested this and it works like a champ.


==== Final Check-In:

E. Not sure if I mentioned it before ... I added a new "full exit" Indigo (very dark purple) color to the band, to indicate when a full exit occurs because the SizePct drops to zero (ie due to PXits). So, there are three colors that might appear when a trade ends: midnight blue (was navy) = "normal" rules (a bunch of them); black = either a reversal or M,W logic; indigo = position size dropped to zero. This is informational only ... the Signal return in every case is "full exit". ALSO, I tweaked the various shades of blue to better distinguish between them ... a ToeIn from an Alert is regular blue, a ToeIn as the first bright is a clearly a lighter color but not bright; a Confirm after either kind of ToeIn is a fairly bright blue. For All-In mode, the Entry is bright green or red as before. The color-families make sense, and the individual colors are easy to distinguish.

F. I've spent most of the day working over the ToeIn, Confirm, PXit, and FullX code. There are *many* permutations of what can happen and when ... it took a lot of work to tweak and revise to cover all the situations. I'm pretty sure that is complete now, but I'll give it a once-over tomorrow AM or later tonight, with fresh eyes. This logic is hugely important ... I'm pleased with the results.

G. Forgot to mention ... the prior posts about the new Add and PXit logic which called for changes (simplifications) to the slider-overrides have all been implemented. I'm not actually testing the overrides yet, but the variables they assign are integral to the calcs, so I'm confident there won't be a need for major re-coding later. The big unknown is whether or not some of the oddball override patterns that cannot be modeled with sliders, will really be a lot "better" than slider-models. If I've done my intuitive tasks properly, they won't.
Top of the page Bottom of the page
JimDean
Posted 5/16/2019 8:52 AM (#9632 - in reply to #9631)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
Another new day's post with progressive updates ...

===== Initial thoughts:

A. I did a thorough review once again of the T+C, All-In with FullX models. Tweaked a the price-fuzz amount regarding the C > C1-ATR/fuzz (longs) rule ... I reduced it from my initial guess of ten, by stages down to fuzz-divisor=50. Thus the comparison is very close to a simple C > C1, but the fuzz allows for minor vagaries in negotiated close-price. Also, I did a final review of the BgnVot options of 6,5,4 ... confirmed proper operation and reasonable range. I'm satisfied that all these rules are solid now.

B. Now focusing on repeating the eval for PXits (EndVot slider <0). I'd modified the M,W a tad bit (to make the M-progression smooth= 2,3,3,4,4) and had reassigned the PXsiz%'s to 40-20 (orig was 50-30, toyed with 30-10). All-in-One: 2V2m2w40, 2V3m2w30, 3V3m3w30, 3V4m3w20, 4V4m4w20
Initial overview (15 symbols @ 6mo's) indicates that:
1. it seems likely that the rules might need to differ for longs vs shorts
2. the MW's cut off longs a bit too early; the PX%'s cut off shorts too late (NOT consistent tho)

The typical "Short" trend has a sm-med drop, a noticeable pullback, a med-big drop, then a bounce up and back. At least that's how I'm thinking of the run for logic purposes. So ... any Adds for Shorts should be early, NOT late (will work on Adds next). And Warns at the beginning of the run should not reduce size too much, but at the end they should quickly get to a full exit. This implies the #Meds2Wrn on high side (to minimize #Warns at first), #Wrns2FX on low side (to quickly FX at end), and PX% on high side ... or maybe even ramped-PX, where first PX is small and last is large.

Otoh, a typical "Long" trend moves up fast initially, pauses or has a small pullback, moves up for a longer period but not as rapidly, has a med pullback, then any further upwards move is either at a slow rate, or highly volatile, or both. Rules for Adds can be more flexible, allowing some mid-run, as long as they aren't too big (much like prior written-out examples). Potential for several manageable pullbacks implies #Wrns2FX could be higher, and to encourage early Adds, #Med2Wrn could be lower (Wrn is req'd before an Add can be considered). Since Adds are tough to qualify, and since there can be several Warns during an extended but typical trend, the PX% shouldn't be too big, so as not to end the trade too early.

So, maybe change from 2V2m2w40, 2V3m2w30, 3V3m3w30, 3V4m3w20, 4V4m4w20 to:
Shorts: 3m2w50, 4m2w40, 4m3w40, 5m3w30, 5m4w30
Longs: 2m3w40, 3m3w30, 3m4w30, 4m4w20, 4m5w20
... increased M's for shorts, increased W's for longs, and increased %'s for shorts
... this presumes the same paradigm, with PX%'s and MW's constant during the trade (no ramping)
... the slider-def's => two lists; EndV override PMWV => PMWpmwV: caps=Long, lower=short


===== Second Check-In:

C. Increasing the W's for Longs doesn't help and sometimes hurts ... so changed back to same as for shorts, but for now, left in the other mod's mentioned above. However, to keep the #W2FX comparable to the PX%'s,
Shorts: 3m2w50, 4m2w40, 4m3w40, 5m3w30, 5m4w30
Longs: 2m2w40, 3m3w30, 3m3w30, 4m4w20, 4m4w20
... need to test more, with Adds ...

D. Finally got round to updating the popup help that has all the derived settings, etc. Fixed all prior lines, added some more for Bgn/End/Fuz derived values. Still need to add lines related to CutGrab, and handle overrides for Filters, BarWndo, and PltRtn. Along the way I also fixed the order of inputs and syntax for the popup function-call strings.
Top of the page Bottom of the page
JimDean
Posted 5/18/2019 3:11 PM (#9633 - in reply to #9632)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
The time has come to update the Help popup. The single most important pane is the one that reports what the actual Input values are for each parameter ... AND provides the "derivative" values related to the Master & Guru-mapping, along with the complex Expert-rules. Those derivative values give essential insight as to how the Stradicator logic is working for a given pattern-model.

Note that the Cstm version provides really, really in-depth override-control over virtually ALL the "derivative" values that are reported here. When the overrides are manually typed-in, they can use up to *seven* digits (with a minus sign) ... this eats up space on the Help pane line, and therefore requires smart formatting to accommodate that.

Also, *many* of the "normal" slider inputs create such different derivative inputs, that a lot of fancy re-formatting needs to be done even without overrides. The idea is to provide as much info as possible, within the Help-panel width restriction, and always in the same "logical" location.

I'm attaching two snapshots ... the first is the popup when "pure-default" inputs are used; the second is the popup when virtually every Cstm-version override-able param has manual inputs. There are *many* variants in the formatting, depending on the input values, but the same info is always on the same line.


(HelpDetail+Params - Default.png)



(HelpDetail+Params - Overrides.png)



Attachments
Attachments HelpDetail+Params - Default.png (120KB - 0 downloads)
Attachments HelpDetail+Params - Overrides.png (122KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/18/2019 6:35 PM (#9634 - in reply to #9633)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
The next Help panel after that shows the function call. It needs updating re the Return options, but I do have the actual func call string corrected for the new and rearranged variables.

I've used the "crib sheet" info, unchanged but with many line-breaks added with indenting, so that info will fit on the Help pane. Later I might take time to reword, etc ... but at least for now, it's all there.

The arrangement is nifty ... Help Panel #3 will appear for Xprt, 3# & #4 for Powr, and #3,4,5 for Cstm. I need to create another one for Easy. See attachments:


(Help Panel #3.png)



(Help Panel #4.png)



(Help Panel #5.png)



Attachments
Attachments Help Panel #3.png (358KB - 0 downloads)
Attachments Help Panel #4.png (330KB - 0 downloads)
Attachments Help Panel #5.png (431KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/19/2019 11:57 AM (#9635 - in reply to #9634)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
I'm rearranging the Help panels so that the most-useful that an experienced user might want is first, then the second-most useful, and so on.

ACTUAL INPUTS & DERIVATIVES panel is without question the most useful ... it concisely and completely reports all the values that drive the model and are necessary to explain its behavior.

FUNCTION-CALL for OMNISCRIPT panel (attached) is likely the next-most useful ... and since it requires a list of the various Return-parameter choices, that list is in the panel which immediately follows it. I can't combine that list on this panel, since the "InputBox" format that provides the copy-able function-call string has a "squished" text width.

I'm working now on the Return-value options and Plot-explanations ... this may grow to two panes ... I figure that even an experienced user might need reminders of the multiple Return possibilities, and what the various digits mean ... and may need reminders of what the Band colors and Histos, etc mean. I won't be giving really complete explanations in the Popups ... it would be too long, and I can't include snapshots to illustrate colors, etc. But hopefully the recap will be sufficient for all but the novice user. There will be a PDF manual for those folks ... &/or Training Videos (probably Videos before PDF).

Following those panes, I'll offer from 1-4 more panes (early samples with poor formatting shown in the prior post), depending on the Version that the customer is using. Easy gets one pane, Xprt gets the Easy pane plus another one with detail about the six Expert sliders, for their positive-value ranges. Powr gets yet another pane, explaining the negative-slider options for all but the Master input. Cstm gets another pane, explaining all the manual-override inputs.

A total of 8-9 panes. Of course, by clicking "No" or Esc at any point, ongoing panes are cancelled.

Do you think this plan is a good one?

(Help Panel #2 - OScript.png)



Attachments
Attachments Help Panel #2 - OScript.png (185KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/21/2019 8:31 PM (#9636 - in reply to #9635)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3796
20001000500100100252525
Location:
USA: GA, Lawrenceville
Extensive eval done re TradePlan requirements and structure, so that min# diff Signal types can be defined. The notes below explain it all. They also provide for even more Ribbon-Band color variants, so that each kind of event has its own color. The Return values will be similarly expanded.

===========

Current definition for Signal is TOO detailed ... TradePlan analysis below allows simplification:
'Signal (0= no sig for this bar) ... SigNAX (BrkFX based on H|L, others on C)
'T.Ppp: TrdDir +L,-S; Size as Decimal Ppp% (always mult of 10, so really just Pp)
'LONG pos: 9=NrmNtr,8=ToeNtr,7=Cnfrm,6=Add,5=GrbPX,4=CutPX,3=VotPX,2=FullX,1=BrkFX
'SHORT neg: 9=NrmNtr,8=ToeNtr,7=Cnfrm,6=Add,5=GrbPX,4=CutPX,3=VotPX,2=FullX,1=BrkFX

Event-based Sigs use *same* TrdPlan 10%-inc PX Cond+Ord, so all PX same; BrkrFX req sep SM Order
... Ppp size used in Cond-Shell OLang check to fire Cond=True (OLang=> generic TP for diff Strads)
... No different for MoO, MoC, Limit or Mkt orders used for PX's &/or Adds (poss partial-fill prob)
... Event-based FX *never* Limit order, but otherwise just bigger-size PX, so Sig "T" can be same
S1=Toe|NrmNtr, S2-8=szdBrkFX, S9-15=szdCndFX @+0|4-6 CndCnfrm, S16-21=TCszBrkFX, S22-27=TCszCndFX

"ScaleEntry" TP - separate MoO and MoC versions ... no Add/PX support
Step 1 has 7 Stradic-Ctl Cond'ns for init size: Toe% = 20,40,60 or Nrm% = 80,100,120,140
Step 1 same-bar jumps to one of 7 Steps @w/uncond Broker-SM order, based on 20-140 size
Each of 7 Broker-SM steps jumps to 1 of 7 diff-init-size FX|Confirm Steps, each having:
... Full-Exit event-Condition for that particular Step-1 size (Stradic controls firing)
... #Strad-Ctl Cnfrm scale-in Cond'ns depends on Step1 Toe sizes only - T+C never > 140%
... CnfrmCondSizes: Toe=20:20,40,60,80,100,120; Toe=40:20,40,60,80,100; Toe=60:20,40,60,80
If Confirm fires, jump to one of 6 Steps to update uncond Broker-SM size & price-level
... Six, since smallest Toe+Cnfrm= 20+20=40, largest= 140(cap) => 40,60,80,100,120,140
Each refreshed-BrokerSM step then jumps to 6 same-Net-Size Strad-Ctl Cond Full-Exit steps
So, total# "ScaleEntry" TP Steps= 1+7+7+6+6= 27; Cond's= 7+7+7+15+6+6= 48

SmartSize -10%|0|+10% size-adj as func(SymATR vs AvgC) - Cstm-Strad Sig= T.PppIR (IR=PltRtn ov'ride)
... license activates SmrtSiz DLL calc, in the generic OLang-shell Cond-Stops (else no Ppp change)
... requires longer TradePlan since Toe, Cnfrm & Norm entries can be multiples of 10, not just 20
Step 1 now has 15 entry-size Conditions 10-150
Then 15 same-bar BrokerSM steps for each size
Then 15 eventFX+Confirm steps ... Cnfrm can be 140+10, which if Toe=20+10, Max Net=160
... Toe=10, 15 Cnfrm-Cond's (net=20-160); Toe=20, 14C's; Toe=30, 13C's
... Toe=40, 12C's; Toe=50, 11C's; Toe=60, 10C's; Toe=70, 9C's (15+14+13+12+11+10+9= 84C's)
... All 15 of those steps also have Strad-Ctl Cond-FX for that Step1 size
Then 15 simple no-Condn BrokerSM-refresh steps if Confirm fired: Toe+Cnfrm = 20-160 by 10's
Then 15 Strad-Ctl Cond-FullX steps for sizes 20-160 (these & prior 15-steps *only* if Cnfrm)
So, total# "SmartEntry" TP Steps= 1+15+15+15+15= 59; Cond's= 15+15+15+84+14+14= 157

NOTE: SmartEntry TP w/SmrtSiz DLL also works w/20%-inc cases, so it replaces ScaleEntry TP

So, NEW Signal-Output map:
Signal (0= no sig for this bar) ... SigNAX (BrkFX based on H|L, others on C)
S.PppIR: Decimal Ppp = Order's %BaseSize (always mult of ten); I&R for SmartSize (Cstm only)
Integer 9-5 = Long ToeOrFullEntry, ConfirmEntry, AddOn, CondEvent-PX|FX, SMkt-BrokerXit
Integer 0-4 = Short ToeOrFullEntry, ConfirmEntry, AddOn, CondEvent-PX|FX, SMkt-BrokerXit
("Do-nothing" bars after a Long FullX = 5.000; after a Short FullX = 4.999 (FL sorts to middle)

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

'DC.PKB: Direction & Status-Colors (neg = in buffer or band w/white line)
'Dir: (EqtyF Pass) L=9|8, 5=None, S=1|2 (2&8=ToeSize) ... EqtyF Block: L=7|6, S=3|4
'Clr: 9=NrmNtr,8=AlrtT,7=BrytT,6=Cnfrm,5=Add,4=NcrV,3=SamV,2=DcrV,1=AnyWrn,0=AnyEnd
'decimal PKB= Slope, Stack, BarV color-states (-3 > +3 output as 2 > 8)

Add+PartCG:
'+5= yellow= part-grab
'0= gainsboro= add
'-5= gold= part-cut
'Full Exit:
'+10= midnitblue= vote|strip => warns|strip? (wrncnt tricky, strip obvious)
'-10= black= warns|reverse => oppvote|reverse? (diff clarified by 3strips)
'+11= indigo= zero-size (dedicated since net-size invisible on ribn+3strips)
'-11= darkslategray= broker-exit|eqty-blk (diff obvious from broker-line)
'+12= slategray= full-grab
'-12= gray= full-cut
Top of the page Bottom of the page
Jump to page : 1 2 3 4 5
Now viewing page 5 [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.