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. 

James 1:5 (NIV) ... If any of you lacks wisdom, he should ask God, who gives generously to all without finding fault, and it will be given to him.


Cumulative Volume Indicator DISCUSSION
Jump to page : 1 2
Now viewing page 2 [50 msgs/pg]
Jump to room :
JimDean
Posted 2/1/2019 4:31 PM (#9288 - in reply to #9287)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
Here are the Core snapshots that parallel (as closely as possible) the Xprt examples in the prior post. Note that the Xprt example has two Expert-overrides (one for each Guru) that cannot be duplicated by the Core routine.

Please study the panels, notably HP#1, and let me know if it makes sense.


(CVWcore A1 Parameters.png)



(CVWcore A1 HelpPanel -1.png)



(CVWcore A1 HelpPanel -2.png)



Attachments
Attachments CVWcore A1 Parameters.png (119KB - 0 downloads)
Attachments CVWcore A1 HelpPanel -1.png (369KB - 0 downloads)
Attachments CVWcore A1 HelpPanel -2.png (216KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 2/3/2019 4:33 PM (#9293 - in reply to #9278)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
COMBO POST ... I deleted the prior post since this one shows updated snaps. Here's its text:

2/2/19: Decent progress today. Ken says his Step8Fours will be ready tonight ... so it looks like I've got another "free" day or two before he gets me the Step8Threes as well.

I'm using that time to significantly expand and rearrange the Help panels ... there are nine so far, each pretty tall. After HP#2 which you've seen, #3 now gives a general explanation of "how" to use the program (ie Master, Gurus, Experts), followed by a 7-step synopsis of how the program does its calculations (all of this is brand new Help info). Then the next all-new two panels (completed) explain each one of the inputs, up to the final two, with as much detail as I thought might be interesting and useful.

Panel #6 begins with explanation of the versatile new output-window-extent input (2nd to last one), clearly explaining (I hope) its purpose, how it works differently for Plot and Return, and even the special negative-number input option. (prior panels explain optional neg inputs also). I still need to add a clear description of Plot#1 ... the big top band and three breakout strips, with all their colors and meanings and use, etc. Since this plot is likely to be the main one used, I'm going to try to polish the explanation well.

Panel #7 explains Plot#3 and Plot#3 colors and meanings and use, etc. It's not shown since I haven't yet updated it. Panels #8 & 9 will describe all of the 40 return options.

Once it's all done, and y'all have both proofread it carefully, I'll also create a PDF that contains the entire thing, maybe with some snapshots (but I don't want to go hogwild on illustrations).

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

2/3/19 Progress Update:

I'm still working on the Help Panels. Reviewed my prior-posted work, and cleaned it up as well as clarified a lot of things. Made a bit more progress forward, too, but still need to finish Plot and Return definitions. Also cleaned up RHS of plots, when a negative # used for second to last input.

Main "new" thing I did was to expand the info provided at the bottom of the HP#1 ... it now shows the Volume Cap multiplier, and the Vote-threshold for Warnings (dark red/grn) and Alerts. While doing this, I also provided for the Xprt user to specify the Volume Cap, not just turn it off. Help Panel #4 explains how (special typed values for MAmethod &/or SlopePds inputs). When those overrides (or the FFMMSS MApds override) are used, the HP#1 now is smart enough to show them correctly, and adjust its formatting accordingly so no word-wrap occurs. Of course, those overrides are only available to the Xprt user. This was all pretty messy to accomplish ... but it's done now!


(CVWxprt A1 Parameters.png)



(CVWxprt A1 HelpPanel -1.png)



(CVWxpco A1 HelpPanel -3.png)



(CVWxpco A1 HelpPanel -4.png)



(CVWxpco A1 HelpPanel -5.png)



(CVWxpco A1 HelpPanel -6.png)



Attachments
Attachments CVWxprt A1 Parameters.png (192KB - 0 downloads)
Attachments CVWxprt A1 HelpPanel -1.png (507KB - 0 downloads)
Attachments CVWxpco A1 HelpPanel -3.png (661KB - 0 downloads)
Attachments CVWxpco A1 HelpPanel -4.png (563KB - 0 downloads)
Attachments CVWxpco A1 HelpPanel -5.png (538KB - 0 downloads)
Attachments CVWxpco A1 HelpPanel -6.png (420KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 2/5/2019 8:27 AM (#9299 - in reply to #9293)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
Repeated post due to lack of response ...

Halloooo, out there! I haven't gotten any feedback about any of the work on the text of the Help panes, or for that matter, any about the Core vs Xprt distinctions on the Inputs ... nor on the extra internal-variables info that I've recently added on the bottom of Help pane #1. I really, really want to get this tied up soon ... I'll finish Help writeups today and hopefully will get the Master Patterns and tweaked Expert ranges defined as well (if I get Ken's Step8 by noonish, that is). I'm not posting stuff here just as a personal journal ... I really need your insights and proofreading, etc ... whether or not you are actively doing testing with the A2 DLL. At this point, you *don't* need to re-read all the prior posts in this long thread ... just the last 2-4 should do it. I'm at the stage now where things are pretty firmed up and I need to assure that the structure makes sense, and that the Help-explanations actually "Help". So, please "help" - thanks.

QUESTIONS:
(please answer the "New" ones #10-12 first, if you have limited time, but come back to 1-9 later)

1. Are the distinctions between Core & Xprt "reasonable"? That is, can you imagine that a goodly percent of potential users will prefer Core, and another goodly percent prefer Xprt? Note that Core will have a less expensive DLL that Xprt (maybe half?), but the subscription pricing for the Returns will likely be the same.

2. Are the extremely-compressed "reminder" explanations at the top of HelpPanel (HP) #1 reasonably useful, given that there's a lot more detail in later HP's? Any specific items that you'd suggest I tweak? (if so, please provide specific suggestion re alt text that fits on the line)

3. Are the ^ and * flags used on the bottom of HP#1 sufficiently clear and helpful? That is, can you understand from them what the "source" of the param-value is, for each of the 11 rows of inputs? (Note that there's plenty of extended explanation on HP#3 ... presume user has read it).

4. Are the "internal" variables which are output on the R side of each of those 11 lines on the bottom of HP#1 understandable (labels and values)? I've recently done a lot to update those, and there are some new ones since I last asked this question.

5. Is the verbiage on HP#3 clear? If not, please specify what needs improvement.

6. Is the verbiage on HP#4 clear? If not, please specify what needs improvement.

7. Is the verbiage on HP#5 clear? If not, please specify what needs improvement.

8. Is the verbiage on HP#6 (as far as it goes) clear? If not, please specify what needs improvement.

9. Approx 4 more HP's are planned, to fully describe all the Plot and Return value features (early forms of those are posted a while back) ... beyond those four, do you think there's a need for any additional HP's to cover some other aspect of the program? (keeping in mind that I can't include graphics on the popups, and that I do plan an intro walkthru video)

=========

NEW QUESTIONS, for my work today ...

10. I'm considering a further limitation/simplification of the Core routine ... instead of nine options for the Cumulation method (VolObOgVpVgAdAtNiNt), it would have five (CumMethVolObvVptAcdNii) ... none of the Guts or TrueRange variants would appear there. Do you think that would be wise / helpful for the person desiring simpler choices? Note: that input is *not* part of any Gurus, but is defined by Master patterns.

11. Amongst all the Expert inputs that are under Guru's, WtdAweExpAesSimMix is the only one that is not "qualitative" ... that is, it explicitly chooses one MA calc method or another (from 6). Would it be "better" (ie easier for the user to work with) if the I changed the label to be qualitative ... ie: something like "MAcalcMethReact2Smooth" (1-5)? (Note that I'd allow for optional override using negative manual inputs to directly specify one of the options.)

12. Currently, the #6 "Mix" option for the MAmeth input is not part of the Guru or Master mapping ... thus not avail in Core at all (Mix is the average of all three methods Wma,Ema,Sma). Arguably (tho I'm not sure which side I take ;~) it maybe should be the "default" ... ie instead of having Ema in the center of the slider, it maybe should be Mix. Any opinions on that?

THANK YOU for your help!
Top of the page Bottom of the page
JimDean
Posted 2/5/2019 6:06 PM (#9300 - in reply to #9299)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
Here are some scattered conclusions that Ken and Salim and I came to, from studying their comprehensive step8 results ... THANK YOU both for Skype time ... especially Ken (till 5:30p)

1. Modify MApdsFMS to make periods longer duration ... current 8, 12, 16 => 12, 16, 20

2. Current CumVol Meth spectrum and default is good (all choices are decent ones)

3. FuzzyBand need more & wider options ... current 0,10,20,30,40% => 0,10,25,40,55,70,85%

4. Bgn-Vote needs lower options, for filtering ... current 5, 6, 7 => 3, 4, 5, 6, 7
... filtering best for Bgn=3,4,5 and End=3,4; trading best for Bgn=5,6,7 and End=2,3...
5. End-Vote needs shifted options, for filtering ... current 1, 2, 3 => 2, 3, 4

6. SlidWndo CumVol calc must => WMA (curr~SMA) ... likely WMA pds= 30,60,90,120 (test!)

7. Make EMA use Pds*5/6 or so, as comparable to WMA|SMA

8. Reduce 6 MAcalcMeth options to 2: EMA versus WS=(WMA+SMA)/2

9. Combine MA CalcMeth into MAperiods slider => 12WS, 12E, 16WS, 16WSE, 16E, 20WS, 20E

10. Reduce Core choices for CumV Calc Meth from 8 to 4 (just classic choices)

11. 60 PatternMaster choices same for both Core & Master

12. 3 Plot choices for Core (Band, B+3Strip, Detail) and Guru (B+3Strip, B+2Strip+2Histo, Detail)

==========

These changes should make all of the patterns better, and eliminate less-useful patterns, and simplify the input choices, and make clearer distinctions between features/benefits of Core vs Xprt.

Here are rough-cut samples of the two new input panels ...



(CVWnewC.png)



(CVWnewX.png)



Attachments
Attachments CVWnewC.png (139KB - 0 downloads)
Attachments CVWnewX.png (172KB - 0 downloads)
Top of the page Bottom of the page
RobertPfoff
Posted 2/6/2019 12:50 PM (#9303 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Spectator

Posts: 5
0
Location:
USA: PA, Warrendale
1 yes, but this is based on the pattern master having all of the useful variations I would likely use, I can see using this as my main slider

2 yes

3 took me a while but I got it, to me ppm = parts/million

4 not really but probably as good as you are going to do given space constraints, detailed information is available later

5 probably but definitely in the weeds

6,7,8 same but will need to spend more time using to be sure

9 sounds good, understanding the return value is critical to use as filters and in atm

10 I like guts and would like to see it in core

11 I like the MAcalcMethReact2Smooth as long as all of the other options are available

12 Not sure, would have to see how it performs. Given I am likely to be a core user I would like to see it included :-)

Rob
Top of the page Bottom of the page
KenWilsdon
Posted 2/6/2019 2:48 PM (#9305 - in reply to #9299)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 17
0
Location:
: ,
Hi Jim,

I spent about 2 hours going over the help panels, and probably another hour or two writing this post. Overall, the help panels (to date) provide a pretty clear and comprehensive overview, description of each slider, the inputs (and I expect the Output panels will be the same high quality). This is in answer to your 12 questions in the previous posts. We have covered the last 3 questions in our Skype session, so I will not repeat those here.

Here are some specific suggestions, not criticisms:

Q1. Are the distinctions between Core & Xprt "reasonable"? That is, can you imagine that a goodly percent of potential users will prefer Core, and another goodly percent prefer Xprt? Note that Core will have a less expensive DLL that Xprt (maybe half?), but the subscription pricing for the Returns will likely be the same.

A: Yes. On Core Help #1, I see you have one extra blank line b4 Actual Inputs and Derivatives. Maybe after Actual Inputs and Derivatives, having something like "Core version adjusts Expert Values below. Adjustable inputs available in Xprt version." is one use of this blank line that would help clarify the differences.

Another (diferent) option is move your line on Help Panel 4 at the end of the section Preferred Pattern Master starting with "CVWCore Includes..." here. That would clarify what they are looking at on Help Pattern 1.

On Xprt Help #1 (as this differs with Core in the posts above), I would recommend the following to use the blank line, after the Warmup line: "Detailed Overview,Definitions,Input,Output: Help Panels #3-[last help panel #]". That would clarify the help panel & outputs they are seeing, for brand new customers. Your help method is not used by Nirvana. If this is the first time someone is buying a product from you, this will encourage them to start there to understand the program, and remind them of your extensive help when they come back later. It will also help those more experienced, who may set this aside for a while, and come back to try to refresh their memory.

Q2. 2. Are the extremely-compressed "reminder" explanations at the top of HelpPanel (HP) #1 reasonably useful, given that there's a lot more detail in later HP's? Any specific items that you'd suggest I tweak? (if so, please provide specific suggestion re alt text that fits on the line)

A: I still have problems with the name "VolObOgVpVgAdNiNt". I understand that this provides each of the 8 slider positions definitions, but it is confusing for people who like simple (probably Core users).

I have 2 options. Maybe something like "CumVolCalcMeth" would be clearer, and the Actual Inputs at the bottom of Help Screen 1 shows what is actually used, if people care (Some will just want it to work right, and not care so much the names, but the slider would then let them know what it does more clearly). This would be much clearer for Core users especially, and if you are not giving Core all these options, then this (VolObOgVpVgAdNiNt) would not accurately reflect what they could input anyways.

2nd option if you don't like the first. I am assuming from the other help that the NiNt portion refers to the Bostonian III method and the True Range selection. As Chaikin has a N in the name (also at the end), Granville has a N, and Bostonian has a N in the name at the end, it is not intuitive which it refers to. Maybe rename it VolObOgVpVgAdBiBt (I know Fosback has a b in it, but as the first letter, it would be the logical assumption that it would be Bostonian).

Q3. Are the ^ and * flags used on the bottom of HP#1 sufficiently clear and helpful? That is, can you understand from them what the "source" of the param-value is, for each of the 11 rows of inputs? (Note that there's plenty of extended explanation on HP#3 ... presume user has read it).

A: It is not super clear on Core help panel 1, but it is clearer on HP 3, if people get that far.

I think this will fit. Maybe reword HP 1 in two spots. Add: "Preferred Pattern Master 1-60 sets (^)...", and "Gurus set (*) value for next 3 Expert Params...". I would leave the explanation at the Actual Values section in as well (now I am referring to Xprt version help 1, which is different here in the post above). Between the two, it should be clearer. This is a crucial part of understanding what they are seeing in the Actual Values section, and the extra emphasis should help.

Q4. Are the "internal" variables which are output on the R side of each of those 11 lines on the bottom of HP#1 understandable (labels and values)? I've recently done a lot to update those, and there are some new ones since I last asked this question.

A: Yes, they seem clear enough to me.

Q5. Is the verbiage on HP#3 clear? If not, please specify what needs improvement.

A: Yes. It seems clear enough.

Q6. Is the verbiage on HP#4 clear? If not, please specify what needs improvement.

A: Under "Options 10s digit ...", when I read it, I wasn't sure whether this refers to just +ive or -ive numbers. Maybe add (+), (-), or (+/-) to explain.

Q7. Is the verbiage on HP#5 clear? If not, please specify what needs improvement.

A: I know you don't have an extra blank line on this panel, but the Cumulatiion Calc Methods NEEDS to be better distinguished somehow. If you have the ability to Bold or Underline in the help file (not sure you do), then this would be the place to do it, if you can't find a line. This is the name (VolObOgVpVgAdNiNt) I have the greatest problems with, and because it almost seems to blend in with the paragraph before, as I scan help for it, I miss it. If you keep that name, then this MUST be distinguished so that users can scan and find it on this help panel. IMHO, this is the one that needs to be distinguished the most on this page, not buried in the previous paragraph. You say it is Crucial, yet it is buried. I would rather have another section buried into a previous paragraph rather than this one.

While it is important, perhaps a line that could be freed up would be, "This expert input and the next one..." because you duplicate this fact on the next help panel. This is the better place for this (not the next page, as you can't go backwards in the help), but if you need a line, this is a suggestion.

Another suggestion: Under this section, in points 1-9, put your abbreviations before the explanations, but after the numbers, like:

1. Vol:Capped V...
2. Ob:Granville OBV...
3. Og: etc.

I think you have room on the lines (looking at the 3 ... at the line before these points), and that would explain the difficulties I have with the term VolObOgVpVgAdNiNt.

Q8. Is the verbiage on HP#6 (as far as it goes) clear? If not, please specify what needs improvement

A: It looks pretty good to my eyes. No suggestions here.

Q9. Approx 4 more HP's are planned, to fully describe all the Plot and Return value features (early forms of those are posted a while back) ... beyond those four, do you think there's a need for any additional HP's to cover some other aspect of the program? (keeping in mind that I can't include graphics on the popups, and that I do plan an intro walkthru video).

A: I can't think of anything right now. Seems pretty complete.

Hope that helps.
Top of the page Bottom of the page
JimDean
Posted 2/6/2019 3:08 PM (#9306 - in reply to #9305)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
Thanks Ken for your careful review and thoughtful points and suggested alternatives.

Here are a few quick points that might help clear up or satisfy some of your concerns ... when I get back to CVW (working on HallMA studies now), I'll address them point by point with some kind of hopefully helpful solution.

A. I *am* going to make an intro video ... I will walk thru all the inputs, and things like ^ & *, and various calc method diff's, and various output alternatives. It will be fairly long but will cover most everything someone needs to "get acquainted". So, the first time they hit HP#1 or the outputs etc, they should have already gone thru the video. If they are unwilling to view that video, my general feeling is "tough bunnies ... I'm not going to repeat the same info endlessly for lazy people".

B. In the video, I am going to emphasize that everyone *must* read all the Help carefully, at least once. I'll be providing a PDF with all the help panels and a few snapshots to serve as reference. I don't expect people to memorize anything, but I do expect them to know generally what's there (ie one section for each input and output, etc) ... so they can jump back and remind themselves of the detailed explanations whenever they need to. If they are unwilling to ever sit down and read the PDF, then again, "tough bunnies". The PDF will not be all that long ... just one Help Panel per page, or so.

C. The HP#1 is not supposed to stand on its own. I hopefully expect that it will be understandable once the other HP's are read ... I will try to make sure that all the RHS info on the bottom of HP#1 is described in the appropriate place in later HP's. HP#1 is supposed to be a "reminder" of what the funky or generalized qualitative input-param's actually mean. It's easy to pop up ... just slide the last param to zero.

D. I agree re the illegibility of the VolObVp... variable. At this point, I'm tentatively planning to change it so that it goes from -4 to +5, where +1 to +4 is Obv,Vpt,AccD,IntrII using classic C & H-L ... and -1 to -4 is the same list, but using Guts and TruRng. I'm about 80% decided to disallow the negative values for Core. +5 will be plain old Volume (the current =1 input). Note also that the bottom of the HP#1 panel completely lists the formula for the selected CumMeth ... removing all doubt. So, whatever the abbreviation is, Help is just one slider away.

BTW:
Imho, my method of popup panels is FAR superior to N's very sparse and generalized help manuals. Yes, their manuals are prettier and easy to read, but they are not as easily accessible nor do they have hardly any "nitty gritty detail" in them about what's going on. Jmho, fwiw.

Thanks again!

Top of the page Bottom of the page
JimDean
Posted 2/6/2019 5:39 PM (#9307 - in reply to #9303)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
Thanks for the responses, Rob ... very helpful! And thanks, Ken +Salim for the skype call.

Re the MA calc type ... take a look at this new thread:
http://tradetight.org/forums/thread-view.asp?tid=1436#M9302

I'm seriously considering switching the entire paradigm over to using the Exponential Hull MA (ie EmaH) ... visual Skype testing with Ken (& a little Salim) ... in lieu of the updated 12,16,20 (used to be 8,12,16) for the existing MA-calc options, for the EmaH the periods would be much longer ... more like 15, 30, 45 ... less lag, plenty smooth, better consolidation zones. By doing that, I can simplify the inputs as shown in the post just before this, eliminating the slider for MAcalc type ... and *likely* improve the results re lag/chop/dir.

During Skype testing, I didn't bother fiddling with the fuzz-factor settings ... the conclusions used a flat 50% of the fuzz SMA basis for both Slope and Stack ... but in CVW (and my test routine), I can assign different fuzz %'s ... that may help.

Snaps show EmaH with 15,30,45. The VotHullMA routine is just for testing. The Votes show up on the bottom. When the "curve" is blue, that means consolidation ... green/pink are bull/bear. The tricolor MA's on the price chart are colored based on agreement of slope and stack rules for that MA ... if they don't agree (re fuzz), then it's the intermediate color. If they agree up/dn, then the color is bright/dim. (presumably you understand the paradigm by now ;~)


(EmaH 7 Sym Tests.png)



Attachments
Attachments EmaH 7 Sym Tests.png (174KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 2/9/2019 1:07 PM (#9312 - in reply to #9306)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
I've begun the significant amount of reworking of inputs and calculations, based on the results of testing (more eval to come), and the feedback y'all have given me. The prior posts showed at least approximately how the inputs would be rearranged ... this post focuses on Help Panel #1. I'm trying to incorporate the various suggestions that Ken made, including mentions of the other help panels, better hints at how the Master > Guru > Expert defaulting happens, and a renamed input for the CumMethod.

NOTE: the MA-calc method input (ie Wma,Ema,Sma) is now "kaput" ... and the CumSlidingWindow input is now "under" the first TimeFrame Guru in its place. The SlidingWindo calcs are radically changing, to use a WMA-like forward-weighted approach, so that when bars "fall off" on the LHS of the window, it doesn't create a "surprise" on the RHS. This means that Plot#3's pink/cyan histo's that are *below* the zero line, representing what is "backed out" with each new CumVol bar increment, will be a net of all the partial-subtractions of the prior-bars' weighting-reductions.

The MA-calc method now *defaults* to Hull Ema, based on the testing we did during the Skype call ... so no explicit Expert slider is needed. However, since I want to provide maximum flexibility for the Expert-version owner, I'm going to allow any of the other existing methods to be forced by the user, if they input negative "FfMmSsT" for the MApdsFMSorSm2Lrg input ... that is, Ff=fast pds, Mm=med, Ss=slow, and the new T= calc type ... 0-9= HullEma, HullWma, Hull(W&E), Wma&Ema, Wma, Wma&Sma, Sma, Sma&Ema, Ema, Wma&Ema&Sma ... this is a "Salim-type-gimme-everything" solution (note "&" means to average 2 or 3 separate methods).

I have not fully completed all revisions to the Expert & Guru names and definitions yet ... this sample shows the changes to the first several lines, and the section heading etc for the bottom half. Note that I also added a report of how many plot-bars are output ... default is 126, but if left zero, this helpfully tells what the max# possible is, with the current settings and #Loaded bars.

The second line only appears when it's applicable ... I have to leave vertical room for it. This panel is the absolute-max height ... I can't add any more rows to it, without making it impossible to use on a display that is 720-pixels high (lots of smaller laptops have this limitation).

The input panel is also shown ... note that one Guru is defaulted while the other isn't, and that one Expert under each Guru is overridden. This helps demo how the ^ and * prefixes work.

What do you think? Ken, does this accomplish most of what you hoped for?


(CVWnewX Parameters.png)



(CVWxprtN HelpPanel -1.png)



Attachments
Attachments CVWnewX Parameters.png (171KB - 0 downloads)
Attachments CVWxprtN HelpPanel -1.png (530KB - 0 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 2/9/2019 1:24 PM (#9313 - in reply to #9312)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 17
0
Location:
: ,
Hi Jim,

I was doing a quick break when I saw this forum post. I looked at the help panel, and it is SO much better! I don't think I have any complaints about it. It seems clearer to me now.

The other improvements you mention in the post sound logical and worthwhile.

Now back to work!
Top of the page Bottom of the page
SalimHira
Posted 2/9/2019 1:33 PM (#9314 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 156
1002525
Location:
USA: MD, Columbia
Yes ... I concur with Ken, looks exceptional and I could follow thru very easily in the help manual too.
Top of the page Bottom of the page
RobertPfoff
Posted 2/9/2019 8:30 PM (#9315 - in reply to #9312)
Subject: Cumulative Volume Indicator DISCUSSION



Spectator

Posts: 5
0
Location:
USA: PA, Warrendale
Looks good to me
I don't fully understand the plot return controls but haven't had any instruction on them, I'm sure it should make more sense after I understand it
Should there be a ^ in front of the 3 on Guru_TimFrmFst2Slo?
Rob
Top of the page Bottom of the page
JimDean
Posted 2/10/2019 3:29 AM (#9316 - in reply to #9315)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
Hi Rob

There are so many Return options that I didn’t try to expand on them in this panel - there are two other panels devoted to that. Of course the three plot options are visually obvious - colors etc are explained in two dedicated panels later.

Re the Guru_TymFrm “3” - please note that the slider on the input pane is set to 3, not to zero - so, it’s overriding the Masyer setting for that slider. The “^” only appears when the input slider is zero, denoting that the Master pattern is in force there.

Note that two of the Experts related to that nonzero Guru input have zeroed sliders. They have a “*” on HP1 since the Guru has “taken over” from the Master regarding those two - the Guru rules set their values.

Hopefully that clears it up for you. Thanks for the feedback.
Top of the page Bottom of the page
JimDean
Posted 2/13/2019 7:37 PM (#9340 - in reply to #9316)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
After getting thru the Spreadsheet Skype, and making minor label-fixes to the BE templates, and running Camtasia to create MP4's, and uploading them to Vimeo (fairly long process ... why I avoid it normally) ... I finally got back to implementing the planned mod's for CVW.

Biggest thing today was adding three new CumVol Calc Methods ... a "Mix" of the classic 4, a "Mix" of the GutsTR 4, and a "Mix" of all 8 (latter two only for Core). That's all in now, and working fine ... the input slider goes from -6 to +6, with pos/neg 1-5 being parallel calcs, where neg=Guts|TR and pos=C|H-L; +6 is raw-volume, and -6 is Mix of all 8; +/-4= Mix of the ObvVptAcdNnn (ie averages)
Got all excited ... found an OT Parser bug ... weird results until I changed (C-O)/(H-L) to (C-O)/ (H-L) ... yup, just added a space. That is NOT an OLang requirement, btw

I tested the BgnVot & EndVot for wider ranges (Bgn=3-7 and End=1-5) ... I couldn't see any benefit in doing anything different than the 5-7 and 1-3 in VolEval. BUT ... I did allow for neg-overrides for either of them, to force 1-7 votes for either. ALSO ... I think this will really help ... I modified the param names for them to indicate which settings to use for Filtering, which for Aggressive trading, and which for Conservative trading. New labels are:
BgnNetVotFltrAgrsCnsv 1-3 ...and... EndBadVotCnsvAgrsFltr 1-3

I also revised the HelpPanel #1 for expert ... added an extra line under the CumMethod input (#2) to clearly explain the pos & neg values, and the new Mix values. At least I think it's clear ;~)
Improved some other HP#1 output-lines in minor ways as well (still more work upcoming for it).

I made some decisions about how the MAspeed and MAslope inputs would be changing ... basically covering a similar range of values (adjusted based on our tests) ... but having 1-5 sliders instead of 1-3 sliders for each. Here is the new mapping:

MAspd (1-5) now def to EmaH: medPds=27,30,33; tmwSprd=13,15,17: 1-5=25t,27m,30m,33m,35w
... that is, "25t" means the FMS spread around 25 will be +/-13; "35w" means FMS= 35 +/-17
... note that the HullEMA requires much longer periods (from testing) than the existing Wma, etc
... negative override FfMmSsT explicitly defines FMS pds, and one of ten MAcalc method-types

Slope (1-5)= LRS(2), wma(LRS(2),2), LRS(3), wma(LRS(3),2), LRS(4) ... neg-override for Pds & Meth
... negative override PpM explicitly defines Slope pds, and M=1=LRS(Pp), 2=wma(LRS(Pp),2)
... the variants in method should offer a smooth alternatives from existing LRS(2,3,4) options

Here are the updated input and HP#1 for Xprt ...


(CVWnewX Parameters.png)



(CVWxprtN HelpPanel -1 (stdHdr).png)



Attachments
Attachments CVWnewX Parameters.png (174KB - 0 downloads)
Attachments CVWxprtN HelpPanel -1 (stdHdr).png (452KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 2/17/2019 9:44 AM (#9344 - in reply to #9340)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
Progress report, as of 9am Sunday ...

Lots of work done to implement Hull MA's ... for many reasons. Done, and efficient, and accurate. Very complex to do iteratively for fast calcs, and double-precision for many-sigfig Volume calcs. Learned from observation that Hull Xma slopes are useful but Hull Xma stacking is squirrely since lines often very close together during trends, SO, default Hull eval uses Hull Xma slope and plain Xma stack (X = W &/or E). For Plot#3, the plain Xma MA's are plotted, but their slope-colors come from Hull calcs. This separate-slope-stack Hull method can be overridden by making the first GuruTF negative.

Adjustments made in the process:
1. put MAcalcType slider back in under the first GuruTF control ... ten (+3) different options now!
2. moved CumV Window slider outside Gurus, under CumV calc type, since need to test WMA change
3. senseless to use same FMS MApds-sets for every CalcType, so researched sep for S,E,W,EH,WH
4. lots of negative overrides (every expert and one Guru) for Xprt version, almost all noted in HP#1
5. expanded Slope from 1-3 to 1-5 (good) options ... 1,3,5 same with 2,4= WMA( LRS(2|3), 2 )
6. after much thot & testing, kept Fuzzy% slider as-is, rather than expanding the range above 40%
7. Vote sliders: Bgn 1-3 => 5-7, End 1-3 => 1-3 ... renamed as AgrsCnsvFltr (& Guru: Fuz similar)
8. Many tweaks to HP#1 ... bottom panel is much "smarter" re diff MA meth&pds, and overrides
9. Improved Plot#1 (band+3strip) output colors, and made it very "squishible" down to just the band

Discussions with Ken last night resulted in a hopefully-sensible and do-able set of tests. I'm moving back the completion deadline to midnight Wed, so that I can take time today to finish up. I'll discuss the meaning of the info in the email with you, likely Skype, before you start on Monday morning. Three phases of ~7 hrs each, one phase/day (I must process #1 to prep #2, and #2 to prep #3).

Still to do for me:
a. implement fwd-wtd sliding window for CumV calc, to eliminate prob with RHS sudden drop-off
b. prelim CumV Window chart studies to determine approp range, and which Pds for which Tests
c. expand Master slider to map all the tests out, so that all guru & expert sliders =0 during tests
d. compile for distribution ... but in a way that's easy to tweak later
e. set up spreadsheets for various tests, and write vote-SBAS descriptions

Here are snapshots of the new Param panel, and the updated Help #1 & #2 panels ... note that Help1 bottom has many variants, depending on inputs ...


(CVWeval Parameters.png)



(CVWeval HelpPanel-1.png)



(CVWeval HelpPanel-2.png)



Attachments
Attachments CVWeval Parameters.png (173KB - 0 downloads)
Attachments CVWeval HelpPanel-1.png (578KB - 0 downloads)
Attachments CVWeval HelpPanel-2.png (275KB - 0 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 2/17/2019 3:20 PM (#9345 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 17
0
Location:
: ,
Hi Jim,

Looks good to me. Some good improvements going on. Great work!
Top of the page Bottom of the page
JimDean
Posted 2/17/2019 4:02 PM (#9346 - in reply to #9344)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
Thanks Ken!

Good news first ...
a. I've got the FwdWtd window for the CumV in place now (instead of the unweighted sliding window that caused us so much confusion before ... its slider has a *huge* effect on the plot)
b. Prelim checks of the effect of the CumV FW Window size, from 200 periods down to 60 periods by 20's (prior sliding window varied from 110 to 50) => VERY LITTLE sensitivity to window size
... "b" is very good news ... means 95% likely that I can ELIM that slider, and tie to MApds internally
c. I got tired of having to squish the Xprt plot#1 to make it look like the Core plot#1 (ie a single band without other strips etc) ... so I modified things: Plots 1,2,3 are now identical for Core and Xprt (like Core was before), and Plot #4 is only avail for Xprt ... it's the cool one with Band on top, then slope histo + 3 component-vote curves, then two skinny BarVote strips, then stack histo + its three component-curves.

Bad news ...
* I'm wrassling now with a knotty issue that Salim pointed out earlier, but I'd forgotten about till about 2 hrs ago. He discovered with VolEval that if you hold all inputs constant, and just change the BarsToCalc (second to last input) from say 126 to 250 or whatever, that the Wave-band will sometimes CHANGE in the final 126 bars ... usually just a little bit, but occasionally fairly obvious. This should not happen AT ALL ... the "bounded" EMA's etc and exhaustive Warmup calcs should prevent that. But, it's still happening. This means that I literally have to check, often with debug message outputs, every calc section in the algorithm to track down where it's biting me. Probably once I find it, the fix will be simple. But it might take me several more hours to find it. Argh.

Your POV ...
"b." above means that the tests which planned for 2 CumVwindow alternates for all the phases ... will disappear. That means the number of tests for all three days will be CUT IN HALF. Yaay.
However, if I run out of steam tonight, I may have to delay release again, maybe till around 2p EST on Monday or so. Hopefully that will still allow enough time for y'all to do phase one before the end of Monday.
Top of the page Bottom of the page
JimDean
Posted 2/18/2019 6:14 AM (#9348 - in reply to #9346)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
REVISED ... (note: if you get a notification email, *always* click link to read it since I often tweak the post after it's initially sent ... treat the text in the post as a hint for what it's about)

I sent an email last night with this info in-brief ... also, that email has notes about some needed fixes, and (important for YOU) the revised specs for the test phases on three sequential days) ...

Yesterday Ken & I planned out some visual flags to denote Initial 100% Entry, up to two 50% AddOns, up to five 33% PartialXits, and one FullExit for any given Wave-Trade. A given Wave Trade always has an Initial Entry and final Exit ... may have 0-2 Adds and 0-5 PXits. Later this year, I will release a TradePlan that supports this kind of dynamic scaled in/out process.

These events will be denoted by dots on the wide top WaveBand. Black dots on Pink and Lime will denote Entry and Adds; White dots on DkRed/Grn will denote PXits. Make Return value for "-1" output option be negative on any bar that has one of those events ... color of the bar, and state of prior bar (ie whether in active trade) makes sense (Ent,Add,PX,FX) clear to calling OLang shell-program or OScript for Scan, Stop, etc.

Rules:
1. Initial Entry on first Lime or Pink bar, after a Navy or Blue/Purple Alert bar
2. PXit: 1st dkred/grn that hits, then if no pink/lime, wait two bars & PXit again next dkred/grn
3. Add: 1st lime/pink immed aft NavyBlue, or >=4b after prior lime/pink (dk/med grn/red between)
4. PXits & Adds can be in any sequence in a given Wave, based on rules above
5. When enough PXits hit to wipe out balance of shares from Entry+Adds, treat as FinalExit

MAYBE: if a PXit wipes final shares of a Trade, then force WaveBand to be Black on that bar (no dot)

Eventual NFX shell routines (System,Filter,Stop) will not be "required" to use these signals, but they will be the "native" mode.

MAYBE: Xprt version users will be allowed to input a negative VoteGuru value to change the rules re bars between PXits & Adds, and/or sizes+max#'s of Adds & PXits. Won't do this till later, if at all.

WHAT DO YOU THINK? If you have comments, questions or suggestions, please reply ASAP.
Top of the page Bottom of the page
SalimHira
Posted 2/18/2019 10:28 AM (#9351 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 156
1002525
Location:
USA: MD, Columbia
If u do decide to incorporate the feature, pls consider also, if at all possible, toggle btwn what u hv suggested above that that has all the options but can switch to also.....only full entries & full exits (most users geared towards). Or simply have full entries and full exits to keep simple. Just a thought coming to mind.
Top of the page Bottom of the page
KenWilsdon
Posted 2/18/2019 10:48 AM (#9352 - in reply to #9348)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 17
0
Location:
: ,
Hi Jim,

Looks good.

I assume on Rule 2, that the wait 2 bars means the 2nd Pxit will follow 2 full bars (similar to an Nbar exit in N), and only then trigger on the third or later bar that is dkred/grn, so that the Pxits will be not less than bar 1, 4, 7 in a downtrend, as we discussed on the phone call.

The first MAYBE that you included at the beginning of the line, would be a good visual feature to have a black bar, if this will be a plot option in Xprt ( even if trade restarted in the direction of the trend after the 3rd Pxit, would be good to wait one bar in case of chop or consolidation zone after longer reversal Pxit move).

Second MAYBE would be a nice feature for tinkerers, or if a particular symbol has a different pattern on wave 2 or 4, but I agree it would not be necessary on a strictly mechanical system of NAPF.
Top of the page Bottom of the page
JimDean
Posted 2/18/2019 10:54 AM (#9353 - in reply to #9351)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
Hi, Salim

The "feature" is *necessary* for the phase 2 and phase 3T tests (see emailed description).

This is just an indicator, so I'm not sure why a "toggle" would be needed ... you could just ignore the dots, and think of a black-bar's background as being dark red/grn.

However, as I said, eventually I will allow Xprt to modify the rules for the Adds & PXits, via a negative manual input of the Vote Guru ... probably something like:

-MAPG, where
M= Max# Adds (0=use A value),
A= Entry%/Add% (2=50%),
P=Entry%/PXit% (3=33%),
G=Desired Guru# (1-5)
... If A &/or P are zero, that would turn off the Add &/or PXit feature.
... Nonzero M permits max sum of Adds to be > or < Entry

There are other kinds of scenarios but this covers enough I think.
Top of the page Bottom of the page
JimDean
Posted 2/19/2019 10:31 AM (#9356 - in reply to #9353)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
I've been giving more thought to how the Adds & PXits should be displayed and "controlled" ...

1. specifics of how the Stradicator is *used* are the purvue of the NFX "shells", not the Strad indic
... rules re *when* events occur make sense for Strad, but *not* rules re position-sizing %'s

2. Strad plotting of Entry,Add,PXit,FXit is to help user "evaluate" ideas (or for discretionary traders)
... Dots on WaveBand for Plot#2 & #4; TradeLines on PricePane for Plot#4 (CVWxprt only)

Email last night described the PricePane TradeLines ... they will be *very* helpful for Testing ...
... Straight Line: Entry C to FXit C (or HreC) ... Line color: Long= DodgerBlue, Short= Gold
... FatDots on that line @bars for Adds & PXits ... Blue means buy shares, Chocolate means sell
... ... (Long Trade Add=Blue Hash, Short Add=Brown; Long PXit=Brown, Short PXit=Blue)

=======

Default logic for when Entry, Adds, PXits & FullX appear:
... Max of two Adds; when Pink/Lime appears after a PXit plus 2 more non Pink/Lime (ie for pullback)
... Max #PXits = 4 + #Adds*2; on 1st darkred/grn; repeat on dark aft 3 non-bright, or 1st aft bright
... Navy(or opp Lime/Pink)=Full Exit, OR after MaxPXits (assumed for logic: PXit=25% & Add=50%)
... ... MaxPXit case: WaveBand bar forced to Black; PricePane TradeLine ends
... Entry on Lime/Pink, but req's a min 3-bar gap (of any color) since a prior FullX or MaxPXit bar
... ... This prevents "chatter" during noisy/transitional zones, and precludes pure Reversals

=======

GURU_WaveAgrs2Cnsv (CVWxprt only) 5-digit "GREMP" Override tailors logic, not percents:
... G= Guru# (0-5, where 0 means Master sets the Xprt defaults)
... R= Ratio of Add/PXit size ... defines #PXits to end trade (0=NoPXits, 2=default)
... E= Entry required prior delay-bars since last Exit (0=NoDelay, 3=default)
... M= Max# Adds allowed (0=NoAdds, 2=default)
... P= PXit #med|dark-bars-gap before another PXit allowed (0=NoGap, 3=default)

Does this sound like a good plan? Am I missing something re definitions?
Note that the lines on the PricePane will greatly facilitate your Filter and Trades testing evaluations!
Top of the page Bottom of the page
KenWilsdon
Posted 2/19/2019 10:54 AM (#9358 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 17
0
Location:
: ,
Hi Jim,

Sounds good to me!
Top of the page Bottom of the page
SalimHira
Posted 2/19/2019 11:43 AM (#9360 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 156
1002525
Location:
USA: MD, Columbia
Hi Jim:

My first thoughts when I read the posts, it was something similar to what I was thinking, but did not get back to you sooner and yaahhh beat me to it - attempt to showing activity on the price pane.

In that regards, its awesome, and sounds very practical too. Thanks.

Top of the page Bottom of the page
JimDean
Posted 2/19/2019 1:40 PM (#9361 - in reply to #9356)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
Just got off phone with Ken. And had a few more thoughts. Here are conclusions:

1. Range of both BgnVot and EndVot sliders 1-5 => 2-6 votes

2. Warning fires when #opposite votes <= ~half of EndVot (thus EndV can't be less than 2)

3. Alert fires when #net votes <= ~half of BgnVot (thus BgnV can't be less than 2)

4. Wave begins when votes >= BgnVot (after delay if necessary) ... band starts bright Lime/Pink

5. After initial wave bar, color of band (if not warn or exit) is bright when net vote is advancing, and medium when net vote is declining (vs prior bar). If no change, color remains the same. This assures all three shades of green and red (as well as Alerts) "can" appear, regardless of Bgn/End inputs ... and it also gives a nice visual of how the votes are getting stronger or weaker (bright vs medium). Note that this is reflected also in the Return values. Imho this is a *big* improvement.

***addendum to 5: even if rising, the shade is never bright unless it >= BgnVote

6. K+S both "voted" for Bgn=1 as highly useful for filters ... but the new slider range will have the lowest option = 2 votes. Not to worry ... if you're trying to get a filter (or Trade) to start earlier (less lag, less certainty), then set Bgn=1 => 2votes, AND ALSO set fuzzy low (so nonzero votes appear more readily), AND ALSO set MA & Slope speeds low (to make voting more reactive), AND ALSO set MA calc to Wma or WmaH. This setup should provide for the least possible lag ... but caution- there could be a lot of nuisance entries during transitional periods.

7. Companion idea for the kind of Bgn settings above ... if you'd like trades to last a long time when all the sliders are set to be really reactive, then set the End votes to a *high* value. Actually, this logic is sort of the opposite of my original thinking ... but it seems to work (except for noisy-ness). Yet another approach ... when using NFX strategy trading, set up the Entry using the Bgn method above, but with a different input pattern (of some sort) for Exits ... you could use more moderate "speed" settings, with a moderate number of End votes.

Any thoughts?
Top of the page Bottom of the page
JimDean
Posted 2/20/2019 10:09 AM (#9368 - in reply to #9361)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
A NEW APPROACH ... please read carefully and comment ... attached PDF dup's the post ...

In the last few days, I've been studying fuzz vs bgn/end votes from different perspectives, and had a few skype discussion-tests with Ken about it. It's become apparent that:

1. combo's like Bgn=1 and End=7 are silly ... never gets to 7 since a new Bgn reverses it before
2. combo of Bgn=7 and End=X are rarely different than combo of Bgn=6 and End=X
... so ... 3-posn sliders: BgnVot from 4-6 and EndVot from 4-2 ... 4,4 seems a good setting for filters

3. with the Bgn,End=4,4 (or 4,3 or 3,4) starting point, low Fuzz seems best for filters, since less lag
... so ... Guru_Wave mapping for those three will be either a 1-5 guru or a 1-7 guru pattern:
WaveAgrs2Cnsv: 1, 2, *3, 4, 5 ... ... WaveAgrs2Cnsv: 1, 2, 3, *4, 5, 6, 7
Fuzzy%OffTo80: 1, 2, *3, 4, 5 ... ... Fuzzy%OffTo80: 1, 2, 3, *4, 5, 6, 7
BgnNetFour2Six: 4, 4, *5, 5, 6 ... ... BgnNetFour2Six: 4, 4, 5, *5, 5, 6, 6
EndOpFour2Two: 4, 3, *3, 2, 2 ...... EndOpFour2Two: 4, 3, 4, *3, 2, 3, 2

... in the table, note how the Bgn and End votes alternate to provide variant patterns (*=default)
... I don't know if the extra 1-7 version variants help ... Bgn,End=5,4 & 6,3 (with more fuzz nuance)
Fuzzy 1-5 => Pct: 0,20,40,60,80 ... Fuzzy 1-7 => 0,10,20,40,60,70,80 (or ... 0,10,30,40,50,70,80)

A. Do you think SBAS tests might clarify if 1-7 is meaningfully more useful than 1-5?
Do you think those test might also clarify which of two 1-7 alt-fuz patterns is best?

... my guess is that it would take a *lot* of SBAS tests to really answer those questions properly, since these three inputs also interact dynamically with the other three experts, and w/CumMethod

4. I've pretty much settled on the Guru and Experts for the TimeFrame triplet:
Expert-mapped inputs for all three exactly equal the Guru input (ie 1-5 for all as Guru goes 1-5)
MAcalcType: Wma, HullW, Avg(HullW,HullE), HullE, Ema (also 5 neg combos of Wma,Sma,Ema)
MAspeedFMS: table-driven FMS differs depending on CalcType chosen (designed for ~similar effects)
SlopeSpeed: 1-5 = LinReg Pds 2, 2, 3, 3, 4 ... but #2 & #4 use Wma(LRS(p),2) rather than LRS(p)
... I spent a *lot* of time on these choices; I see no big need to "validate" them w/more SBAS tests
... CVWxprt allows neg inputs for all three to spec 5 other MAcalcTypes, FfMmSs, and Slope PdsMth
... MAspeed *might* benefit more tests, but since FMS sets vary w/MAcalc, *many* tests req'd
... conclusion: probably the benefit of massive SBAS tests of FMS would not warrant the effort

5. The CumMethod is settled ... +1 to +5 is the four classic methods, with #3= Avg of the four; -1 to -5 is the four Guts/TruRng variant methods with #-3= Avg of the four; also, +6= RawVol and -6 is Avg of all 8 methods. At this time, I'm planning to offer -1 to -6 only with CVWxprt

6. Thankfully, changing the cumulation sliding-window calc to forward-weighted seems to have eliminated the huge disparities in results that we saw originally ... even when I vary the weighted-window from just 60 bars all the way up to 200 bars (by 20's). The WaveBand "shades" do change a bit, but for the most part, "green waves" and "red waves" remain in about the same locations. This means that I can *eliminate that slider* (from both Core & Xprt), leaving room for the helpful additional Xprt gray-section-separator-param.
7. There is still a fairly obvious difference between the wtd-sliding-window (any size) versus no window at all (ie ordinary approach related to #bars loaded). I sorta feel like it would be useful to somehow provide an input-alternate to illustrate that distinction ... probably by manually typing in the CumMethod input as "1X" instead of just X = -6 to +6 ... the "1" would turn off the window.
8. My OCD tendencies lead me to want to use different sliding window widths for different MAspeed inputs ... logically, fast speeds mean a focus on shorter trade timeframes and therefore logically, the CumV window could/should be "tighter" than a slow MAspeed input. As MAspeed varies from 1-5, I'd likely vary the CumV fwd-wtd window from 50-100 bars or maybe 50-150 (presuming "typical-trade" initial-entry-to-final-exit that this indicator would be used for, varies from about 10 bars to 60 bars).

B. Comments appreciated, especially re #8 window tie-in and desireable #bars-variants

9. Ken and I realized during skype chart sessions that another end-the-wave rule is needed, to prevent reaaallly extended "medium-color" waves, that show up currently during consolidation periods after the actual price-trend/swing move has ended. This is particularly an issue for the "filter" type Bgn/End inputs, where not many votes are needed to start a wave, and pretty many are needed to end it (this combo helps prevent choppiness in filter "mode").
10. We noted that in those extended cases, if the Fuzzy was fairly high, that the three "strips" under the Band in Plot#2 would all be simultaneously blue (ie net zero for slope, bar, and stack) ... sometimes for a string of bars, but usually at least for one bar. This seemed to us to be a healthy time to end the Wave, even though the #opposite votes did not exceed the End input (which really is there for significant retracements or reversals).
11. So, two new rules: Full Exit to Wave (ie like a Navy bar) if all three of those strips are blue at the same time ... OR, a Partial Exit to Wave when abs(StackVotes) <=1, abs(SlopeVotes) <=1, and abs(Stk+Slp+BarVotes) <=1 ... the last condition deals with case where Stk+Slp =2, but Bar= -1. These rules would create a Navy bar just like the existing EndVote situatlon would ... and the result would be that a Wave would not resume after that, until the BgnVote threshold (in some dir) is met.

C. Please carefully try to "picture" this, and comment on it ... important.

12. Earlier posts &/or emails indicated that Partial Exits would hit immediately when a darkred/grn Band bar was hit, and would be allowed to repeat if a bright color did not appear, on every third bar ... ie PXit on bar 1, 4, 7 if all are dark, or if some/all of 2,3, 5,6 are medium, but 4 & 7 are dark. Upon discussion while viewing charts, we decided that every-third-bar was probably too infrequent for those cases (ie, the trader would want a more rapid scaling-back). Therefore, we felt that requiring only *one* intermediate bar would be better ... ie tightest PXits would be on 1, 3, 5 (w/2&4 non-bright, and 1,3,5 all dark).
13. After that skype, I thought further about it and decided that taking the PXit immediately on the first dark was probably a bit too quick ... since it's dark and not navy, it probably represents a minor or typical in-trend pullback, if it's ALONE ... ie if following bars are med or bright. So, I'm changing the rule to allow tightest-PXit pattern to be when bars 2,4,6 are dark, and bars 1,3,5 are either dark or medium.
14. Important when evaluating 12-14 to remember that the meaning of the colors has changed since VolEval. The shade of the color used to be related to the abs# of votes, in comparison to the BgnVote & EndVote. The NEW approach offers much more useful info ...
a. Wave starts when netvote first meets/exceeds the BgnVote spec => bright grn/red
b. Wave continues until #opposite votes meet/exceeds EndVote spec, OR #11 "blue rule" is met
c. Wave can also end ... ie Band turns Navy ... if enough PXits hit to kill off all the shares
d. During the wave, any time bar's NetV >= BgnVote, AND NetV > NetV[1], the Band color is Bright.
e. During the wave, any time bar's NetV > WarnLevel, AND NetV < NetV[1], Band color is Medium.
f. During the wave, any time bar's NetV <= WarnLevel, Band color is Dark.

D. Please comment re #13 change, and #14 mapping of shades

15. The optional Xprt-only "GREMP" guru-override will still be supported, with minor tweaks:
... G= Guru# (0-5, where 0 means Master sets the Xprt defaults)
... R= Ratio of Add/PXit size ... sets #PXits to end trade (0=NoPXits, 2=default ~ A=50%, P=25%)
... E= Entry required delay-bars since last Exit (0=NoDelay, 3=default) ... maybe def=1 for reversal
... M= Max# Adds allowed (0=NoAdds, 2=default)
... P= PXit #med|dark-bars-gap before PXit on darkbar, including first (0=NoGap, 1=default)

Please comment re whether you understand GREMP and whether it's flexible enough

16. This is a biggie ... since Rob has backed out of the testing due to unexpected time conflicts, and since most of the ranges and mappings described above are pretty well decided (barring really beat it to death SBAS testing of nuance-y things), I'm considering cancelling the ongoing SBAS testing. If I do that, then I won't be able to draw on it to further tune Expert ranges or Guru mapping ... nor will I be able to "mine" the "bestest" patterns to use in the Master slider mapping. Ideally, I'd like to have the benefit of further SBAS focused-testing, but my guess is that with only two (somewhat weary) testers, and with the tight focus but high-permutation tests needed, it would take a lot of calendar days and exhaustion may set in, resulting in compromised results.
17. Without further SBAS tests, I need to assign the Master mapping somehow. Probably the best approach is to start with Core input alternatives - five CumV's, five GuruTF's, and five GuruWV's = (max of) 125 variants. If I do that, then the key question is "what order do I put them in"?
a. Method-Centric: GuruWV 1-5 within each GuruTF 1-5, within each CumVmeth 1-5
b. TimeFrame-Centric: CumVmeth 1-5 within each GuruWV 1-5, within each GuruTF 1-5
c. FltrAgrsCnsv-Centric: CumVmeth 1-5 within each GuruTF 1-5, within each GuruWV 1-5

E. Do you agree re #16 eval, and which of #17abc seems best (pls give reasons)

18. As an alternative to, OR as a negative-Master input-range option, I could do a bunch of StratWiz tests to determine "best-performing" patterns that beat some arbitrary HR, APR, MDD, Calmar, etc threshold, based on some arbitrary but large FL and arbitrary but wide date range.
19. Initial tests would use just the 125 Core input-variants to control both System and Stop (no filters), with no Adds or PXit scaling (except PXit-based final-exit would be treated as a full-exit). The same pattern would be used for both System and Stop. This would identify "ideal Core patterns" for "Basic Wave" trading ... 125 tests would be reasonable, given the large FL and time period.
20. Then I could map those "ideal" results from #19 ... let's say it's the top 25 ... into the Master Pattern slider, and do a second series of tests on the same symbols and timeframe, but this time include a CVW-based Filter Block that iterates through the 125 patterns for each of those top 25 entry-exit patterns ... a 3125 SW tests for every symbol across that big timeframe ... this would take a while and might be best handled by getting volunteers.
21. I'd then use a spreadsheet to mine the results and discover what the top (25?) filters are that "improved" the results for the top-25 entry-exit patterns ... of course diff entry-exit patterns would be helped by diff filters, but the goal would be to find a "generic" list of "best filters" that could be used with all kinds of different CVW input-patterns (CVWxprt has 12*5*5*5*5*5*5 = 187,500 slider-based patterns, not counting negative override options).
22. I'd then re-map the Master slider so that (maybe) trades would be positive values and filters would be negative ... and within each group, the sequence would be either purely related to the SW scores (not good since too specific, and hard to mush several metric-thresholds into one ranking), or more likely the order would be one of the 17 a,b,c sequences.
23. I'm WARY of doing this simply b/c I'm opposed in-principle to using SW for tool development. However, since this would only affect the Master slider, it would not reduce the range of uses that the Guru and Expert sliders offer ... simply give people some quick starting points that they could then tailor. MAYBE, given time constraints, I should release CVW based on "conceptual" Master patterns described in #17, and defer 18-23 Master "refinements" till later, with optional upgrade fee.

F. What do you think re 18-23? Would you want to help with SW tests? Do this now, or later?


Okay ... I think that covers all the ground pretty well. PLEASE take time to carefully think through these things, and provide useful (and clear) responses to A-F. Thanks!

Attachments
Attachments A NEW APPROACH.pdf (57KB - 2 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 2/20/2019 2:15 PM (#9371 - in reply to #9368)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 17
0
Location:
: ,
Hi Jim,

Wow! A lot to digest! I see this is a critical stage in the CVW development. So I will answer your questions as carefully as I can.

==========

*** A. Do you think SBAS tests might clarify if 1-7 is meaningfully more useful than 1-5?
*** Do you think those test might also clarify which of two 1-7 alt-fuz patterns is best?
... my guess is that it would take a *lot* of SBAS tests to really answer those questions properly, since these three inputs also interact dynamically with the other three experts, and w/CumMethod

Answer to A.

Looking at your point 3 carefully, you actually have 10 variations that would need testing. In order to visualize the settings, I needed to create a spreadsheet (attached). I then yellow highlighted the common settings in both the 1-7 and 1-5. As I noticed there were combos that are different, I then separated out the unique variants. Most of the variants come from what I label Fuzzy1 and Fuzzy2, from your two potential settings for 1-7.

If you tested all 10 variants, then you would have definitive results on all potential settings for 1-7 and 1-5. If we were only to vary the 10 variants, that could be done in 30 tests (for 3 stocks), which is rather trivial compared to what we have done before. Even testing them for Filters, Entries, Pxits, Adds, and Fxits would be 150 tests. While no longer trivial, it could be done in 2-3 hours.

HOWEVER, if we needed to change the settings in the other 3 experts, and the CumMethod, then I agree that it would take *A lot* of tests. Days, if not weeks of testing, to do it exhaustively. It would repeat many of the results we have done before (and it would take quite a while to eliminate anything we have done before to leave us to test ONLY what is is new, I think). I realize some methods and code have changed since the prior tests, but they should be CLOSE to the original tests in many instances.

Therefore, I would recommend an incremental testing regime, instead of an exhaustive testing. The 150 tests (or thereabouts, if you wanted to test for one or two other items), would be doable.

Really, it is only Core users that need fairly precise settings, since they can't fiddle with the underlying settings. Xprt users just need settings close (like Core), then they can fiddle the other 3 experts and CumMethod to their heart's content. I know that this will affect PPM as well.

I think this SBAS testing would clarify the 1-7 or 1-5 slider, and its values.

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

*** 8. My OCD tendencies lead me to want to use different sliding window widths for different MAspeed inputs ... logically, fast speeds mean a focus on shorter trade timeframes and therefore logically, the CumV window could/should be "tighter" than a slow MAspeed input. As MAspeed varies from 1-5, I'd likely vary the CumV fwd-wtd window from 50-100 bars or maybe 50-150 (presuming "typical-trade" initial-entry-to-final-exit that this indicator would be used for, varies from about 10 bars to 60 bars).

*** B. Comments appreciated, especially re #8 window tie-in and desireable #bars-variants

Answer to B.

I never noticed you had OCD tendencies ;-)

This makes logical sense. The logic SHOULD hold for both patterns and Ntry/(P&F)Xits.

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

*** 11. So, two new rules: Full Exit to Wave (ie like a Navy bar) if all three of those strips are blue at the same time ... OR, a Partial Exit to Wave when abs(StackVotes) <=1, abs(SlopeVotes) <=1, and abs(Stk+Slp+BarVotes) <=1 ... the last condition deals with case where Stk+Slp =2, but Bar= -1. These rules would create a Navy bar just like the existing EndVote situatlon would ... and the result would be that a Wave would not resume after that, until the BgnVote threshold (in some dir) is met.

*** C. Please carefully try to "picture" this, and comment on it ... important.

Answer to C.

We have talked considerably about this, and I agree that this would remove a lot of the times when the signal goes way too far, and does not get us out of a trade until (visually) it is obvious the trade has reversed. As this occurs rather infrequently in the charts we looked at, these seem to be good supplemental rules to get us out of a trade when volume is drying up in the direction of the trade. It does not seem to introduce excessive chop, and it reduces lag of the exit, thus keeping more money in our pockets.

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

*** 13. After that skype, I thought further about it and decided that taking the PXit immediately on the first dark was probably a bit too quick ... since it's dark and not navy, it probably represents a minor or typical in-trend pullback, if it's ALONE ... ie if following bars are med or bright. So, I'm changing the rule to allow tightest-PXit pattern to be when bars 2,4,6 are dark, and bars 1,3,5 are either dark or medium.
*** 14. Important when evaluating 12-14 to remember that the meaning of the colors has changed since VolEval. The shade of the color used to be related to the abs# of votes, in comparison to the BgnVote & EndVote. The NEW approach offers much more useful info ...
*** a. Wave starts when netvote first meets/exceeds the BgnVote spec => bright grn/red
*** b. Wave continues until #opposite votes meet/exceeds EndVote spec, OR #11 "blue rule" is met
*** c. Wave can also end ... ie Band turns Navy ... if enough PXits hit to kill off all the shares
*** d. During the wave, any time bar's NetV >= BgnVote, AND NetV > NetV[1], the Band color is Bright.
*** e. During the wave, any time bar's NetV > WarnLevel, AND NetV < NetV[1], Band color is Medium.
*** f. During the wave, any time bar's NetV <= WarnLevel, Band color is Dark.

*** D. Please comment re #13 change, and #14 mapping of shades

Answer to D.

Point 13 is well taken. We often get a one day pullback before resuming trend (Heikin-Ashi just ignores such days, and so should we). But 2 days is reasonable for the beginning of a retracement in a wave 2 or 4. The change helps to reduce Pxits taken out by noise in the markets, and only take the Pxits that are truly signaling some weakness in the stock/ETF. That is the appropriate time to take partial profits.

Point 14 makes more sense to see how volume voting is changing, after the start of a trade. This provides more useful info, visually, IMHO.

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

*** Please comment re whether you understand GREMP and whether it's flexible enough

Yes, I understand GREMP, and it seems flexible enough. Although my comments below may affect its flexibility.

I am not sure what a value of 1 or 3 would do to the R in GREMP. Since it is a ratio, would 1 mean the ratio is 1:1? so the add is the same as the entry, and the Pxit would be the same size? So it could add one full size position the same as the entry, and after that entry, there could be (potentially) 1 Pxit the same size as the entry (would be identical to Fxit if no Addon triggered prior to Pxit), as well as (potentially) a Fxit of either 2x or 1x the initial entry (depending on whether the Addon fired)?

Would a setting of R=3 mean (again) a full size add the same as entry, and Pxit of 33% of whatever the position was at the time of the Pxit firing?

I assume that the M, if set to zero, would mean Pxits are allowed, but not addons.

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

*** 17. Without further SBAS tests, I need to assign the Master mapping somehow. Probably the best approach is to start with Core input alternatives - five CumV's, five GuruTF's, and five GuruWV's = (max of) 125 variants. If I do that, then the key question is "what order do I put them in"?

*** a. Method-Centric: GuruWV 1-5 within each GuruTF 1-5, within each CumVmeth 1-5
*** b. TimeFrame-Centric: CumVmeth 1-5 within each GuruWV 1-5, within each GuruTF 1-5
*** c. FltrAgrsCnsv-Centric: CumVmeth 1-5 within each GuruTF 1-5, within each GuruWV 1-5

*** E. Do you agree re #16 eval, and which of #17abc seems best (pls give reasons)

Answer to E.

I agree with your decision in #16. You have many sliders that do not need changing, and some that require some finessing. If you do a rather exhaustive testing on the remaining parameters, fatigue and "brain freeze" will likely set in with your testers after several days, despite our best efforts to prevent it. I noticed that setting in on the 1-6 tests we did earlier, as it took several days to do. I noticed I was making more errors at the end, and had to go back to check some of my prior work when I noticed it. This set of testing will probably cause the same problems.

This final testing will take not less than that time, probably more. I think the 80-20 rule is setting in, where we already have 80% of the results (at least) with what we already have done, but the other 20% will require a massive amount of time. As our sample set of stocks, while representative, is not exhaustive, our results to this point will fit most stocks (but not all, due to the personality of individual symbols).

While I agree with Salim that TimeFrame-Centric is an important metric, I also think FltrAgrsCnsv-Centric is an equally valid top level metric. I do not see the value of Method-Centric at the top level, or even on the second tier.

Thinking of Core users, I think FltrAgrsCnsv-Centric is more intuitive, as they already know (or should know if they are trading at all) whether they lean toward being a conservative or aggressive investor. For Salim, the multiple time frame is important, but I am not sure if that would be important to all users. While I often make use of multiple time frame myself, for confirmation, I would lean more to FltrAgrsCnsv-Centric as a top tier, and put a second (or third if necessary) instance of CVW on the chart for other time frames, using the TimeFrame-Centric as a second criteria. But that is just me.

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

*** F. What do you think re 18-23? Would you want to help with SW tests? Do this now, or later?

Answer to F.

I think this would be a good idea for the PPM, to use SW over a broad focus list (at a minimum, the SP100 and Nasdaq 100), and over many years of data (your time frames you were using on MTV come to mind which you suggested at the bash about 3 years ago) encompassing bull, bear, and flat environments.

I would help with this. As you know, I have OT on a virtual server, and could run this SW testing on that 24-7 without it interrupting my other computer usage. (You can also access that too, if you want). I also have another computer at home that could run tests as well. I would *need* specific settings and instructions for SW so I could set this up on both systems.

If we get this finished, then it would be done, and would not require an upgrade fee for users. I realize that it might take a week (or 2) for all the testing you mention in 18-22, and for the results to be collated. Perhaps you could get some other projects on your list completed (like MTV to 2019) done in the meantime. Waiting a couple of weeks to release CVW complete would be worth it, IMHO, although there may be other factors for delaying release and using an upgrade at a later date, which I am not aware of. Ultimately, this decision on release is yours.

===========

I hope Salim and my comments will help you moving forward.



Attachments
Attachments FuzzyBgnEnd.xlsx (9KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 2/20/2019 2:40 PM (#9372 - in reply to #9371)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
Thanks Ken. Read thru it, and only noticed one question, regarding the R in GREMP.

R has nothing to do with Entry size. It simply tells the routine how many PXits it takes to nullify an Add.

But your comment made me realize that GREMP does not clarify how big an Add or PXit is compared to an Entry. So although R defines how many PXits offset an Add, it doesn’t define how many it takes to offset an entry - or in other words, how big an Add is compared to an entry.

I could solve this in two ways.

1. Use R for Entry/Add as well as Add/PXit. Thus an R=2 means Add= half of Entry and PXit= half of Add = one quarter of Entry. But R=1 would be sort of absurd imho, and R=3 would make PXits one-ninth ... pretty small.

2. Change to GREMAP - the A defines how big Adds are versus Entries.

Either way, R & A probably need to be mapped values rather than strict integer ratios, so that for instance Adds could be 2/3 of entries and PXits could be 2/3 of Adds, etc.

Thanks for pointing out the missing link.
Top of the page Bottom of the page
JimDean
Posted 2/21/2019 3:15 PM (#9373 - in reply to #9372)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
I rethought the entire Add & PXit sizing thing. Since this will presumably become a "standard" for Stradicators, it's important. PDF of this post is attached.

Important to note that Wave FullX comes from a "navy" Band-bar ... or from the coincidence of 3 blue Strip-bars, as described earlier. Also note that a series of PXits can end a Wave. The latter two will force the Band-bar color to black ... and just like a navy-bar, it initiates a search for a new Wave.
The RASPEG spec below doesn't technically define #shares (that's in the NFX &/or TP) ... the Strad needs to know the number, timing, and relative-sizes of Entries, Adds and PXits.
I want to limit the options to nice clean integer ratios so it's easy to explain, and to know how many PXits are needed to kill off a trade, regardless of whether or how many or what order there may have been Adds and PXits during the trade.
I want to provide for adjustable required delays between the final end of one Wave, and the start of a new one, so that "chatter" in consolidation/transitional zones can be minimized ... this may cause the "first (few) bright" bar(s) to be ignored.
I want to provide for adjustable required delays before a partial-exit is taken. If a bar has a dark "warn" color, this would spec how many bars before that warn must be non-bright (ie CumV is dropping). The spec would apply to the first PXit, and any following ones.

I also want to represent, within those confines, all the different "kinds" of Entry, Add, PXit patterns that have been discussed with various "helpers" over the past 18 months ... that is:
1. 100% Entry w/ FullExit only
2. 100% Entry w/ PXits &|or FullExit
3. 100% Entry w/ Fixed# of Fixed-Size Adds, plus PXits &|or FullExit
4. 100% Entry w/ Reducing-Size Adds, plus PXits &|or FullExit
5. ToeIn, 100%-Toe Confirm, then Fixed# of Fixed-Size Adds, plus PXits &|or FullExit
6. ToeIn, 100%-Toe Confirm, then Reducing-Size Adds, plus PXits &|or FullExit
... where all Entry, Add, PXit and ToeIn Sizes are integer-mults of associated PXit
... Adds, if used, come after a PXit-pullback, then resumption of bright-color (if any)
... ToeIn is on initial Signal, and Confirm is on next bar that moves up (ie bright color)

*I hope* that the RASPEG definition below covers all that, understandably. This input would be typed for the GURU_Wave input ... it's ones-digit *is* the Guru# ... the other digits spec the rules regarding the things above. Please note that when "R" is nonzero, then "AS" are ignored, so if the input is just four digits, it's assumed to be RPEG. Similarly, a five-digit input (leading digit nonzero) is interpreted as ASPEG. Since all inputs have defaults defined, a "PEG" input presumes R=0, A=2, and S=3. And a two-digit "EG" input presumes P=1. So, as long as the user gets the "RASPEG" sequence right, there's a natural shorthand available.

"RASPEG" optional input for GURU_WaveAgrs2Cnsv
... R= Reducing-Adds: 0=100%Entry+ A# Adds+ S-Sizing; 1-8= Patterns (PXsize= final >0 Add):
... ... 1=100,50,0; 2=100,67,33,0; 3=100,75,50,25,0; 4=100,80,60,40,20,0;
... ... 5=50,50,50,0; 6=33,67,67,33,0; 7=25,75,75,50,25,0; 8=20,80,80,60,40,20,0
... A= Max# Adds in a Wave, using S-sizing and ignoring R-patterns (0=NoAdds, 2=default)
... S= Size of Adds+PXits as %Entry (if R>0): 0=NoAorP, 3=def: 1=40+20, 2=50+25,
... ... 3=67+33, 4=75+25, 5=100+50, 6=Pat+20, 7=Pat+25, 8=Pat+33, 9=Pat+50)
... P= PXit #med|dark-bars-gap before another PXit allowed (0=NoGap, 1=default)
... E= Entry req'd prior delay-bars since last Wave-End (0=NoDelay, 3=default)
... G= Guru# (0-5, where 0 means Master sets the Xprt defaults)

A. Is it clear, without further explanation, how to use RASPEG and what the resulting effect will be?
B. Is there another important pattern I missed, which generally fall within my goals (R=9 is unused)?
C. How important/valuable do you think this will be for CVW, MTV, and other Stradicators?



Attachments
Attachments RASPEG Stradic Rules.pdf (37KB - 1 downloads)
Top of the page Bottom of the page
SalimHira
Posted 2/21/2019 6:50 PM (#9374 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 156
1002525
Location:
USA: MD, Columbia
Hi Jim:

A. Is it clear, without further explanation, how to use RASPEG and what the resulting effect will be?

>>If I correctly understand, in adding Partial Adds / with Exits having delays, than does it mean Entries will not have a delay, but Partial Exits will ... but what happens when 100% Entry w/ FullExit only .. would that also have a delay ? How do you correspond to "no delay" in this regard.

>>I am clear with all other comments you have made in this section.

B. Is there another important pattern I missed, which generally fall within my goals (R=9 is unused)?

>>Not that I am able to recall - pretty much well covered all grounds, imho.

C. How important/valuable do you think this will be for CVW, MTV, and other Stradicators?

>>It would be very important in reference to trading stocks, and futures/forex (i.e., to a certain extent - huge leverage to deal with if going overnite) and from how it would be indicative of trades maximizing efficiently the equity %'s usage instead of simply trading 100% on/off entries and exits. Its also nice there would be consistency on all the other DLL being introduced as they become available.

>>Hope it helps. Thank You.
Top of the page Bottom of the page
JimDean
Posted 2/21/2019 10:50 PM (#9375 - in reply to #9374)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3684
20001000500100252525
Location:
USA: GA, Lawrenceville
Hi Salim:

You said:
>>If I correctly understand, in adding Partial Adds / with Exits having delays, than does it mean Entries will not have a delay, but Partial Exits will ... but what happens when 100% Entry w/ FullExit only .. would that also have a delay ? How do you correspond to "no delay" in this regard.

That’s sort of a potpourri of stuff smushed together - I don’t quite understand your question, other than to observe that it sounds like you didn’t follow some or all of the definition. Please break it down into small direct questions, using the terminology that the definitions use, so as not to create ambiguity.

1. There is no such thing as a “partial add”
2. There are two separate dedicated digits that define entry and PXit delays
3. Entry with Full Exit has whatever entry delay you specify
4. “I” don’t “correspond” with anything - what do you mean by that verb?

It would help if you’d ask a focused question about a single letter of the paradigm. Or, if you have a particular combo of settings for 2+ letters, please tell me specifically what those settings are that you are asking about. Or, if you want to do a particular kind of thing, please explain it clearly and completely and I’ll tell you what the settings need to be.

Thanks.

Top of the page Bottom of the page
Jump to page : 1 2
Now viewing page 2 [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.