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. 

1 Timothy 6:17 (ESV) ... As for the rich in this present age, charge them not to be haughty, not to set their hopes on the uncertainty of riches, but on God, who richly provides us with everything to enjoy.


Cumulative Volume Indicator DISCUSSION
Jump to page : 1 2 3 4
Now viewing page 4 [50 msgs/pg]
Jump to room :
JimDean
Posted 3/25/2019 1:12 PM (#9478 - in reply to #9477)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Pls note that recent snapshots show I changed the Fuzzy label to FuzzyAmp2AttenBEdiff, following Salim's recommendation, instead of the admittedly difficult to decipher wk/str or ez/tuf alternatives. Also I modified the Slope label, and the order of experts under the first Guru. Likee?

Re your mirror-flip responses to the Guru name ...

I like the conceptual approach, ie Careful2Hopeful (I think anything with "Nervous" is sort of counterproductive although very descriptive, in that it "insults" the user). Maybe "Careful2Cnfidnt"?
However ... that's totally obscure as to HOW it will impact the model ... what a trader considers "careful" and "confident" might be very different than what the vote & fuzzy and Add/PXit adjustments are actually going to do ... so the results on the chart might be very confusing for that trader.
So ... I'm leaning to the more "descriptive" approach. I suppose that a "Stradicator" is really so much more than just a "filter" that it is safe to use Trade in the name ... however "TradesBrief2Xtnd" might suggest that the Trade enters at a given bar, and that the slider simply controls the exit ... which is not at ALL true ... and again, if the user locks in conceptually to that idea, the changes in the output would confuse them. That's why (in addition to the Filter-use option) I've gravitated to the term "Wave" ... parallel to the MTV term "Zone". So, I'm settling closer to "GURU_WavsBrief2Xtnd", or even more simply "GURU_WavesSml2Larg".

snap attached ... further comments welcome!

(CVW Guru#2 params.png)



Attachments
Attachments CVW Guru#2 params.png (169KB - 0 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 3/25/2019 1:43 PM (#9479 - in reply to #9478)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
JimDean - 3/25/2019 11:12 AM

Pls note that recent snapshots show I changed the Fuzzy label to FuzzyAmp2AttenBEdiff, following Salim's recommendation, instead of the admittedly difficult to decipher wk/str or ez/tuf alternatives. Also I modified the Slope label, and the order of experts under the first Guru. Likee?


I still have a problem with the use of Amp2Atten. It does not clearly tell me what the slider is doing. Amp could be Amplitude (a wave kind of thing that a lot of people don't understand), as we are using waves, or amplify, (or amphibious, as we go under the waves ;-) Attent to a "non techie" could be attention, attentive, instead of attenuate (which is not common in everyday speech outside of electronics, etc). Both amplify or attenuate what? It doesn't indicate what a "Fuzzy" can do, so I do not know what it is amplifying or attenuating, and so it is not a favorite of mine. That's why I prefer some of the other options.

Re your mirror-flip responses to the Guru name ...

I like the conceptual approach, ie Careful2Hopeful (I think anything with "Nervous" is sort of counterproductive although very descriptive, in that it "insults" the user). Maybe "Careful2Cnfidnt"?
However ... that's totally obscure as to HOW it will impact the model ... what a trader considers "careful" and "confident" might be very different than what the vote & fuzzy and Add/PXit adjustments are actually going to do ... so the results on the chart might be very confusing for that trader.
So ... I'm leaning to the more "descriptive" approach.


This is in line with my comments above about Fuzzy. Fuzzy is a little fuzzy to the average person, I would think, so what it does needs to be descriptive in a way a non-technical person can understand.

So, I'm settling closer to "GURU_WavsBrief2Xtnd", or even more simply "GURU_WavesSml2Larg".


I like GURU_WavesSml2Larg. Conceptually clear.
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 1:55 PM (#9480 - in reply to #9479)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Ken:

I hear ya. I'm not sure there is any ambiguity to "Amp" but I suppose there is to "Atten" ... and someone who doesn't think in electrical terms might have trouble with both.

It appears that you didn't fold in the "BEdiff" part of the label re explaining WHAT is being Amp'd or Atten'd. Is BEdiff too obscure? The two param's just before it start with Bgn and End ... I thot that would be sufficient "clue".

So, I suppose that "FuzzyIncrs2SoftnVotEff" is also inadequate using this perspective, since "VotEff" is unclear, as is "Softn". How about "BEdif" as the suffix? &/or "Incrs2Dcrs" ... ie, "Incrs2DcrsBEdif" ... is that better or worse than "BtufEez2BezEtuf"? Do you think that "ez" and "tuf" are immediately understandable? SALIM ... did you "get it" immediately re what ez/tuf stood for (even if you didn't like the label)?

Two new choices for both of you to select between, please:
1. FuzVotBtufEez2BezEtuf
2. FuzVotIncrs2DcrsBEdif
Top of the page Bottom of the page
SalimHira
Posted 3/25/2019 2:00 PM (#9481 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 171
1002525
Location:
USA: MD, Columbia
Two new choices for both of you to select between, please:
1. FuzVotBtufEez2BezEtuf
2. FuzVotIncrs2DecrsBEdiff

Preference of #2 as majority would relate better, imho.
Top of the page Bottom of the page
KenWilsdon
Posted 3/25/2019 2:10 PM (#9482 - in reply to #9480)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
From Jim:

It appears that you didn't fold in the "BEdiff" part of the label re explaining WHAT is being Amp'd or Atten'd. Is BEdiff too obscure? The two param's just before it start with Bgn and End ... I thot that would be sufficient "clue".


It may be sufficient, but the other terms are more difficult.

So, I suppose that "FuzzyIncrs2SoftnVotEff" is also inadequate using this perspective, since "VotEff" is unclear, as is "Softn". How about "BEdif" as the suffix? &/or "Incrs2Dcrs" ... ie, "Incrs2DcrsBEdif" ... is that better or worse than "BtufEez2BezEtuf"? Do you think that "ez" and "tuf" are immediately understandable? SALIM ... did you "get it" immediately re what ez/tuf stood for (even if you didn't like the label)?

Two new choices for both of you to select between, please:
1. FuzVotBtufEez2BezEtuf
2. FuzVotIncrs2DcrsBEdif


I like 2. FuzVotIncrs2DcrsBEdif

From Salim:

Two new choices for both of you to select between, please:
1. FuzVotBtufEez2BezEtuf
2. FuzVotIncrs2DecrsBEdiff

Preference of #2 as majority would relate better, imho.


Great minds think alike. Similar to Jim's. Not sure if Jim can get in all the letters, but your #2 works as well.
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 2:15 PM (#9483 - in reply to #9482)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
FuzVotIncrs2DcrsBEdif it is, then ... I had modified the post after Salim saw it, to remove the "e" and the second "f" (to make it fit on the pane). My guess is that Salim's choice would be the same. I could have double "ff" but it's crowded and imho does not add any more clarity.

Thanks, guys, for this back and forth. Here is the "final" version of the labels, as a result ...

(CVW Guru#2 params.png)



Attachments
Attachments CVW Guru#2 params.png (152KB - 0 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 3/25/2019 3:15 PM (#9485 - in reply to #9459)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
It might be cool (if it doesn't confuse things) to somehow revise the Add & PXit "modifiers" to the BgnV and EndV ReqdVote#s, to follow the same "slider-sense" ... that is, Adds from "Mny2Fw" and PXits from "Fw2Mny".


Your plan seems sound, from my perspective.

Summary:
neg 1-5 duplicates the V pattern from pos 1-5
neg-slider Add & PXit patterns are more extreme
-5 & +5 together show "moderate" choices, for filters

Please comment ... refer back to prior post 9459 if necessary ... this is a CENTRAL part and finalization of a huge amount of discussion and work to be done - thanks


This new paradigm should work well.
Top of the page Bottom of the page
SalimHira
Posted 3/25/2019 4:35 PM (#9486 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 171
1002525
Location:
USA: MD, Columbia
"Please comment ... refer back to prior post 9459 if necessary ... this is a CENTRAL part and finalization of a huge amount of discussion and work to be done - thanks"

I concur with Ken of everything mentioned with the exception of below comment:

... "But maybe it would also be cool to vary the Add pattern so it also goes from many to few ... conceptually, high net-vote beginning provides greater "confidence" that the trade is not a "fluke" (tho it may occasionally have a bit more lag than a low-net-vote start) ..."

Are you adding this feature, still in planning stage, or am I missing something here ?
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 4:51 PM (#9487 - in reply to #9486)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Salim:

I tried texting and calling you with no response. Yes, you are definitely "missing something" ... the huge post 9459, which this more recent post tweaks a bit for the Few<>Many thing.

Please phone/text me and we can skype about it, to bring you up to speed. Your feedback (in detail) is extremely important, since Ken & I created the ideas originally, and you're the only 3rd party avail to review and comment on it objectively.

Thanks.
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 7:09 PM (#9489 - in reply to #9487)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
REVISED after skype with Salim ... Before I start on this topic ... note that I could have used "Few" instead of "Fw" in the Bgn & End V param labels, but I'd need to lower-case the "v" which I thot would be less readable ... I tend to use caps to separate abbreviated words. And in this case, the Vote aspect is pretty important. I did move "Ncrs2Dcrs" to the end of the label ... see updated snap in prior post.


Okaaay ... last step now before I do a *lot* of code-changing ...

Looking back to post #9459 at 9:52A on 3/23, and thinking about the newly relabelled and rethought BgnV and EndV params: BgnNetVotAddMny2Fw & EndOppVotPxtFw2Mny (with the Fuzzy label now being FuzzyAmp2AttenBEdiff and the Guru for those three being GURU_WavesSml2Larg) ...

It might be cool (if it doesn't confuse things) to somehow revise the Add & PXit "modifiers" to the BgnV and EndV ReqdVote#s, to follow the same "slider-sense" ... that is, Adds from "Mny2Fw" and PXits from "Fw2Mny".

In the paradigm from the earlier detailed post 9459, "many" Adds come with smaller percentages per add ... the "spec" defines both the size and the max#. Similarly, "many" PXits come with smaller percentages ... also, larger W counts (second# of "MW" specs) imply that in some cases, a trade will last longer since it takes more Warns to create a FullXit (presuming trade doesn't end due to Opp#Votes threshold, or Reversing Bright, or three blue Strips reasons).

Keep in mind that both BgnV and EndV param's have comprehensive manual overrides available in the Cstm version ... I previously noted that the new Fuzzy param's override is now PppBbEe (ie more control than before) ... I believe that the existing VRPpNL BgnV override and the EndV VMWPp override are fully sufficient, regardless of how this post might suggest changes to the sequence of the slider-selected Add and PX patterns.

======

The revised -5 to +5 EndOppVotPxtFw2Mny slider:
... "Fw2Mny" primarily speaks to the progression of the Opposite Votes from 2-4. But maybe it would also be cool to vary the PXit pattern so it also goes from few to many ...

earlier post's pattern:
+EndV: 1(4v34)30%, 2(3v23)40%, 3(3v34)30%, 4(2v23)40%, 5(2v34)30%
- EndV: 1(4v45)20%, 2(3v22)50%, 3(3v45)20%, 4(2v22)50%, 5(2v45)20%

reverse the vote sequence (same PXits):
+EndV: 1(2v34)30%, 2(2v23)40%, 3(3v34)30%, 4(3v23)40%, 5(4v34)30%
- EndV: 1(2v45)20%, 2(2v22)50%, 3(3v45)20%, 4(3v22)50%, 5(4v45)20%

finally, flipflop the MW%'s to represent "few-to-many" (Wrn=)PXits:
+EndV: 1(2v23)40%, 2(2v34)30%, 3(3v23)40%, 4(3v34)30%, 5(4v34)40%
- EndV: 1(2v22)50%, 2(2v45)20%, 3(3v22)50%, 4(3v45)20%, 5(4v23)30%
... the -5 and +5 together model the "few2many" for 4 votes (filterish), using the moderate 30/40%)
... negative 1-5 is "extreme" version of few2many ... 22)50 means 2warns, or 3meds, = FullXit

======

The revised -5 to +5 BgnNetVotAddMny2Fw slider:
... "Mny2Fw" primarily speaks to the progression of the Net Votes from 6-4. But maybe it would also be cool to vary the Add pattern so it also goes from many to few ... conceptually, high net-vote beginning provides greater "confidence" that the trade is not a "fluke" (tho it may occasionally have a bit more lag than a low-net-vote start) ...

earlier post's pattern:
+BgnV: 1(4vAf)50%1, 2(5vAt)40%2, 3(5vAf)50%1, 4(6vAt)40%2, 5(6vAf)50%1
- BgnV: 1(4vAn)0%0, 2(5vAx)30%3, 3(5vAn)0%0, 4(6vAx)30%3, 5(6vAn)0%0

reverse the vote sequence (same Adds):
+BgnV: 1(6vAf)50%1, 2(6vAt)40%2, 3(5vAf)50%1, 4(5vAt)40%2, 5(4vAf)50%1
- BgnV: 1(6vAn)0%0, 2(6vAx)30%3, 3(5vAn)0%0, 4(5vAx)30%3, 5(4vAn)0%0

finally, flipflop the AddMeth+%'s to show "many-to-few" *shares* potentially Added:
+BgnV: 1(6vAt)40%2, 2(6vAf)50%1, 3(5vAt)40%2, 4(5vAf)50%1, 5(4vAf)50%1
- BgnV: 1(6vAx)30%3, 2(6vAn)0%0, 3(5vAx)30%3, 4(5vAn)0%0, 5(4vAt)40%2
... the -5 and +5 together model the "many2few" for 4 votes (filterish), using the moderate 30/40%)
... negative 1-5 is "extreme" version omany2few ... An)0%0 means *no* Adds (but ToeIn poss)
... remember that if FuzVot input is negative, all Wave Begin entries follow the "ToeIn" paradigm

======

Summary:
neg 1-5 duplicates the V pattern from pos 1-5
neg-slider Add & PXit patterns are more extreme
-5 & +5 together show "moderate" choices, for filters

Please comment ... refer back to prior post 9459 if necessary ... this is a CENTRAL part and finalization of a huge amount of discussion and work to be done - thanks
Top of the page Bottom of the page
JimDean
Posted 3/28/2019 10:32 AM (#9490 - in reply to #9489)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Rearranged, Revised and Expanded ...

A. Planned standardized names: CVWeasy, CVWxprt(xprt-sliders), CVWcstm(typed overrides)
Easy has Master, CumMeth, two Gurus and two output controls; min# plots and returns
Xprt adds six Expert sliders (three per Guru); one extra plot and ~10 extra returns
Cstm adds manual overrides and one extra plot and ~4 extra returns (and maybe neg-sliders)

B. MAspd & MAtyp interactions - all completed now
1. Re-ordered MAtyp since Wma slower than Hulls: now HwHweHeWmEm
2. Pos-slider MAspd: Sma & Wma Pds =Ema and WmH =EmH (5 FMS triplets)
3. Neg-slider diff FMS to "equalize" types: S,W,E & Hw,He pds-pat's a bit diff
4. Adjusted Hull Pds: min-max EmH range 6-40 now 5-35; WmH 9-46 now 6-40
... other ranges unchanged from before: Ema 3-28, Sma 2-22, Wma 4-34
5. MAspd still allows FfMmSs override (Cstm) ... can be neg or pos
6. MAspd expert now before MAtyp; changed label of MASlope expert

C. CumV-Wndo control ... all completed now
1. Tightened to 80-120 range vs prior 60-140, after testing
2. Derived from MAperiods; pds vary with MAspd & MAtyp input (or -FfMmSs)
3. Tested: if all else locked, varying from 80-120 by 20's plots sensibly
4. WwwT override is avail (Cstm) as typed MAslope input (Www=Wndo Pds)

D. Filter & TradeTrak Specs - (just placeholder for now - no integration to calcs)
1. any version, but requires paid license-flag in Keys to utilize (sep for Filters & TradTrak?)
2. Filters: manual entry for either/both Guru (ie full ability to spec *two* filters)
... +FPPPPCG: F=up to 10 filters, PPPP= explicit pass-thru params (efficient but just 4)
... -FFPPCG: FF= up to 99 filters, PP= Master-slider or filter-shell mapping to specifics
3. Equity-Toggle logic (later, via opt license) via DCZSV PltRtn manual input
... D= trade-Dir's allowed SBL; affects are interactive (B <> S+L sometimes)
... C= impact on trades: Block Entry/FIlter &/or Force PX/FX &/or LateEntry
... Z= share-sizing as func of Risk &/or pctPrc for initial-base 100% value
... S= options re Equity-MA speed (limited due to special MA calcs)
... V= expert control of equity-curve voting rules (fuzzy, slope, stack)
4. can be part of Master spec eventually (likely txtfile basis since Filters are optional)
5. C allows <=10 filter-use variants ... C ignored by Filter, used by calling Strad

E. Resurrect additional Param-pane Section-headers, since CumWndo and WarnCnvrt gone
... Master, CumMeth, HEADER, TimeG+3X, HEADER, VoteG+3X, HEADER, B2calc+PltRtn

F. Master slider permit manual override (Xprt or Cstm) ... 7-digit spec for CumMth+Experts
... Allows SW list-based looping through specific starting patterns (other SW loop can override)
... Hardcoded arrays do not include manual Filter-specs ... but can be done w/sep SW list-loop
... All 7 sliders go from -5 to +5 (CumMeth also +/-6) ... -1 to -5 "map" to 6,7,8,9,0 for this use
For other Stradicators, try to arrange <=7 sliders that define pattern (big MTV > PVS change)

G. Reverse the "meaning direction" of the VoteGuru and its Experts, per prior posts.
... as a result, the VoteGuru "impacts" will parallel TimeGuru, when both move from 1-5
... modify Fuzzy, BgnV & EndV rules per earlier posts
... new exit rule: Entry/Adds/PXits => "+/-votes(shares)" that if <=0, can *end* a Wave
... Negative Fuzzy (any ver) TURNS OFF %size calc's and new exit rule above
... VoteGuru -5>+5 maps to same values for all its experts

H. Miscellaneous
... update & rearrange Help Panels ... generic expanded info for GuruV & its 3 experts

I. Any time Return is negative (except for CumV), it means "buffer prep" is incomplete
... buffer is ~40-bar "post-warmup" zone where a navy bar then full trade w/end is sought
... if full-trade-end occurs b4 end of buffer, then entire spec'd output range is stable, if not

J. New "-1" Signals Return output (all versions): Entry, Add, PXit, FullX, NoTrd (Short/Long)
... S.Zzz where Zzz= pct of 100%-nominal-entry shares for this bar's order; S= signal 0-9:
... ... Short/Bear 1-4 & Long/Bull 6-9 @ Ntr,Add,PX,FX; 5= NoTrd; 0= warmup

K. Implement Plot output choices to 6,8,10 ... dots on PrcPane optional
... Entry, Add, PXit(Wrn), FXit dots diff colors; Long: dots below candle; Shorts= dots above

L. Normalized Equity per-trade calc's w/&w/o Adds & PXits, w/histo plot & return output
Normalized Cumulative Equity totals w/&w/o Adds & PXits sizing, w/curve plot & return output
... possibly, Equity outputs only avail from extra one-time license fee
Debug-output efficient Equity-optimization studies (by JD), to find ideal Master patterns
... offers ability to do custom for-a-fee studies, distributed to clients as text files
... also offers ability to sell regular updates to "ideal pattern" files to clients if desired
Slider-spec time-window for Cum-Equity-calc's (opt FwdWtg) => DynamicScan Sym lists
... B2calc input LLLWWWW: LLL=lastbarB4hre, WWWW=calc wndo width
... Neg B2calc > FwdWtd Equity calcs; ForNext back via FXbar-ptrs, @LastBar
New Filter-spec options w/in Strad (typed Gurus) allow simultaneous interactive simulation
Equity-Optimization procedures: find Master Pat's, and ~DynScan Sym's
... ~DynScan uses CVW as Filter, to block Sym Entry that bar
... Find best Master-patterns (req's source coded):
... ... Column in FL; Details out to DebugPane incl patn & Sym
... ... Each Edit of FL col changes settings & recalcs all Syms
... ... ... Preplan using Master arrays to prevent mistakes
... ... Paste all Debug into Excel; filter+vote for best pat's
... ... Save patterns into CSV file; #####-Master if licensed
... ... ... Allows periodic update of file to be purchased
... ... ... Allows gen/sale of custom files (diff constraints)
... ... ... Use 1st-2 digs to select between diff files
... Later, use file for *all* Master mapping (replace coded arrays)
... Several Trd-Stats for DynOScan Sym-selection: #Trds, HitRate, PPT, MDD, ADD, Calmar

M. New Equity Plot for all versions: 2 NetEquity Curves; 0-Band & Wallp for TradeEquity
... color of center Band in red-to-green ATR increments: Trade progress with Add/PXit sizing
... color of wallpaper in dark blue-to-purple ATR increm: Trade progress w/o Add/PXit sizing
... color NetE curves for rising/falling/same (fuzz= f(ATR)): Curves w/ & w/o Add/PXit sizing
... thin vertical lime/forestgrn/dkorng/magenta lines identify Entry/Add/Pxit/FullX bars
... avail for *all* versions as final plot option: Easy=1,2,E Xprt=1,2,3,E Cstm= 1,2,3,4,E
... Ntry, Adds, PXits, FullX appear as PrcPane dots & EqtyPane verticals and in "signal" Return

N. New Equity Return CCC.TTTT show *normalized* Profit vs Risk, for multi-sym FL sorting
... CCC= CurTrd; TTTT= Total: Prof|Loss w/ Adds|PXits effect, unless VoteGuru is neg
... ... CCC: 123 => 2.3 *ATR/10 prof vs NtryC; 85 => 1.5 *ATR/10 loss; ATR => Risk (fxd @Ntry)
... ... TTTT: 1234 => 234 *ATR/10 prof during trades in spec'd Lkbk, ATR reset @new Trade

O. (Later) implement "TradTrak" fore/background Equity-Toggle
... control via PltRtn manual input DCZSV (see above)
... will open up another Plot pane and additional Return values

P. Approximate early planning re marketing:
** Rental via PP auto-draft for Both DLL & Sub = $95/mo
** Annual via PP invoice for Subscription $195 (DLL lump)
** Lifetime: Lump-sum for DLL + $975 for Subscription
** Extra for Equity features via license file toggle: $295
** NtrXit shells (in DLL) = $195-295 ... write/read Param txt file
** TradTrak optional control (later) = $495-$695
Top of the page Bottom of the page
JimDean
Posted 3/28/2019 3:02 PM (#9491 - in reply to #9490)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Simple Question for y'all ...

Buried in the notes from the long previous post are two "override" rules which allow the TimeGuru and VoteGuru to take on negative values ...

Negative TimeGuru (any ver) locks WndoPds (& FuzPds) to be 100
... this simplifies the internal models by removing the automated variance of the MA calc that is a few layers underneath. Both the CumV WndoPds and the Fuzzy MApds are normally a derivative-multiple of the Slow MA pds ... the SloPds are a function of MA speed and MA type settings. However, that's an *arbitrary* (and messy to document) connection ... I could have just as well locked the Wndo & Fuzz periods to an arbitrary value without compromising the calc-logic ... though it does alter the results. So, allowing for a "locked" mode via the Guru provides the user of ANY VERSION (including Easy) an alternate set of calc's. The value of 100 is halfway through the "normal" range.
... I'm not really certain whether allowing these background periods to vary is a good idea or not ... so another benefit of this option is to be able to test it exhaustively (later). If it turns out that locking them is consistently *better* than allowing them to vary, I'll modify the rule so that the negative Guru value => variable and positive => locked. If it turns out that one or the other is pretty much always worse (unlikely), then I'll eliminate the bad option and the negative override entirely.

Negative VoteGuru (any ver) TURNS OFF EFFECTS of Adds & PXits
... It's possible (for Xprt & Cstm) to "turn off" Adds using the "An" option ... but there's no slider-based method for "turning off" PXits ... unless I steal one of the four PX sizing/count options which I would rather not do, since their "range" is reasonable.
... If this toggle is OFF, then the dots would still appear, but the new exit-rule that forces a Wave to end early if the shares hit zero would be deactivated, and the Adds/PXits would not impact the Equity calc outputs.
... It seems logical to me that a user may want to "clean up" the model with a simple toggle, to remove both of these special intra-Trade variants ... especially since for the time being, a pure-automated-mechanical TradePlan cannot support them. This is "just as needed" for Easy as for the other versions.

If this toggle is OFF, then the PrcPane dots would still appear based on the BgnV & EndV sliders, but the new exit-rule that forces a Wave to end early ***if the sum of the shares hit zero*** would be deactivated, and the Adds/PXits #shares variants would not impact the intra-Trade Equity calc outputs.
HOWEVER ...
The BgnV & EndV rules re Med>Wrn(PXit) and Wrn>FullX *will remain* live, when the VoteGuru is negative. Those rules are reflected in the Band output, and beneficially assist in ending a trade-wave at an "improved" point, when things stop going well. It's possible to turn off the Add effects (Xprt or Cstm) by setting the BgnV slider to an "An" option, and to "minimize" the PXit effects by setting the EndV slider to one of the "45" options.

QUESTION:
Presuming these are available, should I make the Guru sliders -5 to +5 (all versions), rather than forcing the user to manually type the value if it's negative?


... note ... ALL other manually typed overrides require the Cstm version ... also note that the Xprt version provides sliders that go from negative to positive for nearly all other param's.
Top of the page Bottom of the page
SalimHira
Posted 3/28/2019 3:11 PM (#9492 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 171
1002525
Location:
USA: MD, Columbia
QUESTION:
Presuming these are available, should I make the Guru sliders -5 to +5 (all versions), rather than forcing the user to manually type the value if it's negative?

My first reaction was YES... after re-reading, its still not budged - so I suppose, I lock-in YES.
Top of the page Bottom of the page
KenWilsdon
Posted 3/28/2019 3:24 PM (#9493 - in reply to #9492)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
QUESTION:
Presuming these are available, should I make the Guru sliders -5 to +5 (all versions), rather than forcing the user to manually type the value if it's negative?

I vote yes as well. Having it as a slider is better.
Top of the page Bottom of the page
JimDean
Posted 3/28/2019 3:36 PM (#9494 - in reply to #9493)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Thanks for the quick responses.

After you responded, I realized that clarification might be needed re the VoteGuru Add/PXit "lock out":

... If this toggle is OFF, then the PrcPane dots would still appear based on the BgnV & EndV sliders, but the new exit-rule that forces a Wave to end early ***if the sum of the shares hit zero*** would be deactivated, and the Adds/PXits #shares variants would not impact the intra-Trade Equity calc outputs.

HOWEVER ...

... the BgnV & EndV rules re Med>Wrn(PXit) and Wrn>FullX *will remain* live, when the VoteGuru is negative. Those rules are reflected in the Band output, and beneficially assist in ending a trade-wave at an "improved" point, when things stop going well. It's possible to turn off the Add effects (Xprt or Cstm) by setting the BgnV slider to an "An" option, and to "minimize" the PXit effects by setting the EndV slider to one of the "45" options.

If this info changes your response, please let me know.
Top of the page Bottom of the page
JimDean
Posted 3/29/2019 9:37 AM (#9495 - in reply to #9494)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
As mentioned previously, I'm considering elimination of Alerts, since they currently aren't "doing" anything. If I do, I can reclaim two "color-state" Return-values and use them for the "intermediate" wave-color (same-barvote-as-before).

Before I do that, I'm testing an alternative definition of Alerts ... instead of the threshold-vote for an Alert being half of the BgnVote (ie BgnV=5 => AlrtV=2), I'm testing how things look with AlrtV=BgnV-1(ie just one vote shy of a "bright beginning".

Initial checks seem a lot better than the overview tests that Ken and I did earlier. There are still a number of cases where alerts fire and there's no follow-through with a bright color, *but* it appears that in many/most of those cases, it's not a ridiculous point to enter with a "ToeIn".

If I go this route, then the trick is to determine an appropriate *full exit* rule, if a "true wave" (ie green or red) has not yet begun. In many of those cases where there is no follow-thru, it *appears* that a decent exit might be when the *net* vote drops two below the AlertV ... ie net= BgnV-3. Sometimes there's an Alert then Alert-1 then Alert again (ie a small pullback) ... this would seem to solve the problem.

There are no PXits or Adds within an Alert Zone. The ToeIn percent is used (if ToeIn is toggled on), and if the net vote drops below Alert-2, then a full exit occurs. If a bright bar "fulfills the Alert" before that happens, the shares increase to 100%, on that first bright bar. ToeIn percentages currently vary between 20%-50%, depending on the BgnV slider's An/Af/At/Ax setting ... if this Alert scenario works out well, I'm thinking of maybe pushing those percentages up to 30-60% or maybe even 40%-70%. What ToeIn range do you think is best?

This would replace the prior rule, where a ToeIn occurs on the first bright, and followthru to 100% if the very next bar is also bright.

Another idea: if ToeIn is turned on, then if an initial Bright is hit *without* a previously-active Alert in force, then that initial Bright maybe should be 100%-Toe%, rather than a flat 100% ... thus maintaining the "cautious approach" of the ToeIn concept. In that situation, a second bright bar would not do anything, but there would be potential for Adds based on their normal rules. Do you prefer this alternative 100%-Toe% for initial-non-Toed-bright approach?

For BgnV=6, that means ToeIn=5 and ToeXit=3
For BgnV=5, that means ToeIn=4 and ToeXit=2
For BgnV=4, that means ToeIn=3 and ToeXit=1
... override cases:
For BgnV=7, that means ToeIn=6 and ToeXit=5 ... maybe make ToeXit 4, since it's hard to sustain 7
For BgnV=3, that means ToeIn=2 and ToeXit=0
For BgnV=2 or 1, that means ToeXit < 0 ... not logical so in that case, ToeIns should be disallowed

The attached charts mainly use default settings (BgnV=5) ... I've modified the code to turn on the Alert if it hits BgnV-1, and to *leave* that color on until it drops to <= BgnV-3 = AlertV-2

The two stacked instances use Fuzz=2 and Fuzz=4 (Fuzz has been modified to map to tighter range than before). I'm showing the Band + 3-strips output, so that you can (if you'd like) discern where the Vote is dropping by just one, allowing the Alert mode to be sustained.

To be clear: when the Band is blue/purple, a bull/bear ToeIn is in force until it turns navy or a bright color. No changes have been made to affect other colors of the Bands.
Do you think I should use this Alert-ToeIn with Alert=BgnV-1 and AlertXit=BgnV-3, *if* ToeIn is activated by the user?

Currently, ToeIn requires Fuzz input to be negative ... which only is avail with Xprt|Cstm. If I implement this approach, should the *default* be for ToeIn mode to be toggled ON?

Final question: If this rule is enacted, should blue/purple bars be considered as part of an active bull/bear "wave" for output and other logic purposes?
(note: if this is implemented, I'd turn off the blue/purple if ToeIn is not active)


(Alerts (Bgn5; Fuz2,4) SPY.png)



(Alerts (Bgn5; Fuz2,4) PCAR.png)



(Alerts (Bgn5; Fuz2,4) NCLH.png)



(Alerts (Bgn5; Fuz2,4) CTAS.png)



(Alerts (Bgn5; Fuz2,4) WBA.png)



(Alerts (Bgn5; Fuz2,4) LILAK.png)



(Alerts (Bgn5; Fuz2,4) DIA.png)



(Alerts (Bgn5; Fuz2,4) ALXN.png)



(Alerts (Bgn5; Fuz2,4) ADP.png)



Attachments
Attachments Alerts (Bgn5; Fuz2,4) SPY.png (23KB - 0 downloads)
Attachments Alerts (Bgn5; Fuz2,4) PCAR.png (24KB - 0 downloads)
Attachments Alerts (Bgn5; Fuz2,4) NCLH.png (25KB - 0 downloads)
Attachments Alerts (Bgn5; Fuz2,4) CTAS.png (22KB - 0 downloads)
Attachments Alerts (Bgn5; Fuz2,4) WBA.png (24KB - 0 downloads)
Attachments Alerts (Bgn5; Fuz2,4) LILAK.png (26KB - 0 downloads)
Attachments Alerts (Bgn5; Fuz2,4) DIA.png (26KB - 0 downloads)
Attachments Alerts (Bgn5; Fuz2,4) ALXN.png (25KB - 0 downloads)
Attachments Alerts (Bgn5; Fuz2,4) ADP.png (25KB - 0 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 3/29/2019 10:06 AM (#9496 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi Jim,

This does look like a valuable addition. Toe-in is getting into trades at least 1 bar early, and even those trades which exit before a bright seem to do OK visually (break-even or slightly better). Of course, there are times when that doesn't work out, but it looks like a good addition to me. I vote to add it in.

Thanks ... four more questions in the post needing answers if possible.
Top of the page Bottom of the page
SalimHira
Posted 3/29/2019 10:33 AM (#9498 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 171
1002525
Location:
USA: MD, Columbia
I'm thinking of maybe pushing those percentages up to 30-60% or maybe even 40%-70%. What ToeIn range do you think is best?

>>I feel a higher % should it be a continuation, and high confidence level is established... since, if not correct, it'll be exited out early in any case.<<
Unclear answer ... I'll presume you mean that a higher range than 20-50 is likely useful.

In that situation, a second bright bar would not do anything, but there would be potential for Adds based on their normal rules. Do you prefer this alternative 100%-Toe% for initial-non-Toed-bright approach?

>>Yes, I believe so - as it makes sense to me conceptually.<<

Do you think I should use this Alert-ToeIn with Alert=BgnV-1 and AlertXit=BgnV-3, *if* ToeIn is activated by the user?

>>Yes, if it makes sense to do so.<<

Final question: If this rule is enacted, should blue/purple bars be considered as part of an active bull/bear "wave" for output and other logic purposes?
(note: if this is implemented, I'd turn off the blue/purple if ToeIn is not active)

>>I am not clear on this.<<
A bull/bear "wave" in its simplest form is a FILTER region where long/short Entries (from whatever System creates them) are allowed to pass. Since you "like" earliest possible entries, I'll assume your answer is "yes".
Top of the page Bottom of the page
KenWilsdon
Posted 3/29/2019 11:31 AM (#9501 - in reply to #9495)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
There are no PXits or Adds within an Alert Zone. The ToeIn percent is used (if ToeIn is toggled on), and if the net vote drops below Alert-2, then a full exit occurs. If a bright bar "fulfills the Alert" before that happens, the shares increase to 100%, on that first bright bar. ToeIn percentages currently vary between 20%-50%, depending on the BgnV slider's An/Af/At/Ax setting ... if this Alert scenario works out well, I'm thinking of maybe pushing those percentages up to 30-60% or maybe even 40%-70%. What ToeIn range do you think is best?

I think 30-60%. 70% is really a big toe, and 20% is a baby toe.
I agree. Will change accordingly.

Another idea: if ToeIn is turned on, then if an initial Bright is hit *without* a previously-active Alert in force, then that initial Bright maybe should be 100%-Toe%, rather than a flat 100% ... thus maintaining the "cautious approach" of the ToeIn concept. In that situation, a second bright bar would not do anything, but there would be potential for Adds based on their normal rules. Do you prefer this alternative 100%-Toe% for initial-non-Toed-bright approach?


No, I prefer the first option, myself. Toe in, in my mind, is for when a signal is not clear. A bright is a clear signal. No need for Toe. as well, 100%-Toe% would make this a smaller trade than a regular toe, if the percent toe is 60 or 70%. That would mean this toe is 30 or 40%, on a good signal. I don't like that.
Hmm. If the range is changed to 30-60% per your recommendation above, the only time that the 100-Toe would be less than 50% would be if the BgnV was negative, using one of the "Ax" options. And, you didn't mention the fact that Adds still could push the size up further. My concern is large entries that are *late* ... the Alerts seem to provide earlier, more profitable trades, quite often. So, I'm still mulling this over.
HOW ABOUT THIS: if Toe mode is active, on the first bright bar that does not immediately follow an Alert zone, use ToeIn Pct, and then follow with the 100-Toe% if the next bar after that is also bright? (ie the original rule)


To be clear: when the Band is blue/purple, a bull/bear ToeIn is in force until it turns navy or a bright color. No changes have been made to affect other colors of the Bands.
Do you think I should use this Alert-ToeIn with Alert=BgnV-1 and AlertXit=BgnV-3, *if* ToeIn is activated by the user?

Yes, that is fine.

Currently, ToeIn requires Fuzz input to be negative ... which only is avail with Xprt|Cstm. If I implement this approach, should the *default* be for ToeIn mode to be toggled ON?

Most "regular" users probably just want to buy at one point and sell at another. Toe-in requires a multi-step trade plan, which a lot of people may be unfamiliar with. So far, the shells for implementing multiple adds and Pxits are not available, nor is the Spreadsheet creating multiple addins and Pxits within trade plans in place. If they were, then I would say yes, do that. But since they are not, I would say, no, not even for the Xprt or Cstm. When everything is in place, this would be great as a default, but not until then.
People that aren't using scaling can always turn off the ToeIn option. Or they can turn it on and just trade with Entry/Exit. Note: it would be *easy* to create a TradePlan Condition that made the Initial Entry small vs large, based on a Return value from this routine. And a followup increase on the next bar, if it is bright, is also fairly easy.

Final question: If this rule is enacted, should blue/purple bars be considered as part of an active bull/bear "wave" for output and other logic purposes?
(note: if this is implemented, I'd turn off the blue/purple if ToeIn is not active)

Yes, This is fine.
Top of the page Bottom of the page
JimDean
Posted 3/29/2019 12:30 PM (#9502 - in reply to #9501)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
I should clarify about the TradePlan limitations. The primary barriers are:

1. If >=1 sequential TP steps immediately after the Entry step have Conditions that *could* be met by the Entry bar, then any such steps will execute ... that's why Step-2 Stops are can initiate on the Entry bar. However, if the Condition for Step2 *cannot* be met on the bar that satisfies Step1, then Step2 will wait for a later bar. That's what you need to have happen, to handle the various Toe+Followup cases discussed earlier ... the Return value would be *different* for an Alert-Toe than for a Bright-Complete ... and *different* for a Navy-Exit. So, the Toe options discussed above *are* viable without needing a long fancy TP or special "tracking" text file.

2. Adds & PXits that occur in a dynamic pattern unrelated to specific, locked-in Bar#'s since Entry, require very long, byzantine TP structure ... and other things. So, Add+PXit combo's are nogo for now.

3. HOWEVER, if *only* PXits (or only Adds) are active, the native OT TradePlan engine probably CAN handle it, without an external text file to track bar-progress. With or without the Toe/Full approach ... here is a snippet to explain ...

... toe &/or full entry steps ...
Step 3 ... PXit if return says to ... go to step 4
Step 4 ... wait till Return from Prior bar was a PXit , and Cur bar isn't ... go to step 5
Step 5 ... PXit if return says to ... go to step 6
Step 6 ... wait till Return from Prior bar was a PXit, and Cur bar isn't ... go to step 7 ...

That structure also would work for a series of Adds. But *not* for a series of Adds and PXits that can occur in an unknown sequence. I could set up the Stradicator to provide a Return value that specifically flags the "Prior=X and Cur=Y" case, or it could be done in OScript.
Top of the page Bottom of the page
JimDean
Posted 3/29/2019 6:05 PM (#9503 - in reply to #9502)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Yet another looong skype with Ken to discuss how the generic dynamic-scaling TP approach would mesh well with the standardized VoteGuru+3expert paradigm, across all TT Stradicators, without needing special DLL's that wrote text files to track things. Result of that discussion is "hoorah ... can be done with great versatility".

Then we spent a long time re-re-re-re-rehashing the -5>+5 BgnV and EndV sliders, as to what they cause the Adds and PXits to be ... also in conjunction with full -5>+5 Guru and Fuzzy sliders. The result is very flexible, and will pair nicely with both the fancy dynamic-scaling TP, or a simple one with no Adds/PXits (w/or w/o ToeIn).

The following notes are copies of what I wrote during the Skype, preserved here for us to review. Salim, I don't expect that you will "follow" this so don't feel bad ;~)

===========

Add Req's: Wrn >= next Add/2, then ... Bright (>= BgnV?); also, Add%'s decrement sequentially
... 20% bins for Adds to keep TP shorter; 10% bins for PXits to honor "half of Add" rules (no 10%'s)

Guru pos=Toe, neg=Full; neg Fuz= no Add/PXit %'s (just counts to end); Fuz%s same for + or -

... Toe: +1>+5= 4t6c6v%60, 4t4c6v%80, 4t4c5v%60, 2t4c5v%80, 2t4c4v%40
... Full: -1>-5 = 100n6v%0, 80n6v%40, 80n5v%0, 60n5v%40, 60n4v%0
Entry size= 120(6t6c),100(4t6c),80(4t4c),60(2t4c),40(2t2c) from 7-3 act #votes on 1st grn/red bar

... PXit: +1>+5= 2v33%30, 2v32%40, 3v43%30, 3v42%40, 4v54%20
... PXit: -1>-5 = 2v32%40, 2v34%20, 3v43%30, 3v44%20, 4v54%20
PXit size could (later) be a function of SmartSize or Market Dirn, etc

Alert=Toe-20 (>0), if no navy b4/Bright, then 1st Bright Complete+20;
Else initially navy then 1stbar Bright=Toe & 2ndbarBright=Complete
Maybe turn off Alert blue/purple on Band & in Return if Full selected

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

A dynamic series of Adds and PXits, following an Entry that's either ToeIn+Completion, or Full, are all do-able, as long as a Stradicator is driving them. However, this will not solve the "generic" case that uses SL, etc orders with non-Stradicator TP's. It will require OLang-based Stop-conditions, which themselves are "calling" a background Strad that is tracking the entire trade, and *knows the trade's history*.

The core of the solution is simplicity itself. Think about the "tiered" structure of our Excel-gen'd TP ... it has a "path" it follows for each possible sequence of Adds, and sub-paths for each PXit embedded in those main paths.

The essential thing to note is that in any main path, the TP "knows" how many Adds have previously taken place. And, during any given Add-path, it "knows" how many PXits have taken place. Here's the key: the Stradicator "knows" the *same* information! And, if programmed to do it (easy), the Strad can "tag" any Signal for an Add or a PXit as being "applicable" *only* for a particular TP Condition-rule in a particular Step.

This will automatically prevent the native TP's "ability" to process multiple Steps on a single bar from creating problems by "stacking up" multiple Adds or PXits based on repeated processing of the very same bar in subsequent steps ... BECAUSE ... the conditions in those subsequent steps will be looking for a different "sequence-tag", which the Strad will not produce till some later bar (if at all).

The key is for the Strad to have the same PXit% and Add% options that the TP does ... in managed increments (such as the 10%-multiples we are now using). There would be different TP's for the various permutations of Add% & PXit% selections ... we currently have An, Af, At, Ax = 4 Add types, times 23, 34, 22, 45 = 4 PXit types = 16 permutations ... not bad at all ... and only 4 permutations if just the positive-slider settings are used.

The Toe-only vs Toe+Finish vs Full Entry options, as described in posts, all would occur BEFORE any of the Adds or PXits ... therefore those options are built into every one of the 16 variants (not requiring further permutations).

Furthermore ... unless I'm missing something ... the same "tagged Condition" approach can be used to scale the initial Entry size as a function of Market state &/or Volat vs Close ratio ... ie multiple variants of the same entry order in a given Step ... with the tagged condition return-value preventing more than one from firing. Again, if those increments match the 10%-paradigm, the TP structures we've worked with already will handle it just fine.
Top of the page Bottom of the page
JimDean
Posted 3/30/2019 10:28 AM (#9504 - in reply to #9503)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
I'm carefully going over the plans from yesterday re BgnV, EndV and Fuzz inputs. I'll post this info in stages so that you can carefully review and comment on each without being overwhelmed ;~)

Since this set of four param's (VoteGuru plus its three experts) will be a *standardized* Voting, Signals & Trading Paradigm for Stradicators, it's important that I establish the nomenclature, logic-rules, and actual code to be as easily "portable" as I can, applicable to any Stradicator.

I'm assuming that all Strad's will have their own unique internal means of creating "votes" (that's not the "portable" part). I want to standardize the plot "Band" if possible, with colors always meaning the same thing regardless of the Strad ... distinguishing Bullish, Bearish, and Neutral states (aka waves/trades).
Colors: Neutral will include FullX bars (black|navy|indigo to indicate "cause"), no-action Navy bars, and Bull/Bear=blue/blueviolet Alert bars. Bear/Bull bars will be shades of red/green: Bright= NetV > PrvBarNetV, Medium= NetV < PrvBarNetV, Dark= Warn(aka PXit) or grayish= same NetV as prior bar in wave. Bull/Bear Dark=Warn bars will distinguish whether that PXit is due to #opposite Votes (darkgreen/firebrick), or the result of the "Medium-count" method (darkolivegreen/darkred).

In order for the TradeTight Dynamic TradePlan Condition-Rules to work (or for a conventional TP), it's essential that Stradicators all provide the same kind of "Signal" value as one of its Return options. The Signal output needs to provide clear "action" distinctions, separately for Long or Short trades, of: AlertEntry, CompleteEntry, AddOn, PartXit, FullXit, and of course "do-nothing" Neutral. Each Signal will have a decimal-component that specifies the Size-Percent for its action. Do-nothing-neutral mode is flagged via a special size-percent decimal, with the integer based on the FullXit value (Long or Short) from the end of the prior trade.
So, the standardized Signal-Return will be:
Integer 0-4 = Long ToeOrFullEntry, ConfirmEntry, AddOn, PartXit, FullXit
Integer 9-5 = Short ToeOrFullEntry, ConfirmEntry, AddOn, PartXit, FullXit
For all "action" cases, a three-digit decimal indicates %nominal Shares to use for the related Order.
"Do-nothing" bars after a Long FullX = 4.999; after a Short FullX = 5.000 (max% in Trd <~ 300%)
TP Step 1 handles "ToeOrFullEntry" orders; TP Step 3 handles the followup Confirm orders.
(T+C mode may not have a C followup ... if Alerts then Navy bar, the Alert mode simply exits)

This mapping allows an Ascending FL column sorting to float Long trades to the top, dealing with Entry/Add Buy-orders first then PXit/FullX Sell-orders, with do-nothing bars that follow a prior Long sorted last in the "LongGroup" as 4.999. A Descending FL sort floats Short trades to the top, dealing with Entry/Add Sell-orders first then PXit/FullX Cover-orders, with do-nothing bars that follow a prior Short sorted last in that group, as 5.000 (followed by any 4.999 bars which are also do-nothing).

My convention is for any Return values that have a bearing on "voting" to reserve the "-" to flag bars that are prior to the completion of the first historical trade ... normally this will occur during a warmup-buffer, but in the uncommon case when the first trade isn't complete within the buffer, the Return values will be negative to caution the user that those values *could* be different, if more warmup had been done. This case also plots a thin white line through the Band. I'm designing the code to minimize these situations, but they could occur. Signals that *do* occur in that mode *could* be used for trading without issue, other than the fact that backtests with different #bars loaded *might* show different signals for the trade-status on those particular bars.

Let me know whether you fully understand the Signals output paradigm from the above explanation ... if not, ask specific questions so I can clarify (or revise the paradigm).

I've tweaked the Parameter names, so that abbreviations in explanations are simple and un-ambiguous: GuruV, BgnV, EndV, VFuz; I created a new Fuzz name since even *I* couldn't remember, two days later, what the "1-5 slider effect" of earlier name "FuzVotBEdifNcrs2Dcrs" actually *did*). Here are the new names (snapshot shows them in the Param pane):
GuruV_WavesSml2Lrg, BgnVotNetAddMny2Fw, EndVotOppPxtFw2Mny, VFuzzBtufEez2BezEtuf

Are these four names good, from your perspective? Do they remind you of what the slider does and how its 1-5 slider affects things?

(Vote Guru+Xprts.png)



Attachments
Attachments Vote Guru+Xprts.png (64KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 3/30/2019 1:00 PM (#9510 - in reply to #9504)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Thanks for your feedback on the prior post ... I've updated it and cleared off the responses. Moving forward now ...

The BgnV, EndV & VFuz parameters have been radically revised (again), in line with the plans to standardize them for all Stradicators, and to link them to a viable TradeTight Dynamic-Scaling TradePlan (to be released later, likely next fall/winter after several Stradicators that can use it have been released).

Although my plan (currently) is to limit the number of popup Help Panels, and rely mainly on video-training and PDF Help Manuals, I am planning to expand the popup which provides basic explanations for each parameter, to *succinctly* touch on all the impacts of a given parameter ... that is, when its slider is moved, what core-logic impacts does it have. In the case of Guru's, this will be a generalized explanation ... but for Expert param's, there need to be a lot of details in some cases.

This post addresses the BgnV slider. There are quite a few "expert" impacts linked to this ... I want to provide a *very concise* description of them, such that if you've previously heard a video explanation (maybe a while back). The popup will remind you of the key factors, and will list any internal numbers or rules which are pretty directly modified by changing the slider. So, with that in mind, here is the new BgnV popup explanation (I'm typing it in so you can copy if needed, but also showing how it "fits" on the popup panel.)

BgnVotNetAddMny2Fw -5>+5: neg&pos ReqV= 6,6,5,5,4; -FullNtr, +ToeIn.
... AddSz%(VFuz>0): -1>-5= off,40,off,40,off; +1>+5= 60,80,60,80,60.
... @NewAdd= 20%smaller; @Add on Bright after SPXitSz >= NxtAddSz/2.
... neg= NtrFull% @7-3netV: 120,100,80,60,40; pos= Toe%+Cnfrm% for
... @7-3reqV= 40+80,40+60,20+60,20+40,20+20; two Toe+Cnfrm types:
... Navy+Alert+LaterBright or Navy+1stBarBright+2ndBarV>=1stBarNetV.
... *CSTMver* TypedIn VFCA: V=BgnV; FCA=Size as #20%s for F=FullNtry,
... C=Cnfrm(Toe=F-C), A=InitAdd; '9'=>180%,'1'=20%; -/+Inp= Full/T&C.

Note: in the third line, "SPXitSz": the "S" is a greek Sigma, meaning "Sum of" ... see snapshot. Also: the final two lines describe the optional override available only in the Cstm version.

Please respond with *specific* questions re anything you don't understand ... show the line(s) in question and let me know what was confusing. Thanks!

(BgnV PopUp Help.png)



Attachments
Attachments BgnV PopUp Help.png (135KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 3/30/2019 1:45 PM (#9513 - in reply to #9510)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Thanks for your comments, Ken. I deleted them after I modified the post with an updated snapshot, and an explanation of the "S" being a sigma. Also I changed some semi's to periods which might help a little. Salim is unavail for a few hours, so when you read this, Salim, please do separate-post responses to each of my individual posts that sequentially address each parameter. Also, please note that:
I don't want suggestions that "radically reformat" things ... vertical space is at a premium, as is the horizontal width. It's an iterative pain to tweak line formats. The popup Help *will* be terse & concise in this manner ... however punctuation, such as commas vs semicolons vs periods *does* matter. What I really need is to know whether, after a very careful reading of the text, it's adequately clear. Where it's not, please ask specific questions about some snippet. Thanks!


OK, moving on now to the EndV parameter. It's about the same complexity re the variety of things that changing the slider does behind the scenes, but there are significant differences. I needed to provide the Med2Wrn & Wrn2FX values, before I used them in explanations ... but hopefully if you read the entire thing, they will make sense.

Some of the "reasons" for PXits and FullXs may vary a little for different Stradicators, but I'm hoping that the explanation as it stands will be representative enough to work across the board. Here is the text ... see the attached snapshot for "how it fits". Once again, note that greek sigma "sum of" symbol reprints in forum as an "S", in the right side of the last line. Also: the final two lines describe the optional override available only in the Cstm version.

EndVotOppPxtFw2Mny -5>+5: neg&pos OppV= 2,2,3,3,4; neg=faster FullXs.
... PXitFxdSz%(VFuz>0): -1>-5=40,30,30,20,20; +1>+5=30,40,30,40,30.
... Med2Wrn & Wrn2FX Thrsh: neg=32,42,33,43,44; pos=33,43,34,44,45.
... DarkWarn(PXit) when #OppV= EndV-1, or MedDcrsCnt= Med2WrnThrsh;
... FullXit: #OppV>=EndV, WrnCnt=Wrn2XitThrsh, NetV>=OppBgnV(revrs),
... (more FX...) SubTot Votes all=0, or (if VFuz>0) SNtryAddsPXitSz%<=0.
... *CSTMver* TypedIn VPMW: V=EndV; P=PXitSize as #10%s if VFuz>0;
... Cnvrt: M=Med2Wrn, W=Wrn2FullX. Bright decrem's MedCnt; Dark sets=
... Med2Wrn/2. WrnCnt decrem's if NetVot>=BgnVot, but not < Wrn2FX/2.

Please respond with *specific* questions re anything you don't understand ... show the line(s) in question and let me know what was confusing. Thanks!

(EndV PopUp Help.png)



Attachments
Attachments EndV PopUp Help.png (131KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 3/30/2019 4:06 PM (#9517 - in reply to #9513)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
I just did significant revisions to BOTH the BgnV and EndV posts, AND their snapshots. The first line of the EndV text is fixed, thanks to Ken's earlier catch. Both of them now have two NEW lines at the end, which define the CVWcstm version manually-typed-in optional overrides. Please review and note any specific questions. Thanks!

The last of the three standardized-voting Expert parameters defines the Fuzz effect. The label changed a few times, because the meaning changed a lot ... and it was hard to convey in the limited label-size. Hopefully, this description clarifies everything (snapshot attached). The final line defines the optional override for CVWcstm. I still need to play with this a bit ... after testing, I may decide to adjust the 5/2, 4/3 etc assignments a tad, but the basic idea will remain unchanged.

VFuzzBtufEez2BezEtuf -5>+5: +/-1='tough'BgnV,'easy'EndV; +/-5=flipped.
... Neg=NoFXfrom%SzCalc. 1=BigFz-BgnV,SmlFz-EndV; 5=SmlBgn,BigEnd.
... Fuz% for BgnV/EndV +/-1>5= 50/20, 40/30, 0/0, 30/40, 20/50. HistAvg
... for @Vote * Fuz% = VoteFuzLim; if bar Check-Value (Slope|StackDif) for
... Vote < VoteFuzLim, that Vote=0. Net & Opp VoteSums define the Wave.
... *CSTMver* TypedIn BbEeHhh: Bb=Bgn%, Ee=End%, Hhh=HistAvgPds.

Please respond with *specific* questions re anything you don't understand ... show the line(s) in question and let me know what was confusing. Thanks!

(VFuz PopUp Help.png)



Attachments
Attachments VFuz PopUp Help.png (81KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 3/30/2019 4:55 PM (#9518 - in reply to #9517)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Alll-riiiight! I completed my planned tasks for the day (an uncommon situation for me). This is the last of the four Help descriptions. Please be sure to review each of the other three in separate posts.

This GuruV param controls the prior three Expert param's in the Easy version ... but the popup Help explains the Experts anyways, since even though the user doesn't have access to them, their impacts are complex and deserve explanation. Also, the "Actual Inputs & Derivatives" popup section will show their defaulted values and related internal values, just as it does for Xprt|Cstm.

As you read this, remember that the specifics are given in the three Expert explanations ... the purpose here is a general guide as to how to use the GuruV, and how it impacts the output. Snapshot attached.

GuruV_WavesSml2Lrg -5>+5: maps directly to -5>+5 of BgnV, EndV & VFuz
... inputs (Xprt+Cstm)- see below. +1>+5 uses Add&PXit Siz%'s to scale
... in/out, maybe forcing FullX when net%=0; also uses Toe+Cnfrm Entries,
.. -1>-5 uses simple FullEntry & FullExit w/o Add/PXit Size-adj's. General:
... +/- 1>5 creates Timid-to-Aggressive 'Trade-Waves' (filters: use +/-4,5).

Please respond with *specific* questions re anything you don't understand ... show the line(s) in question and let me know what was confusing. Thanks!

(GuruV PopUp Help.png)



Attachments
Attachments GuruV PopUp Help.png (74KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 3/31/2019 2:51 AM (#9523 - in reply to #9521)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Fixes and Cleanups done!

In addition to the fixes, I also modified some other things. The BgnV +5 changes from 40 to 60%. Several tweaks to the EndV mapping, for reasons to complex to write out (compare snap to blue for diff’s, until I update snaps). Generally, using the Timid>Confident concept from 1>5, following the (unchanged) EndV’s of 2,2,3,3,4 - I prioritized the “sequence” of MW’s higher than the Pcts, since when VFuz|GuruV is neg, the Pcts have no effect but the MW’s do. Also I used the idea that neg EndV range should be “faster” to exit than the pos-range counterparts (re MW’s). Finally, I made sure that when the EndV vote-spec didn’t change (2,2 or 3,3) - the MW’s did, to create a functional distinction.

The neg side of GuruV is supposed to be for “simpler trades” (since neg VFuz turns off Sz% calcs and neg BgnV turns off Toe) - so it seems that when -2 EndV is GuruV-paired with -2 BgnV, the PXit should “quickly” kill the Add … while the paired -4 settings (20% & “44” PX w/ 40% Add) should kill it off more slowly.

The Easy version has full -5>+5 range for both Gurus, and full -6>+6 range for CumMeth … ie 1200 permutations. This will be simpler to code and explain than limiting the Easy sliders to pos values … also I’m guessing that negative slider values might work a bit better as filters than the positives do (we’ll see).

Finally ... I updated the Band colors used for the "same-vote-as-prior-bar" case ... much clearer distinctions now, making it easier to quickly see the bright and medium cases. Also, I got all the inputs and section headers rearranged, with several name-changes ... snapshots attached:


(CVWeval V2 Parameters.png)



(Sample Using Defaults - ALXN - new SameVote colors.png)



Attachments
Attachments CVWeval V2 Parameters.png (174KB - 0 downloads)
Attachments Sample Using Defaults - ALXN - new SameVote colors.png (22KB - 0 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 3/31/2019 9:50 AM (#9521 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi Jim,

You asked if the CSTM section is clear, to take a second look. I will go over them one by one. I will answer as you initially suggested, after about a month or so after a new user has "supposedly" viewed the video and read the pdf.

BgnVotNetAddMny2Fw.

To me, this is clear, and after having viewed a video (and perhaps taken notes), I would remember what these values and shorthand represent.

EndVotOppPxtFw2Mny

The only thing that "might" be confusing here is this line:

... CnvrtThrsh M=Med2Wrn, W=Wrn2FullX (Bright:Cnt=-1,Wrn:MedCnt/2).

I have worked with you a "lot" and I still get confuse with the last part of this, the section with (Bright:Cnt=-1,Wrn:MedCnt/2).

The reason I get confused is (1) I have not written this code; and (2) the whole concept is difficult to explain, even in one paragraph. To me, this is one of the more difficult sections/parameters to get my head around conceptually, because this is doing a "lot", and I think I am fairly good at concepts. This is something the video should focus on, looking at charts and the slider, especially for CSTM users.

If I look at it like someone who saw a video a month ago, I might think that I can put a -1 for M or W, since that is what comes before, in order to get a full exit. Then I see Wrn:MedCnt/2, and that would say to me, take the MedCnt ("M"), divide by 2, and that would be a Warn. So that is what I would input. That's how "I" would interpret it after a month.

You're right that this is sort of messy ... normally I'd not include the latter half of that line in Help, since it's internal logic. But I think some users will want to "check" it ... and if they are providing a Cstm override of M &/or W, they probably should understand this. But writing it out fully would take up too much space.
The intent was to convey that for either "count" (Med or Wrn), when a Bright bar appears, it *reduces the count by 1* (never less than 0). And, when a Warn bar appears, the Med count is reset (up or down) to Med2Wrn/2 ... that is, a Warn "primes the pump" so that fewer subsequent Med's are needed to create another Warn.
Upon checking the code, I decided to tweak it a bit. For the MedCnt reset to half, I'm rounding-down ... ie if Med2Wrn input=3, the reset goes to 1, not 2 ... this assures there will be at least one Med between successive Warns, unless the Med2Wrn input spec=2 (not true for any defaults).
Re the WrnCnt decrement by 1, it already is limited to never be less than Wrn2FX/2 (rounded down).
I'm adding another restriction ... the decrement does not happen unless that Bright bar has a strong enough vote to pass the BgnVote threshold ... reason: I don't want to allow lots of Warns without creating FullX's, unless the Wave has a strong recovery from the Warn-pullback.
Here's my revised help-text for that (adds another line):

... *CSTMver* TypedIn VPMW: V=EndV; P=PXitSize as #10%s if VFuz>0;
... Cnvrt: M=Med2Wrn, W=Wrn2FullX. Bright decrem's MedCnt; Dark sets=
... Med2Wrn/2. WrnCnt decrem's if NetVot>=BgnVot, but not < Wrn2FX/2.

VFuzzBtufEez2BezEtuf

The first line is great. No problems with +/- 1 to 5

Not sure if I commented on this before. May have been out. Will comment now.

... neg=NoFXfrom%SzCalc. Vote=0 if ChkVal<FuzLim: 1=BigFuz for BgnV,

The first half, with the neg=, clearly reminds me that this slider controls full exits. That should be sufficient.

The part, Vote=0 if ChkVal<FuzLim is not clear to me; I don't remember what ChkVal is, nor FuzLim. Don't remember seeing it in prior help screens. Must be internal parameters in the code to this section. If you are going to put it in the help panel, should go over it in the video and/or pdf.

I tried to generalize what's going on in the code. There are 8 different baseline averages calc'd, specific to each "ChkVal" (ie 3 slopes, 3 Stacks, and 2 for CurBar) ... the FuzPct is applied sep to each baseline, to create a "FuzLim" for each baseline. If the ChkVal (ie a slope or a stack-diff, etc) is within that FuzLim band, then the Vote for that category is zero for that bar.
The simple "Vote=0 if ChkVal<FuzLim" correctly states that, but presumes the reader can figure out what ChkVal and FuzLim are.
Here's my revised help-text for that (adds another line):

VFuzzBtufEez2BezEtuf -5>+5: +/-1='tough'BgnV,'easy'EndV; +/-5=flipped.
... Neg=NoFXfrom%SzCalc. 1=BigFz-BgnV,SmlFz-EndV; 5=SmlBgn,BigEnd.
... Fuz% for BgnV/EndV +/-1>5= 50/20, 40/30, 0/0, 30/40, 20/50. HistAvg
... for @Vote * Fuz% = VoteFuzLim; if bar Check-Value (Slope|StackDif) for
... Vote < VoteFuzLim, that Vote=0. Net & Opp VoteSums define the Wave.
... *CSTMver* TypedIn BbEeHhh: Bb=Bgn%, Ee=End%, Hhh=HistAvgPds.

The last part, 1=BigFuz for BgnV seems clear to me, and should be after seeing a video a month before.

... 1=SmlFuz for EndV. 1-5 Fuz%/10 for BgnV/EndV= 5/2,4/3,none,3/4,2/5;

1=SmlFuz for EndV seems clear.

as does 1-5 Fuz%/10 for BgnV/EndV.

It is after that when we have the divide sign that things start to get confusing (appropriate for "Fuzz", as it may affect the brain too). If I saw a video a month ago, I would not necessarily remember that BgnV/EndV= 5/2,4/3,none,3/4,2/5; means 5 BgnV and 2 EndV, etc. (although that is logical from the BgnV/EndV before it, and should be clear from the descriptions of BigFuz and SmlFuz for BgnV and EndV), and "none" in the middle would confuse me to think no BgnV and no EndV (i.e, no fuzz at all). I "MAY' think this is a division process (like Wrn:MedCnt/2 above). Then 5/2, 4/3, 3/4, and 2/5 would be confusing if I went this route. Not sure how to make it clearer to the user, other than a video and pdf that clarifies this. Again, this Fuz does a lot, and it inversely affects BgnV and EndV, so it is not conceptually easy, until you understand it better. This is a section of the video that users may have to repeat until they "get it".

... '3'=30%. @Vote-metric uses a dif historical avg to which Fuz% is applied.

This seems clear. It actually might help some to understand the preceding, a bit. They still may have to chew over the preceding for a while to "get it".

The '3'=30% should have cleared this up ... the long writeup you did re 5/2 etc format was totally offbase. Hopefully the revised format above, which expands it to "50/20, 40/30, ..." clarifies it ... note that I *very commonly* use a convention where I'll say something like "Long/Short = X/Y", which is (usually) shorthand for "Long=X and Short=Y". That's what I did here with BgnV/EndV, to avoid repetition of the BgnV= and EndV= pair, five times. I hope the revision is sufficiently clear.

... *CSTMver* TypedIn BbEeHhh: Bb=Bgn%, Ee=End%, Hhh=HistAvgPds

I have 2 questions.

(1) Why here, is the entry 2 digits, when you say above ... 1=SmlFuz for EndV. 1-5 Fuz%/10? Is this so the user can input the actual %, instead of the %/10? The actual values they are to input for BbEe are not confusing, just seems a little inconsistent with what was said earlier. You may not need to change it, but I noticed it and thought I should point it out.
Hopefully the revision cleared this up, by removing the Fuz%/10 that had been intended to apply only to that one sentence.

(2) Hhh=HistAvgPds. Does this mean the user could (theoretically) enter "999", if that "fills their boots" as an experiment, if they load that much data for a security? And that they can use over 100%? (It's OK if that capability is here, just asking).
All overrides for all inputs are "range-checked" to block spec's that are either utterly absurd, or that the code can't handle. In this case, the Hhh periods override allows a range of 20-200. If input is outside that range, it substitutes the "edge" value and drives on. You can see the value that is actually used in the popup panel.

OK. That's my review of the Cstm and Fuz sections.
Top of the page Bottom of the page
JimDean
Posted 3/31/2019 12:07 PM (#9530 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Re Help Panels in general ... re-posted, with lots of snaps - please respond to Q at end

After doing that expansion for the GuruV section, I think that I'm going to take a different path than I've discussed earlier.

In my opinion, that set of four writeups is about as comprehensive as I want to be in writing - although I could create an expanded PDF version of that, it would take a *long* time and I doubt many would read it all - or refer back to it.

Instead, I will go back to my earlier plan of providing all *written* explanations in Help panels ... I'll expand each of the other input param's similarly to how I handled these four ... probably one Popup panel for each of the four "sections" ... the first 2-line section's panel will list and briefly explain all the CumV methods, and will provide an appropriate "table" related to the canned Master selections. The final output section will include concise explanations of the various plots and colors, plus a table that lays out what all the Return options are ... this will likely require two panels.

I'll update and expand the "Actual Inputs and Derivatives" panel ... it will become Panel #1 ... and it will include a few sentences to "outline" the rest of the Help Panels. The Copy-OScript-String panel will be #2, and the ~5 explanation-panels will complete the set.

I will simply copy/paste those panels (zoomed for readability) into a PDF *without adding more detail*, other than a snap of the Input Params and sample snaps of the various plot options.

======

In addition to that PDF-reprint of the HelpPanels, I'll create a few training videos. And of course in addition to that, there will be a few threads dedicated to Q/A, etc for CVW. I think that should do it ... it's arguably more than Nirvana provides.

The snaps below come from a quick restructuring of the code ... obviously many of them need to be fleshed out. But the *idea* should be clear ...

Is this plan a good one, or is more needed? NOW is the last chance to opine about this!

(CVWeval V2 HelpPanel-1.png)



(CVWeval V2 HelpPanel-2.png)



(CVWeval V2 HelpPanel-3.png)



(CVWeval V2 HelpPanel-4.png)



(CVWeval V2 HelpPanel-5.png)



(CVWeval V2 HelpPanel-6.png)



(CVWeval V2 HelpPanel-7.png)



Attachments
Attachments CVWeval V2 HelpPanel-1.png (266KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-2.png (294KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-3.png (138KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-4.png (98KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-5.png (407KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-6.png (71KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-7.png (48KB - 0 downloads)
Top of the page Bottom of the page
SalimHira
Posted 3/31/2019 3:04 PM (#9534 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 171
1002525
Location:
USA: MD, Columbia
Here is one suggestion as starters:

1). CVW Help panels - includes all the relative information needed based of the parameters on need basis, and other important information

2). PDFs - includes all the technical stuff, and detailed reference points - primarily copy/paste content of what you have from the T.T. forum posts to date.

3). Video(s) - a general overview, usage, etc.

4). TT forum - Q/A, examples, user-feedback, etc.

5). etc...
Top of the page Bottom of the page
JimDean
Posted 3/31/2019 3:39 PM (#9536 - in reply to #9534)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Thanks, Salim ... that's very helpful!

It appears that what I described initially is what you are saying, BUT you are suggesting in #2 that the PDF should be continually updated as more posts are added to the forum which might have broadly-useful info.

That is, when I take the time to answer a Q in the forum, if it's a useful Q, then you're suggesting that *when* I answer the Q, I *add* that answer (incl graphics if any) to the PDF (which is attached to a "locked" post in the Distribution thread).

Presumably whenever I did that, I'd include a note in the Answer post re the update, with a link to the standard place where the PDF is.

Since I don't want to rewrite/restructure the PDF each time, I'd probably just add the new info to the next PDF page ... maybe I could add a one-liner to a Table of Contents for each new entry.

That's a very practical idea! And, it's a meaningful "selling point".
I could employ this method for all Stradicators ... and the amount of extra effort it would take to add to the PDF "on the run" would probably avg at about 15 min / entry ... of course answering the original Q might take anywhere from 15 min to an hour or more ;-)

Thanks!

Top of the page Bottom of the page
JimDean
Posted 4/1/2019 7:46 AM (#9539 - in reply to #9530)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Ken ... please note that HP#1 needs a LOT of "cleanup", as stated on its final line in all-caps ;~)
Salim ... if you're volunteering to help manage the PDF updates, thanks! I'll discuss later w/you.


Now ... "Back to the Fuzzy" ...

I discovered a huge issue yesterday with the proposed "BtufEez2BezEtuf" fuzzy-change ... it messes up virtually *all* of the outputs, and requires a *lot* of new calc's. So, I scrapped it ... Ken & I discussed on phone and came up with a good alternative that utilizes the original Fuzzy "Small2Large" slider approach ... but it had some weaknesses. Further thinking last night and this morning solved all that. The notes below retain the planned Easy/Xprt/Cstm input-combo's, but redefine the meanings of neg vs pos for GuruV & Fuzz, and "empower" the dots/nodots PltRtn variants. I'm pretty happy with it ... but maybe I'm missing something. Please read carefully, and comment.

1. Keep -5 > +5 Vote Guru … neg Guru= noTAP (Toe,Add,PX all off, using pos BgnV+EndV maps) ... Guru uses locked-in Fuzz (Fuz only variable via Xprt slider), and has no access to -BgnV or -EndV options. So, Easy version can't access any (arbitrary) fuzz-tweaking, and some (secondary) Add/PX/MW variants. (Easy has -6>+6 and 2*(-5>+5) = 1200 patterns.)

2. Fuzzy expert Slider = small to large, but label to imply slide-left + choppy vs slide-right + continuous ... mirror neg & pos 1-5 fuzz %'s. Neg fuzz input turns off Adds & PXits, but retains MW cnts & Toe|Full, and small diff's for +/-PX MW.

3. Toggle Size% calc's that impact final-exit as well as equity calcs, via the PltRtn slider ... pairs of Plots: A) FullXit w/no Adds/PXits shows just (Toe/)Ntr/FXit dots (allows Toe+Cnfm since easy for TP) ... VERSUS ... B) those 3 dot-types plus Add/PXit dots *with* extra FX-rule related to NetSize calc's. Total of nine plot options (no dots w/internals chart) ... and about 2-4 of the Return options will have to double-up.

4. Easy-version GuruV neg with PlotA toggles Toe off, and GuruV neg makes PlotB the *same* as with PlotA. Xprt-version GuruV neg BUT with Fuzz-slider positive *allows* Add+PXit, since Xprts override Gurus ... similarly, neg GuruV with BgnV-slider positive *allows* Toe (indep of fuzz slider re Add/PXit). SO: versatile permutations ... but popup help probably should provide a simple lookup table showing which combos of GuruV, BgnV, VFuz, PltRtn make each of the Toe|Add|PXit|Size% features active, and which don't. (note that BgnV= -1,-3,-5 turn off Adds w/o affecting PX's).
Top of the page Bottom of the page
JimDean
Posted 4/1/2019 9:41 AM (#9540 - in reply to #9539)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
I've modified the Help for the four Vote param's ... major changes for GuruV and VFuz (also note NAME CHANGE for VFuz). Minor tweaks for BgnV & EndV ... so far. I need to re-think EndV's neg Pct's and neg MW's in light of the various "toggle" effects of the revised VFuz and GuruV logic.

PLEASE chew this over, in light of the prior post's changes (see updated Help, below):
There *may seem to be* a logical conflict if GuruV is negative, which defaults to *no* Toe|Add|PX ... but also the BgnV slider is >0 (meaning Adds are active) ... and EndV slider=0 ... that would leave PXits turned off (default state from neg GuruV), with Adds & Toe+Cnfrm active (due to BgnV override of GuruV). The "Add rule" requires a PXit to have occured before any Add can be done ... so in actuality, the "potential" Adds that this situation "seems" to allow will *never* take place, since PXits are turned off. Thats *good* ... but it's a nuance that the user might be confused by at first.
Similarly, if neg GuruV defaulting plus EndV slider <> 0, then the EndV slider overrides the Guru and PXits *are* allowed (though Adds & Toe+Cnfrm still aren't, as long as the BgnV slider=0). Again, that's *just fine* ... no worries about using PXits with no Adds ... but user needs to understand.
Furthermore, if the PltRtn (final param) setting is in the "no Adds|PXits" setting, then *it* has the *final veto* ... regardless of GuruV or its experts, if PltRtn *dis*allows Adds&PXits, then they will *not* be implemented (although of course the MW counts that influence the final exit still are in play).

>> I mentioned in the prior post that Help would include a "Scaling Table" which shows, for various "states" of GuruV+/-, BgnV+/0/-, EndV+/0/-, VFuz+/0/-, PltRtn on/off (13 table-rows) ... whether T&C, Adds, PXits, &/or Size%FullX are "active" (ie four columns). I think (hope) that table will totally clarify the interactions, AND illustrate just how *powerful & versatile* the input-combinations are.<<

I'm attaching the four updated Help snapshots, along with the renamed Param's snap ... PLEASE REVIEW these with a fine-toothed comb. Thanks!

(CVWeval V2 Parameters.png)



(GuruV PopUp Help.png)



(BgnV PopUp Help.png)



(EndV PopUp Help.png)



(VFuz PopUp Help.png)



Attachments
Attachments CVWeval V2 Parameters.png (174KB - 0 downloads)
Attachments GuruV PopUp Help.png (153KB - 0 downloads)
Attachments BgnV PopUp Help.png (251KB - 0 downloads)
Attachments EndV PopUp Help.png (285KB - 0 downloads)
Attachments VFuz PopUp Help.png (125KB - 0 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 4/1/2019 12:50 PM (#9542 - in reply to #9540)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
From Jim's post 9539:

4. Easy-version GuruV neg with PlotA toggles Toe off, and GuruV neg makes PlotB the *same* as with PlotA. Xprt-version GuruV neg BUT with Fuzz-slider positive *allows* Add+PXit, since Xprts override Gurus ... similarly, neg GuruV with BgnV-slider positive *allows* Toe (indep of fuzz slider re Add/PXit). SO: versatile permutations ... but popup help probably should provide a simple lookup table showing which combos of GuruV, BgnV, VFuz, PltRtn make each of the Toe|Add|PXit|Size% features active, and which don't. (note that BgnV= -1,-3,-5 turn off Adds w/o affecting PX's).


Jim: It would be helpful to have that lookup table (Perhaps created in a Word table so everything lines up properly and evenly for those with OCD ;-) on a separate page in the pdf, so that people would be able to print that out.

===========

Now to post 9540:

I've modified the Help for the four Vote param's ... major changes for GuruV and VFuz (also note NAME CHANGE for VFuz).

VFuzzNgNoAPXoff2Big Name is good, once you figure out what it is saying.

Here is an idea. Perhaps also in the pdf, put a glossary at the back, translating things like VFuzzNgNoAPXoff2Big into "real English", something like "VFuzzNgNoAPXoff2Big is the Fuzzy vote slider [Vfuzz] that if negative [Ng] provides for no [No] Adds [A] or Partial Exits [PX] by turning them [off]. Values go from small to [2] big in size." This glossary should not use abbreviations to explain abbreviations, but would be most helpful in the plain English format, similar to the above. The documentation in Nirvana products is minimal (less than above often), with many times no idea what effects moving sliders on Nirvana products actually does.

This would also preempt those who would complain about the abbreviations, as there would be a glossary (which they also could print out, if needed), which explains in simple English what it does and what it means. Also, with a plain English glossary, they will find it easier to understand other abbreviations used that may not make it into the glossary. Then if on the TT forum, people have questions about what something means, it could be added to the Glossary fairly easily, and updated. Those not asked about would be assumed to be understood.

PLEASE chew this over, in light of the prior post's changes (see updated Help, below):
There's a logical conflict if GuruV is negative, which defaults to *no* Toe|Add|PX ... but also the BgnV slider is >0 (meaning Adds are active) ... and EndV slider=0 ... that would leave PXits turned off (default state from neg GuruV), with Adds & Toe+Cnfrm active (due to BgnV override of GuruV). The "Add rule" requires a PXit to have occured before any Add can be done ... so in actuality, the "potential" Adds that this situation "seems" to allow will *never* take place, since PXits are turned off. Thats *good* ... but it's a nuance that the user might be confused by at first.
Similarly, if neg GuruV defaulting plus EndV slider <> 0, then the EndV slider overrides the Guru and PXits *are* allowed (though Adds & Toe+Cnfrm still aren't, as long as the BgnV slider=0). Again, that's *just fine* ... no worries about using PXits with no Adds ... but user needs to understand.
Furthermore, if the PltRtn (final param) setting is in the "no Adds|PXits" setting, then *it* has the *final say* ... regardless of GuruV or its experts, if PltRtn disallows Adds&PXits, then they will *not* be implemented (although of course the MW counts that influence the final exit still are in play).


The table (discussed below) is a great way to show what ACTUALLY happens, maybe with a footnote or two below the table explaining why (even your explanations above could be used).

>> I mentioned in the prior post that Help would include a "Scaling Table" which shows, for various "states" of GuruV+/-, BgnV+/0/-, EndV+/0/-, VFuz+/0/-, PltRtn on/off (13 table-rows) ... whether T&C, Adds, PXits, &/or Size%FullX are "active" (ie four columns). I think (hope) that table will totally clarify the interactions, AND illustrate just how *powerful & versatile* the input-combinations are.<<


This table will indeed show how powerful and versatile the combinations are. Again, this should have a separate page in the pdf, so people can print it out if they want to.

b]I'm attaching the four updated Help snapshots, along with the renamed Param's snap ... PLEASE REVIEW these with a fine-toothed comb. Thanks!


I reviewed them (twice). I think this is a good set of Help panels, as is. I did not see anything way too confusing or contradictory.


Edited by KenWilsdon 4/1/2019 12:51 PM
Top of the page Bottom of the page
JimDean
Posted 4/1/2019 1:09 PM (#9543 - in reply to #9542)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Thanks, Ken

I agree 100% re the importance of a clearly-understandable Table w/footnotes and a few examples to boot.
I can see that a glossary would be nice too ... but of secondary priority.

Re: VFuzzNgNoAPXoff2Big ... you copied it incorrectly ... should be VFuzzNgNoAPxOff2Big ... parses as: VFuzz: Neg=No-Add|Px; Off2Big. That is, Off2Big is what 1-5 choose between, and if the input is negative, then no Adds or PXits are allowed (regardless of what BgnV or EndV might imply).

You understood it properly ... just got lower & upper case flipped.

I could change it to: VFuzzNgNoAPxSml2Big, but since input 1= 0% fuzz, "off" is more descriptive.

Top of the page Bottom of the page
JimDean
Posted 4/1/2019 4:50 PM (#9544 - in reply to #9543)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Updated collection of thoughts, mostly re Equity analysis calc's/output, but other stuff also ...

• SBAS Master 1-33= best of 12*10*10=1200; 11/11/11 = Filter/Trend/Swing (Slow>Fst)
• CumMeth: -6>+6 for all versions
• for SBAS tests, skip -6,-3,+3,+6 CumMeth; skip +/-1,5 on Guru’s => 8*6*6=288 tests
• if GuruX 2 ~better than GuruX 4, and if GuruY 4 ~better than GuruY 2, need more tests
• Second set of (same-procedure) tests = 8*(10+10)=160 more
• => Max= 448 total SBAS tests (all the same re columns and test-types)

• neg MAspd: use wider spread = slower, just as neg MAtyp is slower and neg MAslp is slower
... ... so, maybe that neg MAspd (and negGuruT) range will be good for filters or long term trades

• GuruV= negative disallows any Toe|PXits|Adds in calc's and outputs, regardless of its experts
... this *replaces* the doubled-up PltRtn options ... and is part of the "portable algorithm"
... it gives "Easy" ver user a simple way to control this major impact: Neg= "traditional TP's"
• GuruV= positive, in Xprt|Cstm: BgnV<0=NoAdds; EndV<0=NoPXits; VFuz<0=NoToe
... allows *any combo* of Toe|PXits|Adds, in memorable places (fancy TP if BgnV | EndV > 0)
... it also means that all three experts' neg ranges s/b *identical* to pos ranges in other respects
... it also means that the Easy GuruV when negative is "logically" the same as the 3 in Xprt ver

• Need Toggles for: Short/Both/Long & EqtyFltr-Sigs & FwdWtd-Eqty-Stats
... ... Fore/Bkgrnd only applies if person paid extra for that high-level "recursive" filtering ability
... ... F/B, S/B/L, FwdWE settings would normally be "locked in", then experiment w/other settings
... ... S/B/L: B is likely the default; L-only also very common; S-only is very specialized
... BarWndoToCalculate is in portable paradigm ... slider is 0-999 (0-299=S,300-599=B,600-899=L)
... ... for Plotting, ###=output window width; for Return, ###=#barsB4hre (both= auto-warmup)
... ... current override: BbbWww, so both metrics can be spec'd (for targeted historical backtesting)
... ... allows 999 bar (~4yr) test-window, ending any time in the past 999 bars => 8yr coverage
... SOLUTION: add one extra digit to BarWndoToCalculate override, for the Toggles:
... ... New typed override: BbbTWww, where T controls S/B/L and Fwd-Wtd-Eqty-Stats(vs not Wtd)
... ... ... Bbb and Www can each be 0-999 (not in 300-segments as for slider S/B/L)
... ... ... T: 2=BothLS & NoFWE, 3=Long& NoFWE, 1=Short& NoFWE; 4/5/6=S/B/L & UseFwdWE
... ... ... 4-6 only needed when test-window is wide; also, FWE calcs are messy and maybe N/A
... ... ... Positive = No EqutyFltr on Trades; Negative= Use Equty-Flr (if licensed)
... ... Examples: 426= BothLS,NoFWE,NoEFltr, -426=same,w/EFltr; 6126=Long,UseFWE,NoEFltr,126b
... ... ... Very easy to type in or delete a neg sign, or a digit, or both ... and readily visible
... ... ... Very likely to want slider's ### setting locked, when playing with these other features
... ... ... +T's 1-3 are "base" features; +4-6 are specialty; neg has license-fee, => easier to code
... Clean, versatile, portable, memorable solution ... and, MORE control with NO new sliders!

• various flags => don’t need *dual* curves or wallpaper on Eplot for w&w/o Pcts or A+PX
• instead, show E+2ma’s, and use Wallpaper color to show Use/Maybe/Off from E voting
• Maybe = change Use<>Off *during* a trade - could mean start late or end early
• Maybe Starts/Ends when E vote changes; goes to Off/Use when current trade Ends
• show “actual” trade-equity as histo = using the E toggle effects (sep Return values too)

• Eqty calc if PltRtn req’s; pointer-chain calc
• Normalize/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$
• Lrs(E,X), Wma(3,Y) w/ Lrs(2,3) => 2stk+3slp, where X=8-12, Y=4-6 = f(SlowCumMA)
• Use=5-3net, f(Bgn); Kill=2-4opp, f(End)
• PltRtn Cstm override: XYUKss (ss=slider)

• All versions provide Signal and "basic" Scan outputs = **RAFT, or ATQ, or RUFF** (see below)
... *don't* need SlopStak EqtyVote to calc these (all could be avail, as Cstm Return options):
... ... NT = number of trades in test window
... ... HR = percent of trades that were profitable
... ... TPL = NetTrdPL ... w/Scaling Adj's, normalized for ClosePrc & WTR
... ... PF = profit factor = [HR * sum(TPL,winners)] / [(1-HR)*abs(sum(TPL,losers))]
... ... *TDD = MDD during a Trade = (Peak b4 largest drop - Lowest b4 new high) / Peak b4 drop
... ... TQ(TradeQuality~Rwd/Rsk) = TPL*[ 1/(bgnWTR*3) + 1/TDD ] /2
... ... TE(TradeEngagement) = Tot#BarsInTrds / #BarsInTestWindow
... ... STQ(SumTradeQuality) = Sum(TQ / BarsInTrd, NT)
... ... ATQ(AvgTradeQuality) = STQ^TE
... ... ... ... STRR=2^ : .8=1.74, .6=1.52, .4=1.32, .2=1.15 ... 51% (frc=4.93x)
... ... ... ... STRR=1.5^: .8=1.38, .6=1.28, .4=1.18, .2=1.08 ... 28% (frc=4.75x)
... ... ... ... Avg of TRR=2 / TRR=1.5: ( 1.26 + 1.19 + 1.12 + 1.06 ) / 4 = 1.18
... ... *MDD = test-window: (Peak b4 largest drop - Lowest b4 new high) / Peak b4 drop
... ... ... *TDD & MDD are considerably trickier to calc than the others in this list
... ... SPL = Sum(TPL,NT) = takes scaling into account
... ... CAGR = test-window: (End$/Bgn$)^(1/#yrs)-1 = SPL^(260/bars)-1
... ... APR = test-window: CAGR/Bgn$ -1
... ... Calmar = CAGR / MDD, using $normalized by share-price and ATR-risk
... ... ADD = test-window: Sum(TDD,NT)/NT ... TDD defined above
... ... APD = profit/trade vs avgDD/trade = SPL /NT /ADD
... ... RUFF= ReturnUpsideFreqFear = CAGR*sqrt(HR*TE)/ADD ... broader Calmar
... ... RAFT = ATQ*RUFF ... combo of "trade-focus" with "overview"
... ... ... ... depending on typical ranges of ATQ & RUFF, may need multiplier for scale
Top of the page Bottom of the page
JimDean
Posted 4/2/2019 7:58 AM (#9546 - in reply to #9544)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
I've revised the final red section of the prior post, renaming some things but mainly to define another overall metric "RUFF" that I think would be a more useful alternative to Calmar. The newly-renamed "ATQ" (previously ATRR) is another general-metric that I think would be better than Calmar.

ATQ focuses a bit more closely than RUFF on what's going on in each trade, evaluating small-wiggles as well as swings within the trade, and uses TE via exponentiation to factor in how frequently that symbol is "engaged" during the test period. RUFF starts with the net gain during the period, normalized annually, and adjusts it by sqrt-attenuated HR*TE ... incorporating TE in a different way, and also flavoring the result by the likelihood of success for a given trade ... finally, tempering it with ADD to represent the "fear factor".

I'm not sure which of the two (ATQ or RUFF) would be "better". So, I combined them into a single number ... RAFT = ATQ*RUFF ... (conceivably if by serendipitous chance ATQ and RUFF have similar value-ranges, they could be averaged instead of multiplied) ... but however it's done, a higher value is better.

Please chew over the revised and expanded formulae, and let me know what you think would be most useful as a SINGLE metric for OmniScan selection of good candidate symbols that would populate the FL.

Salim, since this has nothing to do with the parameters or other workings of the Stradicator ... it's just ways of measuring trading success potential ... please don't just skim past it ... give it some careful thought, and *choose* one - thanks
Top of the page Bottom of the page
KenWilsdon
Posted 4/2/2019 11:15 AM (#9549 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi Jim,

Upon further reflection, I have a question how these metrics would be used in, say, Omniscan to sort for the best candidates. I know we talked generally about it, and I am in agreement with it, but need more details to make a decision on the 2 alternatives.
3 alternatives: RAFT, RUFF, or ATQ

My questions relates to how we would determine which sets to scan for. I am conceptually trying to understand the process. Also I am trying to understand how this process could be automated (you know this is a big focus for me). Then I may have a better idea which of the two metrics I personally prefer.

1. Would not these metrics be Guru and Xprt sliders derived (as I understand the values)?
All input param's would affect the output metric, of course. You'd use SBAS or other means to determine what input-pattern you want to use ... most likely, use the same for the Scan that you use for trading those symbols ... that's the core idea anyhow.

2. If so, are we finding the best general set(s) of settings, and scanning for them to put in our Focus List? A good start would be the Master sets, of course. I understand from prior posts that there will be 8 Masters for filters, which I assume could be used, then symbols sorted in the FL by how strong they are, by the metric chosen, or by Ind. FL Columns for each of the 8.
What Master options will be is still very fluid ... need to see the SBAS results for that.

3. Do we do that by running on something like the Russell or SP500, etc. (user defined) to find those which pass some threshold (also user defined) in the Omniscan (using other variables like min volume or price to filter as well) on at least one of the 8 Master Sets?
I'd use maybe Optionable (~3k symbols, presumably fairly liquid), then put in other Scan filters for Price and Liquidity limits and other Personality things to cull the list down. Then use this output CVW equity-stat to SORT the list, to peel of the top X symbols (50 maybe?). Once you get a feel for what the typical range is for the equity-stat you want to use, you could also optionally call CVW as a part of the Scan filters, requiring some minimum value for the equity-stat (as well as sorting on it). Or, you could use one EStat for filtering, and another for Ranking.

4. How do we then determine which slider positions we want for a particular symbol on a particular day? The 8 Masters would get us close, but if we use just this to buy/sell, then in some ways the other sliders will be unused. So how do we get to the next step? I am sure the metrics here will be used, but unsure of the process.
The Scan I described would be looking at recent-history ... depending on how tight that sampling is, the Symbols chosen for the FL would vary at different rates. My guess is that redoing the scan once a week, using the same param's, would be sufficient (as long as you also keep the params of the strategy the same). Occasionally, maybe once a quarter, you might decide to re-optimize the param-pattern, and update the OScan filter|sort as well as the strategy with the new values. I wouldn't expect the quarterly tweaking to result in radically different patterns, but ya never know ...

I hate to slow down your work to answer this question, but we have not (to my knowledge) really dealt with this in the forum to date (I may be wrong) in print, so we have a record of the process. Doing this may clarify some things unknown to us presently that need to be addressed, and may also make clear which metric we should use. This is like taking a step back to look at the big picture goal of this whole process. As this will be used in all upcoming Stradicators, I think it is important to clarify the process at the start, so we get things right the first time.
very good question ... hopefully my explanation helps
Top of the page Bottom of the page
SalimHira
Posted 4/2/2019 2:31 PM (#9550 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 171
1002525
Location:
USA: MD, Columbia
RAFT, ATQ, and RUFF in that order.

The way I am currently thinking, unless proven otherwise, since it does not seem to matter if either ATQ or RUFF, as the value best that goes higher - than, I'd select RAFT the combo of both... but, if I need to know in particular which may be leading or lagging in the race btwn ATQ and RUFF - than it becomes a coin toss - and in that case, I continue to select ATQ in every instance of the toss for the simple reason of the "fear factor" embedded in the equation.

THANKS!
Top of the page Bottom of the page
JimDean
Posted 4/2/2019 2:33 PM (#9551 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
When Ken asked about Long/Short/Both control on the phone call yesterday, I was bothered that I could not find the definition of the "DCZSVOO" PltRtn override that was in the code-comments ... turns out that it was in a post back on 3/28 (actually earlier, before repost with updates) ...
http://tradetight.org/forums/thread-view.asp?tid=1432#M9490

That post specified "DCZSV" as Cstm-ver manual for the PltRtn OutputReturnHelpPlot input:
... D= trade-Dir's allowed SBL; affects are interactive (B <> S+L sometimes)
... C= EqtyVote impact on trades: Block Entry/FIlter &/or Force PX/FX &/or LateEntry
... Z= SmartSizing as func of atrRisk &/or pctPrc for initial-base 100% value
... S= tweaks to Equity-MA speed/slope (~TimeGuru for Eqty filtering)
... V= tweaks to Equity-Voting rules (~VoteGuru for Eqty slope & stack)
(actually it would have been DCZSV##, where ## is the normal PltRtn slider value)

However, since I more recently defined a way to handle the Long/Short/Both via the "T" digit override of the BarWndoToCalculate param, I don't need the "D" digit as part of the PltRtn override group. "T" was defined in this post:
http://tradetight.org/forums/thread-view.asp?tid=1432#M9544

Also, since the EqtyFltr-Sigs toggle (ie use EqtyFltr logic or not) is part of BarWndoToCalculate's override as a *very easy to manually flip* "+/-" feature, it can *remain* there, even though the "C" override for PltRtn specifies a granular control of how the EqtyFltr might be applied. If "C" is manually input in PltRtn, then the "-" in BarWnd simply toggles it off/on (handy for quick comparisons).

Most of the PltRtn features above are related to the extra-cost Equity-Filter option ... except for D which is being handled by T in the BarWnd override. Since most of the other features of the CZSV group require the optional Equity-filter license purchase, it makes sense for them to stay together, while the "standard" Long/Both/Short s/b in the BarWndo "T" digit.
The "Z" digit provides a bias-adjustment to the SmartSizing formula, which was enhanced by "AutoGenTP" research last year (italics, below). Z specifies a representative "stop-loss" gap related to ATR: Z=1-9= 1.0-5.0x in 0.5 increments ... default= 3.0 is used if Z not specified. This (renamed to "R") becomes the basis for what follows.
SmartSize balances the Risk$ vs Capital$, in light of what's "typical" for that stock's price-range. Normally you use something like 10% of Account to limit Cap$ (Elder), and something like 2% of Account to limit Risk$ (VanTharp). SmartSize (in its simplest form) calc's the shares for both limits, and uses the smaller of the two.
Here, we don't "know" the Equity since all the $ are normalized, so we only need to know the ratio of those two percentages ... ie 5.0 would represent 10%Cap/2%Risk. So, our override "B"(balance) for this spec will be a single digit 1-9, which represents a SSratio of 2-10, where 0=default would use 6.0 ... ie 1.67% Risk$ for 10% Cap$.
Therefore, the two digits BR define SmartSizing. This does not require EquityVote licensing, but can't fit into the
BarWndoToCalculate override, so it has to be in the OutputReturnHelpPlot override, since the GuruV+3experts already have overrides for other things (GuruV override is for Filter).
Optionable Stocks were sorted into 200-sym bins, then a median share-price and ATR for each bin was found. The result, when parsed into 9 normalized bins, showed that sTR/5%C was 4.25 for $86 stock, and 1.44 for $5 stock (where sTR = sma(ATR(1)) ... thus, knowing the price of the stock, the "typical" sTR can be calculated: Typical sTR= Close/20 * [1.44+Close*(4.25-1.44)/(86-5)]. If the actual sTR is >/< the Typical, then there is currently more/less wiggle-Risk$ than typical for that share price, and the Size should be adjusted by TypSTR/ActSTR. HOWEVER, the actual code will not use that approximate linear $86-$5 formula ... it will use a curve-fit to the 18-bin nonlinear table that came directly from the research to determine the appropriate "balance point" TypSTR for a given Symbol's Close$.

Summary of rearrangements from those two prior posts:

Manual override for BarWndoToCalculate (all versions, no special license):
... BbbTWww, where T controls L/S/B and Fwd-Wtd-Eqty-Stats-Calc(vs not Wtd)
... ... Bbb and Www can each be 0-999 (not in 300-segments as for slider S/B/L)
... ... T: 2=BothLS & NoFWE, 3=Long& NoFWE, 1=Short& NoFWE; 5/6/4=B/L/S & UseFwdWE
... ... 4-6 only needed when test-window is wide; also, FWE calcs are messy and maybe N/A
... ... Bbb *not required* unless historical test window should end sometime before the Hre
... If this input is NEGATIVE, it toggles EquityFiltering ON (if it's been licensed)

Manual override for OutputReturnHelpPlot (only avail with Cstm & special EquityFiltering license):
... SVCBR##, where +/- ## is standard PltRtn settings for output control, and:
... ... S= tweaks to Equity-MA speed/slope (~TimeGuru for Eqty filtering)
... ... V= tweaks to Equity-Voting rules (~VoteGuru for Eqty slope & stack)
... ... C= EqtyVote impact on trades: Block Entry/FIlter &/or Force PX/FX &/or LateEntry
... ... BR= SmartSizing as func of atrRisk &/or pctPrc for initial-base 100% value (see above)
Top of the page Bottom of the page
JimDean
Posted 4/3/2019 10:28 AM (#9552 - in reply to #9551)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
(Fairly) Easy "Visual" Q for Salim & Ken ...

I'm working with Ken on possibly implementing bands around price for trailing-stop-like partial & full exits both on the downside ("Curbs") and upside ("Grabs"). They would appear on the price pane as two or four lines, spaced above and below the candles based on Strad-set ATR-mults. This would be a part of the "standardized portable paradigm" that I'd implement in all Strad's. There are *a whole bunch* of pros and cons ... but THIS POST ONLY FOCUSES ON ONE THING ... how it would affect the appearance and usability of the Parameter pane. Please limit your comments to that, here.

In the snap, I "faked" moving the last two lines to just below the first two, and adding in a new slider at the bottom which would be a fourth "expert" under the VoteGuru (new slider would not appear in Easy version, but rearrangement of last two lines would). Reason 1: if I add any more lines to the pane, it becomes ugly two-column. Reason 2: I'm thinking maybe it's more useful to keep the two section-divider gray areas to identify the two Guru-sections, rather than having to remove the one in the middle, scrunching two Guru sections together, and keeping the two output control lines at the bottom with a section-divider between them and the Gurus.

Note that the section labels change and also the Guru param names change ... when the two Guru sections have no intermediate divider, I capitalize GURU to help clarify the boundaries.

Two snapshots provided. Which do you prefer (visually and functionally)? (please keep in mind that this might affect a lot of stradicators).

Result: Ken liked #1 for reasons I agree with; Salim liked #2 ... going with #1


(Params with GC-gap slider & same Output.png)



(Params with GC-gap slider & move Output.png)



Attachments
Attachments Params with GC-gap slider & same Output.png (179KB - 0 downloads)
Attachments Params with GC-gap slider & move Output.png (172KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 4/3/2019 4:16 PM (#9556 - in reply to #9552)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
I think Ken & I got the "bands" decided upon ...

PricePane will show Two lines below price, and two above
Tight line is for Partial exits, distant line is for Full exits
Exits from lines above called "Grabs" (ie grab your profit)=PG|FG
Exits from lines below called "Cuts" (ie cut your loss)= PC|FC
... Partial|Full exits triggered by Stradicator-specific logic are still called PX|FX
Distances of the lines away from price controlled by new -5>+5 slider: CutGrabGapSzSm2Lrg
... a fourth expert, controlled by the GURU_WavesSml2Lrg input, if expert=0
... negative slider = turns off Partial inner lines ... only FullCut & FullGrab (lowest &highest) remain
... this slider alters the gaps, not the size-Percent

FullCuts will tie into Broker StopMkt orders in the TP, to assure protection even if OT|feed fails.
... these will trigger based on Long/Short= L/H price crossing the threshold (same bar exit)
... OLang resets SM level on bars where it should "ratchet"closer ... never gets wider
... the ATR-multipliers for these gaps will be *locked* (no override), since hardcoded into TP
... Robust-TP will slightly tighten the FC gaps after each new Add (hardcoded)
PartCuts, PartGrabs, and FullGrabs will use "virtual" Mkt orders:
... internal calc's watch price and fire the order when the level is crossed (same bar exit)
... FullGrabs will fire when Close price crosses threshold, presuming EOD feed calc'd at night
... Partial Cuts & Grabs will fire after Close has crossed the threshold (next Open exit)
... Logic for these will use "smart time" ... tightening a bit, for each bar that doesn't improve Profit
... these allow Cstm user to *override* their 3 (initial) ATRmult's, independently

We also discussed practicalities about the TradePlan. Two types:
... Simple TP that supports Full or Toe+Cnfrm entries, and the FullGrab & FullCut line exits, plus standard Stradicator-logic FullExits, but not Adds or PXits of any type (Strad PX, PC, or PG).
... Robust TP that supports all Entry, Add and Exit types (VERY long ... thousands of Conditions)

All prior descriptions of how Signals are output (via Return) and meaning of Band colors (or their related Return "T-color" values) are *unchanged* by this. When a PartialCut fires due to crossing a threshold-line, it will show up on the plotted Band as a dark-gray color "Warn" (instead of dark green or dark red). In the internal calc's, it will "act like" a Warn, in relation to the Med2Wrn count reset rule, and the Wrn2FX count rule ... that is, if a cross of the inner PC line occurs when the Wrn2FX count was one less than its threshold, then that PC cross will trigger a FullExit rather than a PC exit, and will "paint" as black on the Band.

When a FullGrab occurs, from the Close crossing the outer profit-line, then it will paint as black on the Band, since it ends the trade a Mkt order (executed first thing next bar). When a PartGrab from Close crossing the inner profit-line fires a Mkt order for next-Bar execution, then it will paint a light-gray bar on the Band, and will be treated in the internal logic as a "bright" bar would be. If the bar that crosses the PG line might otherwise have triggered an Add, the Add is cancelled (it would have been a poor pricepoint for an Add, anyways).

The standard-paradigm Stradicator Add logic will be modified to *prevent* an Add from occurring when it is triggered by the "normal" rules, if the Close price is not a good one (ie too high, for Long) - the internal code will emulate this. The "acceptable range" will be the lowest of: highest prior Close since trade began, or halfway from the price to the PartialCut line at the time of the prior Close. Adds will use StopMkt-Orders (following day) with level set to the Close of the prior bar that signaled the Add ... which usually prevents a poor price-fill, but definitely prevents a partial-fill.

The code will assume that feed is end of day, executing after the close ... unless I can find an easy way to "read" OT's exchange-time table to get the Start and End time for that day, versus the current clock time. I'm asking Barry for that. Fingers crossed.

Add-overrides will have a min limit of 20% and max limit of 80% (4*20) ... this assures that no more than four Adds can occur in a trade (ie during Elliot Wave 2 & 5 "A"&"C" legs, ideally). Each successive Add is 20% smaller than the prior one.

Partial G|C virtual orders use the PXit pct defined by the EndV slider, unless it's overridden. That is, the PG|PC exit size can be: default PX size, overridden PX size, or a different size from a CutGrab slider override. Regardless of the source, the size *must* be one of the 10%-multiples supported by the PXit orders in the TP ... likely range will be 50%-10%. The default PX assignments from the EndV slider are 20|30 ... maybe I'll change that to 20|40 ... unsure at this time. Note that if the user wants PXits to be bigger than 50% in order to end the trade quicker, they can reduce M &/or W so that the PXits fire more easily.

A new EndV override option will permit the user to modify the PXit-size required to allow a subsequent Add. Default is 3/8 of Add for first add, and 2/3 of next-add, for following Adds. New override can require prior PXit to be at least: 1=1/6, 2=1/4, 3=1/3, 4=3/8, 5=1/2, 6=2/3, 7=3/4, 8=1/1,9=anyPX ... that represents all the combo's of 80%-20% Adds, with 30% & 20% PX's.

The new CutGrab slider will permit separate overrides for Partial Grab & Cut sizes (ie instead of the size of the normal PXit defined by EndV) ... but these must be in tens-increments from 50%-0%, so that the Robust TP can support them with its standard Conditions (0% permits Cstm uset to turn off either/both PC|PG, while leaving FG active). Also, separate PC|PG overrides can spec non-standard ATR-mult gaps: 1=.5, 2=1.0, 3=1.5, 4=2.0, 5=2.5, 6=3.5, 7=4.0, 8=4.5, 9=5.0.

BgnV overrides for Toe allows 20%-60%, and allows 20%-180% for Cnfrm or Full (but prevents any combination of them from exceeding 200%). Both TP's will support a version of "SmartSizing" that potentially adjusts the Toe+Cnfrm or Full Entry sizes to balance wiggle-Risk exposure vs $Capital tied-up in trade, using rules that can be tweaked via Cstm overrides. The "nominal" Toe,Cnfrm,Full entry-sizes are multiples of 20 ... SmartSizing can tweak the nominal values up (if Risk relatively low vs Price) or down (if Risk high vs Price), such that the actual Size used is in multiples of 10%. I'll probably build in a limit so the adjusted size is always within +/- 10% of the nominal one chosen by the user. This adjustment will not affect the Add or Partial exit sizing ... Adds will always be multiples of 20, and PX|PG|PC exits will be user-specified multiples of 10 (this restriction is related to the "Robust TP" structure.

Top of the page Bottom of the page
JimDean
Posted 4/4/2019 3:23 PM (#9558 - in reply to #9556)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Addendums to the Cut&Grab description post that *had* said:
"separate PC|PG overrides can spec non-standard ATR-mult gaps: 1=.5, 2=1.0, 3=1.5, 4=2.0, 5=2.5, 6=3.5, 7=4.0, 8=4.5, 9=5.0" ...


I'm increasing that for PartialGrabs a tad, since 0.5xATR is just plain silly as a reasonable "grab" threshold-gap ... and since the old list had a hole (was missing 3.0, which no one noticed tsk tsk). . The new list is: 1=1, 2=1.5, 3=2.0, 4=2.5, 5=3.0, 6=3.5, 7=4.0, 8=4.5, 9=5.0 ... so, middle Partial Grabs override value is 3xATR.

It seems to me that the Partial Cut gap options should be a bit tighter than the Partial Grab options, since the "default" (recommended) Reward:Risk should be a bit better than 1:1 ... like maybe 1.25:1. Using that, the PC's list is: 1=0.8, 2=1.2, 3=1.6, 4=2.0, 5=2.4, 6=2.8, 7=3.2, 8=3.6, 9=4.0 ... so, middle PC override is 2.4xATR.

The FullGrab override options (virtual orders, based on Close price just as PG&PC's are), which logically must *always* be wider than the PG spacing. So, FG override options use the *same* list as PG's, but they ADD to whatever the PG gap is ... additional FG gap override options: 1=1, 2=1.5, 3=2.0, 4=2.5, 5=3.0, 6=3.5, 7=4.0, 8=4.5, 9=5.0 ... so, minimum override-based FG is 2xATR (1+1), max FG is 10xATR (5+5), and "5=middle" setting is 6xATR (3+3).

The new Cut&Grab SLIDER will provide 5 options for gaps and tightening-time ... neg uses same values but toggles off the FG, PG, and PC, leaving only the FC broker stops. Since the slider controls more than one thing (sort of like BgnV & EndV), the gap-options will be in pairs, with differing tightening-rates distinguishing each pair. That is, Slider 1-5 "Sml2Lrg" gap settings:
1 & 2 will both use 4x for FG, 2x for PG, 1.6x for PC
3 & 4 will both use 6x for FG, 3x for PG, 2.4x for PC
Slider=5=Lrg uses 8x for FG, 4x for PG, 3.2x for PC

The time-tightening settings will distinguish the components of each pair ... 1 & 3 will use fast tightening, 2 & 4 will use slow tightening, and 5 will use medium tightening. Tightening is "smart" ... that is, *no* tightening while profits are accruing at a reasonable rate, faster tightening when meaningful iterative losses are accruing, and medium tightening between those categories. Since the starting-points for FG, PG, and PC are significantly different, the tightening needs to be a fractional multipler of the starting-gap value, rather than a simple per-bar subtraction. Here's what I've tentatively decided on (see attached spreadsheet for various combo's analyzed):
1 & 3: gap tightening per "meaningful-additional-loss" bar = - 24% of InitGap /bar
2 & 4: gap tightening per "meaningful-additional-loss" bar = - 20% of InitGap /bar
slider5: gap tightening per "meaningful-additional-loss" bar = - 22% of InitGap /bar
... the "medium" tightening would therefore be -12%, -10%, and -11% respectively

A simple example might be a case where the second bar of a Long trade "pops up" a lot but not enough to trigger a Full Grab, then is followed by a consolidation where price doesn't really go anywhere. We'd want the Cut bands to tighten up and take out the trade (keeping in mind that the Stradicator logic probably will be "helping out" some, too). The default slider setting=3 assigns a "meaningful loss situation" tighening of -24%/bar, but since the example has the price staying pretty much flat, the "medium" alternative= -24/2= -12% would be used. This means that the Cut threshold would become *zero* after ~8 bars ... but since each bar has a bit of wiggle to it, the close probably would likely swing half an ATR lower than mean. The slider=3 setting puts the initial PC gap at 2.4x ... if we reduce that by ATR/2, then we need to tighten the band down to 1.9x to get a hit for a "flat" consolidation ... -12% of 2.4x =0.288x ... so reduction of 1.9x would only take 6.6 bars.

That example is illustraded in the bolded-box A17:G29 in the xls). Row 16 shows the associated Partial Grab multiplier (for a PG/PC Reward/Risk of 1.25). Row 30 shows the associated Full Grab multiplier (twice as wide as Partial Grab). The pink cells in col G shows Max/Min variancefor the #bars it takes to hit. Hopefully the meaning of the other fields is clear from the labels.

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

Finally, the FullCut options need to be established ... but since they are broker orders, they are locked in by the TP to fixed options. I mentioned earlier that all of the cuts and grabs will tighten as time passes ... for the locked-in FC's, that is done by making the gaps tighter after each successive Add (ie different "sections" of the Robust TP). The TP *can* provide multiple choices for FC's, but each choice adds another Condition row to *every one* of the (potentially hundreds) of Steps, so prudence is called for ;~).

For FullCut, the Initial multiples for Slider=1,3,5 will be 80% of the FullGrab multiples ... ie a nominal 1.25 Reward/Risk. Since the timing adjustment is not as "smart" as used for the FG, PG and PC, the slider-variance is linear: 1=3.2, 2=4.0, 3=4.8, 4=5.6, 5=6.4 ... these will be locked-in by the ATR-multiplier in the TP Orders panel, for each condition. The FC model will therefore require five Conditions per Step in the TradePlan.
In each new TP Add-section (Adds drop by 20% each time), those FC Conditions will tighten, since the trade has obviously matured more, and it's smart to become more protective of the progress. There are a maximum of four Adds (if InitAdd is 80%) ... so, for each new Add, the FullCut ATR-multiples will tighten by: 1=-0.4, 2=-0.5, 3=-0.6, 4=-0.7, 5=-0.8 ... thus for the fourth Add section (which will rarely be reached), the final FullCut gap-spacing ATR-multiples will HALF of what they started: 1=1.6, 2=2.0, 3=2.4, 4=2.8, 5=3.2

Overrides will be available for FullCut, but they ONLY will be able to specify Initial FullCut gaps amongst the five slider values. That is, if Slider=3 (for the FG,PG,PC settings), a manual override could force the FC to use the slider=5 setting.

Of course the PC's will be much tighter by that time too, so working together, they will help assure a "tidy" exit from the trade, hopefully avoiding being hit by big reversals or wild volatility that is common after the end of an Elliott Wave-5. Even if the full exit is not before that point, the Partial-exit rules (Grabs and Cuts) along with the tightening, will usually have reduced the position size significantly ... thereby minimizing the impact of a final big bar opposing the trade.

Another change since prior post: when Cut&Grab slider is neg, the FC and FG lines remain functional. The FC multiples won't vary (if the BgnV-Add slider or GuruV slider is negative), so in this case ... ie using the "Simple TP", the FC gap multiples will be halfway between the InitialAdd and FinalAdd lists, above.

Attachments
Attachments Cut&Grab Gap&Tighten.xlsx (18KB - 2 downloads)
Top of the page Bottom of the page
JimDean
Posted 4/16/2019 8:35 AM (#9567 - in reply to #9558)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
... recap of cleaned-up posts, w/modified approach to BarWndo input ...

Result of discussion re output spec for Both/Longs/Shorts ...

Too messy to fold into overrides, and also needs to be universal for Easy & Xprt not just Cstm. Distinctions between S & L patterns to use for trading, if any are desired, are handled by creating two sep Strategies, one for Long-Only and the other for Short-Only. We need one of the existing input parameters to clearly distinguish between B/L/S to support this as a part of the portable Stradicator paradigm.

Only sensible input for that is BarWndo, since it isn't normally fiddled-with, and doesn't change the wave-creation logic. The current input slider goes from 0-256 ... modify that input:

0-299 means Both Long&Short trades with output window spec 0-299 where 0= all possible
300-599 means Long-Only trades with output window spec 0-299 where 300= all possible
600-999 means Short-Only trades with output window spec 0-299 where 600= all possible
... the default is "Both" with ~7+months => 150 default

I've decided to limit the slider itself to the 0-299 "Both" range ... thus the user needs to type in (any version) an intentional value >=300 and <900, to limit the output to one direction or the other. In the great majority of cases, this will simply "turn off" one color (green or red) without affecting the other ... "pure" reversals are the only exception that I can think of ... if the "reversal direction" is the only one allowed, that bar will start a new wave ... but if "both" are allowed, that bar ends the prior wave without starting a new one.

The slider name should reflect the additional distinction:

BarWndoToCalculate becomes BarWndoOutTrdDirBLS
Top of the page Bottom of the page
JimDean
Posted 4/16/2019 9:31 AM (#9568 - in reply to #9567)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
UPDATED version ... old post deleted ...

Here is a pretty durn cryptic cheat-sheet for the various overrides ... the *only* slider without specifics (yet) is the Master. Note that this shows how comprehensive and valuable the Cstm version is ... the only overrides in this list that will be avail for the Xprt & Easy versions are the Guru-based Filter-spec's.

After that, I've also included a (hopefully more understandable) cheat-sheet that shows the impact of negative-slider values.

I added ONE NEW override feature that is not mentioned in prior posts ... the "X" override digit for BgnV. X specifies the max# Adds allowed. Routine *typically* applies a 20%-reduction-in-Add-size for each new Add-section in the TP (and internal stradicator logic), and since the max possible Add is 80% (via override or slider), there are up to four possible Adds. However, the user might want to limit that to just *one* add of only 80%, or maybe just *two* of 60%,40% (etc) ... this X input specifies how *many* are allowed. 0=no limit (can spec A=0, or make input neg, to kill Adds), X=1-3 causes the reduction-algorithm to work normally, but prevents more than that #of Adds from occurring, regardless of what the initial Add% is.

Furthermore (and this is the further-revised expansion-part ;~) ... the X input can also be 4, which says to use the reduction-method with no explicit Add limit, but reduction is 40% for each new Add, rather than 20% reduction ... thus X=4 with A=4=80% initial allows a second Add of 40%, but no further Adds since the next would be 0%. Similarly, with X=4 and A=3=60%, the second (and final) Add would be 20%. X=4 and A<=2 is the same as X=1 with A<=2 (ie only one Add). Finally, to complete the menagerie, X=5 means the second-Add-reduction is 60% - thus X=5 & A=4 means the first Add is 80%, and the second (final) Add is 20%. All other A-options with X=5 really mean the same thing as that A-option, paired with X=1.
Note that since the TP is hard-coded only to support a max of four Adds, and the Adds are all 20%-multiples, and the successive Adds always get smaller (if active), these two new X=4,5 options complete all possible permutations, without requiring the TP to be expanded.

Also, I allowed the BgnV overrides to turn off Adds (A=0), turn off Toe-In (T=0), or even turn off Confirm (F=0 with T>0). That latter case - a Toe-In *without* Confirm - allows 20-100% size "toe-in" Entry when an Alert fires OR when an initial BgnV-Bright fires, *without* allowing a followup Confirm-trigger to augment the size prior to a PXit. No additional Steps will be needed in either the simple or robust TP's to fulfill this ... and it seemed to be a useful option. Note that there is an alternative approach which does not ever enter when an Alert fires ... set F>0 and T=0.

I realize this may seem pretty confusing, but the idea of the Cstm version (and the entire paradigm) is to support the max possible flexibility with min# input-sliders, while sticking to a generic TP structure. The flexibility described above is imho a welcome addition.

The "main" changes to earlier descriptions are for the BgnV (#*20% size limits & X-limit), EndV (#*10% size limits and A=req'd prev PX% req'd), and especially CutGrab, which is all-new and very powerful, using all seven possible digits. Note that the 4-line CutGrab feature is part of the "stradicator paradigm" ... that is, its logic will be echoed for all stradicators (esp since the TP is hard-coded to match it). Also part of the paradigm: GuruV, BgnV, EndV, VFuz, BarWndo, PltRtn

Here is the "comment-style" cheat-sheet for the overrides ... followed by a cheat-sheet for the negative-slider impacts ...

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

*** LIST OF CSTM-VERSION OVERRIDES *** (save)

CumMethBasic2Refined- CCM: CC= C.C CapVmult (M=CumMeth)

=== GURU_TymFrmFst2Slo- Fltr1=FPPPPCG: C=CntlTyp, PPPP=parms, F=FltrID (G=GuruT)

MAvgSpeedPdsSm2Lrg- FfMmSs: Ff,Mm,Ss specific fast, med, slow MA pds

MAvgTypTight2Smooth- CSST: S.S=FMSsprd, C<>0 => use Wma&Ema for HullStk (T=MAtyp)

MASlopeLkbkThn2Wide- WwwL: Www= CumWndoPds (L=SlopeLkbk)

=== GURU_WavesSml2Lrg- Fltr2=FPPPPCG: C=CntlTyp, PPPP=parms, F=FltrID (G=GuruW)

BgnVotNetAddMny2Fw- VFTAX: V=7-3; Sz%*20: FullNtr 0-9, ToeNtr 0-5, Add 0-4; X=Mx#A's
... X= 0-5: 0=std @Add-20%; 1-3= max= 1,2,3 Adds; 4= 2nd=@Add-40%; 5= 2nd=@Add-60%

EndVotOppPxtFw2Mny- VPMWA: V=2-5; PXsz%*10(1-5); Med2Wrn#, Wrn2FX#; F=PrvPXfrac(1-9)
... F= reqPXb4Add as Frac of Add 1-9= 1/6, 1/4, 1/3, 3/8, 1/2, 2/3, 3/4, 1/1, anyPX

VFuzNgNoAPxOff2Big- PpHhh: Pp= Fuzz% (10-90), Hhh= Hist-Avg Pds (20-200)

CutGrabGapSzSm2Lrg- TGRFCUB: Tytn=22+/-4%; G&C=Xsz%1-6=0-50; Gaps: R+F=1-5; U=0.8-.0;
... B=BrokerFullXinitGap 1-5= 3.2,4.0,4.8,5.6,6.4 (@addTytns -0.4,-0.5,-0.6,-0.7,-0.8)

=== BarWndoOutTrdDirBLS- BbbTWww: Bbb=#Bb4Hre, T=0-5=B/L/S & FWeqtyStats, Www=WndoWdth

OutputReturnHelpPlot- EqtyVote SVCBR##: S~TimeG, V~VoteG, C=Cntl, BR=SmSiz(##=PltRtn)

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

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

CumMethBasic2Refined- negative uses Guts & TrueRange; -3=avg(4), -6=avg(8)

=== GURU_TymFrmFst2Slo- negative specs neg versions of three Experts

MAvgSpeedPdsSm2Lrg- negative uses independent FMS pds-sets for S,E,W,EH,WH

MAvgTypTight2Smooth- negative specs WE,WES,WS,ES,S calc methods

MASlopeLkbkThn2Wide- negative extends range to 4WL,5L,5WL,6L,6WL (WL=wma(lrs))

=== GURU_WavesSml2Lrg- negative turns off Adds and PX,PG,PC (ie Simple TP)

BgnVotNetAddMny2Fw- negative turns off Adds

EndVotOppPxtFw2Mny- negative turns off Wave-related Partial Exits (but not PC,PG)

VFuzNgNoAPxOff2Big- negative turns off Toe+Cnfrm

CutGrabGapSzSm2Lrg- negative turns off boundary-line Partial Cuts & Grabs (but not PX)

=== BarWndoOutTrdDirBLS- negative toggles on Equity-Vote Filtering (if licensed)

OutputReturnHelpPlot- negative used to specify Return type (pos=Plot)

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

yes, I know this is cryptic but all of this stuff is explained at length in prior posts ... explanations are lengthy so I didn't bother repeating them here. This is a handy-dandy cheat-sheett ;~)
Top of the page Bottom of the page
JimDean
Posted 4/16/2019 11:01 AM (#9569 - in reply to #9568)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Here is an updated snap of the Param's pane ... names in yellow have been modified ...

Most important need seemed to be to change the second-guru's name ... it used to be GURU_WaveSm2Lrg, but since this is part of the stradicator paradigm, I thought I need to move away from "Wave". I've been referring to this as the VoteGuru or GuruV (vs TimeGuru or GuruT), so that's where I started. Recently we added the CutGrab slider, which really has nothing to do with Votes at all, but is under the control of this guru. So, "VotBnds" was born ... "Bnds" can be thought of as either Bands or Bounds (Boundaries) ... either way, it refers not only to begin and end of waves / tradezones, but also to the Full and Partial Cut and Grab lines. I used Tyt2Lax since Tyt2Wyd and Tyt2Loose wouldn't fit.

The FuzVote modification removed the reference to the negative range (turn off Toe), since no other slider ref's neg ranges (again, this is part of the standard strad paradigm). I also tweaked the MAvgCalc and MASlope names a bit.

I changed the final two params to be a bit more helpful. BarWndoTrdDirL3cS6c reminds the user that even though the slider range only goes from 0-299, they can type in 300+ for Long-Only and 600+ for Short-Only ("c"=hundred). ReturnNgHelp0PlotPos seemed a little more helpful than just "OutputReturnHelpPlot".

Other alternatives for the 2nd to last: BarWndoLimDirL3cS6c or BarWndoOneDirL3cS6c or BarWndoSngDirL3cS6c

Are any of these changes objectionable ... that is, are the new names meaningfully worse than before?

Another thing I am considering would be to move the new CutGrab slider out from under the GuruVote section, into the final section ... that is, make it an independent expert from the three that actually do have to do with Voting. Rationale, besides it not being a vote thing, is that folks with Easy might like to have that control ... and since it's simple to understand (very graphically obvious) ... and also since it's a "TradeTight innovation" (the idea of "grabs" is unique to TT, imho), it might help to "promote" it to being more obvious. I'd change the section-header to "BandsAndOutputSpecs", if I did this.
I'm undecided, so please tell me your thinking ...

Should the CutGrab slider be extracted from the VoteGuru section and made visible for Easy?

(CVWeval V2 Parameters.png)



Attachments
Attachments CVWeval V2 Parameters.png (171KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 4/16/2019 11:51 AM (#9572 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3759
200010005001001002525
Location:
USA: GA, Lawrenceville
Please answer *both* bold questions from the prior post. Thanks.

Re the BarWndo name ...
I provided three other options. Are any of them better?

Keep in mind that the param labels are reminders, not full definitions. Once you "know" that L3cS6c means LongOnly starts at 300 and ShortOnly starts at 600 ... would the label be memorable, and would it be helpful?

The earlier version gave no clue as to the ranges ... ie 0-299, 300-599, 600-899 had to be "guessed at" from slider fiddling, or from looking up something in a PDF.

Another approach (sort of clunky imho) would be to longhand the numbers ...
"BarWndoOnlyL300S600" or "BarWndoLonly300S600"
Top of the page Bottom of the page
KenWilsdon
Posted 4/16/2019 12:07 PM (#9573 - in reply to #9569)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
I changed the final two params to be a bit more helpful. BarWndoTrdDirL3cS6c reminds the user that even though the slider range only goes from 0-299, they can type in 300+ for Long-Only and 600+ for Short-Only ("c"=hundred). ReturnNgHelp0PlotPos seemed a little more helpful than just "OutputReturnHelpPlot".

Other alternatives for the 2nd to last: BarWndoLimDirL3cS6c or BarWndoOneDirL3cS6c or BarWndoSngDirL3cS6c

Are any of these changes objectionable ... that is, are the new names meaningfully worse than before?


I prefer BarWndoTrdDirL3cS6c, with BarWndoSngDirL3cS6c being second. The other 2 are a bit more vague.

Another thing I am considering would be to move the new CutGrab slider out from under the GuruVote section, into the final section ... that is, make it an independent expert from the three that actually do have to do with Voting. Rationale, besides it not being a vote thing, is that folks with Easy might like to have that control ... and since it's simple to understand (very graphically obvious) ... and also since it's a "TradeTight innovation" (the idea of "grabs" is unique to TT, imho), it might help to "promote" it to being more obvious. I'd change the section-header to "BandsAndOutputSpecs", if I did this.
I'm undecided, so please tell me your thinking ...

Should the CutGrab slider be extracted from the VoteGuru section and made visible for Easy?


Sounds like a good idea.

I think your ReturnNgHelp0PlotPos is a little difficult. But not sure what would replace it if you want both +ive and -ive in the title.
Top of the page Bottom of the page
KenWilsdon
Posted 4/17/2019 12:34 AM (#9575 - in reply to #9573)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Would it be better to return to the more generic "OutputReturnHelpPlot" for the final param?

It might be better. That is clear.

Re moving Cut Grab ... I forgot to mention the "downside". If it's not linked to the GuruVote slider, then it will be easier for the user to "inadvertently" create tight restrictions re the Vote rules, while leaving the borders loose (or vice versa) ... without an obvious visual prompt pointing out the disparity.

Can you think of a significant number of situations where the user might want the vote rules to be "tight", but the Bands to be "loose" ... or vice versa?


Not offhand. But someone else may be able to come up with situations during testing.

But I would say the danger is there, even if it is under the GuruVote slider, if people are not consciously thinking about the vote slider and the Cut Grab being related. This could happen because there are lots of moving parts to the stradicator for people to consider.
Top of the page Bottom of the page
Jump to page : 1 2 3 4
Now viewing page 4 [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.