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. 

Proverbs 19:21 (ESV) ... Many are the plans in the mind of a man, but it is the purpose of the Lord that will stand.


Cumulative Volume Indicator DISCUSSION
Jump to page : 1 2 3 4 5
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: 3798
20001000500100100252525
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: 3798
20001000500100100252525
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: 3798
20001000500100100252525
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: 3798
20001000500100100252525
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: 46
25
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: 3798
20001000500100100252525
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: 3798
20001000500100100252525
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: 3798
20001000500100100252525
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: 46
25
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: 175
100252525
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: 3798
20001000500100100252525
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: 3798
20001000500100100252525
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: 3798
20001000500100100252525
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: 46
25
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: 3798
20001000500100100252525
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: 3798
20001000500100100252525
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: 175
100252525
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: 46
25
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: 3798
20001000500100100252525
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: 3798
20001000500100100252525
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: 46
25
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: 175
100252525
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: 3798
20001000500100100252525
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: 3798
20001000500100100252525
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: 46
25
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: 3798
20001000500100100252525
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: 3798
20001000500100100252525
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 - 2 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: 175
100252525
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: 3798
20001000500100100252525
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
JimDean
Posted 2/22/2019 9:48 AM (#9377 - in reply to #9373)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Ken - thanks for your careful evaluation ... you pointed out some things that I needed to address. Hopefully the comments below will answer all your questions, resolve the confusion, and provide for the additional needs. There are some suggested improvements, with three questions for you and Salim.

Hi Jim,
Sorry about the lateness of this, Internet was down for quite a while here. Some polar bear must have gotten tired holding the cables together. We'll have to fire him, and get another one. The help you need, and the help you get...

FIRST: as you pointed out near the end of your writeup, there is a typo in the RASPEG writeup ... under S, it should say "(if R=0)". And that apparently contradicts the use of "Pat" for options 6-9 ... each of which should say "NoAdd+X" rather than "Pat+X" ... I was continually editing and failed to update that. Sorry about the confusion it generated!

A. Is it clear, without further explanation, how to use RASPEG and what the resulting effect will be?
So to understand RASPEG better, I am going to put the RASPEG value under your options. This may also indicate how easy it is to understand (might not be bad, if you show each of these options, to give RASPEG for each number as illustration). It will also show if your explanation is adequate, as I have spent a couple of hours on this, looking carefully at everything.

1. 100% Entry w/ FullExit only

R = 0 (100% entry) Could leave blank
A = 0 (No Adds) Can't leave blank as default = 2
S = 0 =(No Adds or Pxits) Can't leave blank as default = 3
P = 0 or 1 (default is 1, but 0 works as well here, since no Pxits)
E = 0,1, 2, 3, etc (User determines value)
G = Guru number user wants.

Here is what my text says, re your note 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.

What you're missing is that the word "default" means that you *can* leave it blank (re R, A & S). For instance, if the default values of:
R = 0 = 100%Entry & "use A & S specs",
A = 2 = 2 max Adds, and
S = 3 = 67%Adds & 33%PXits,
... then you do *not* need to type in those three digits.

Furthermore, if you are satisfied with defaults of:
P = 1 = 1 required non-bright, non-exit bar before a PXit
E = 3 = 3 required delay bars after end of last Wave before a new wave is allowed (with bright)
... then you do *not* need to type in any of the RASPE digits ... just use slider to select G (or leave it 0 and let the Master dictate ;~)


2. 100% Entry w/ PXits &|or FullExit

R = 0 (100% entry), or 1-4, if those patterns under R match what the user wants. If not, could leave blank.
no - if your #2 above means not using any Adds, then R must = 0
A = 0 (No Adds)
correct - but the primarily purpose of A is not to turn off Adds in other specs, but rather to limit their application.
S = 1 = 40% Add (not used) then 20% Pxit for each Pxit.
*** 2 = 50% Add (Not used) then 25% Pxit for each Pxit.
*** 3 = 67% Add (Not used) then 33% Pxit for each Pxit.
*** 4 = 75% Add (Not used) then 25% Pxit for each Pxit. Same as 2 in this case.
*** 5 = 100% Add (Not used) then 50% Pxit for each Pxit.
*none* of S options 1-5 should be used, as they all contain Add spec's
*** 6-9 refers to the patterns under R,
*** 6. not exactly sure what Pattern + 20 means, 20% Pxit each time in the pattern of R? Does that mean in this case, that each of the patterns under R are Adds (except the zero, of course), with the last one in R being a Pxit, UNLESS we chose this S pattern, where this would override the R final value that is non zero? Would 6-9 be an acceptable option if R=0 and A=0? If so, does it then mean in that case that you would take a 20%, 25%, 33%, and 50% Pxit each time for 6-9, respectively? A little clarity here would help.
*** 7-9. Same question.
I think that my "FIRST" comment probably clears this up. Options 6-9 are intended for cases where the user wants a 100% Entry, and wants to use PXits, but not use any Adds.
P = 1 (but could be changed by user)
E = 0,1, 2, 3, etc (User determines value)
G = Guru number user wants.
PEG correct

3. 100% Entry w/ Fixed# of Fixed-Size Adds, plus PXits &|or FullExit

Let's see if I understand R:
R = 1 (if user wants 1 add same as entry and 50% Pxit)
= 2 (if user wants 2 adds, 1st same as entry, 2nd 67% of entry, and 33% Pxits)
= 3 (if user wants 3 adds, 1st same as entry, 2nd 75% of entry, 3rd 50% of
entry, and 25% Pxits)
= 4 (if user wants 4 adds, 1st same as entry, 2nd 80% of entry, 3rd 60% of
entry, 4th 40% of entry, and 20% Pxits)
= 5 (if user wants 2 adds, 1st 50% entry, 2nd 50% of entry, and 50% Pxits)
= 6 (if user wants 3 adds, 1st 33% of entry, 2nd 67% of entry, 3rd 67% of
entry, and 33% Pxits)
= 7 (if user wants 4 adds, 1st 25% of entry, 2nd 75% of entry, 3rd 75% of
entry, 4th 50% of entry, and 25% Pxits)
= 8 (if user wants 5 adds, 1st 20% of entry, 2nd 80% of entry, 3rd 80% of
entry, 4th 60% of entry, 5th 40% of entry, and 20% Pxits)
All are incorrect ... all for same reason. The first number is intended to be the Entry%, which for 1-4 is 100%, and for 5-8 is a "Toe-In" smaller value. The second and following numbers are successive Add%'s. The final nonzero number "doubles" as the final Add, and also as the spec for the (fixed) PXit size - note that it always divides evenly into the preceding numbers in that option.

If user wants a different configuration than patterns above, he would set R=0,
and adjust A and S as below.
correct

A = # of adds user wants (when R=0; Otherwise, R overrides A; 2= default)
A=2 is default only if R=0, otherwise A and S are ignored. Not sure if that's what you meant.

Now let's see if I understand S:
first, as mentioned earlier, S only applies if R=0
S = One of the following:
= 0 if you want just the number of Adds in A above with no Pxits, just Fxits.
No. When it says "0=NoAorP", that means No Adds or PXits ... ie the simplest of all plans ... an Entry and a FullX. I chose not to set that as the default, since the Stradicator works much better with PXits than without them ... if it turns out that Adds don't clearly improve the way the Wave works, then I'll probably change the default to 8.
= 1 if you want each Add in A above to be 40% of entry, and each Pxit to be
20%
= 2 if you want each Add in A above to be 50% of entry, and each Pxit to be
25%
= 3 if you want each Add in A above to be 67% of entry, and each Pxit to be
33%
= 4 if you want each Add in A above to be 75% of entry, and each Pxit to be
25%
= 5 if you want each Add in A above to be 100% of entry, and each Pxit to be
50%
1-5 correct ... what I think you may be missing, maybe due to the order of letters in RASPEG, is that A is "subservient" to S ... if S does not spec an Add size, then A is ignored.

Here is what I don't understand:
You state "Size of Adds+PXits as %Entry (if R>0):" Shouldn't that be if R=0?
Otherwise, R overrides S. The only cases are when S=6 to 9, then I could see
R>0, if you set each exit for the value at the end of 6-9. If you are doing
both, then you should add (if R=0) and (if R>0) in the appropriate spots, to be
clear. Otherwise, Pat makes no sense here, if it is not referring to R patterns.
correct - "R>0" was a typo, as was "Pat" which should have been "NoAdd"

PEG same as above.
correct

4. 100% Entry w/ Reducing-Size Adds, plus PXits &|or FullExit

Reducing size adds would need to use R patterns 2-4, which has Pxits inside.
Wrong - all R patterns 1-8 use reducing-size adds ... that is, as time proceeds, Adds get smaller than the prior Entry/Add. The only "special" case is the "ToeIn" Entry used by 5-8 ... two paragraphs earlier in my writeup, it was poorly written ... 5 & 6 should have said:
5. ToeIn, ToeConfirm (Sum=100%), then Fixed# of Fixed-Size Adds, plus PXits &|or FullExit
6. ToeIn, ToeConfirm (Sum=100%), then Reducing-Size Adds, plus PXits &|or FullExit
... ToeIn is on initial Signal, and Confirm is on next bar that moves up (ie bright color)

That final "..." note is essential - Confirm (ie the second # in R=5-8) works much differently than Adds do ... it happens *shortly after* the ToeIn, *without* a darkbar pullback ... all it needs is a single bright bar to trigger it. This is common on the second bar of a "real" wave", but when an initial bright occurs in a consolidation or retracement, quite often it's not followed by another ... in which case R=5-8 patterns would significantly limit your exposure.


Do not need A or S (I think).
correct - but if you chose to type in a six-digit RASPEG value, it would ignore A & S if R was nonzero ... maybe it would create a popup note as well.

PEG same as above.
correct

A. Are my explanations and comments sufficient, for all the above?


5. ToeIn, 100%-Toe Confirm, then Fixed# of Fixed-Size Adds, plus PXits &|or
FullExit
This is not possible ... maybe it should be. Current logic only allows Toe+Confirm with R=5-8, all of which use Reducing Adds after the Confirm.

ToeIn requires R = 5 to 8, with the second number making the 100% confirm, then remainder up to the number before 0 are the fixed # and fixed size (preset) addons, and the number before zero is PXit.
Can not be done with A and S, as Entry then is 100%, if not using R=1-8.
Closest would be S=2, if entry could be somehow turned off [Perhaps this would be R=9}, and Add1 would be ToeIn entry, Add2 would be 100%-Toe Confirm. A would then need to be a minimum of 2 for this to happen.
Since current logic is "either use R or use A+S", it's probably best to maintain that ... otherwise potential confusion might arise from combinations of the three. However, the "ToeConfirm + PXits", with or without A# of Fixed Adds, is a sensible option that needs to be represented. The trick is that each letter can only have single-digits 0-9, and that all components of the process need to be evenly divisible by PXit, and that ToeConfirm should likely offer 4 options: 50,50; 33,67; 25,75; 20,80. After chewing it over a while, I realized that there is a nice elegant solution to it:
a. remove R=5-8 options, since they are simply ToeConfirm echoes of R=1-4
b. specify: if the RASPEG value is *negative*, then Entry is Toe+Confirm; if positive, then it's 100%
c. Toe+Confirm cases use 20,80 if PXit=20 as spec'd by R or S; use TC=25,75 if PX=25; use TC=33,67 if PX=33, and use TC=50,50 if PX=50.

B. What do you think about this idea?


PEG same as above.
correct

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)

ToeIn, 100%-Toe Confirm, then Reducing-Size Adds require R patterns 5-8.
correct ... but with the change I suggested above, you'd use R=1-4 for reducing-size Adds, OR S=1-5 for fixed-size Adds ... and make the entire entry Negative to spec ToeConfirm.

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

As mentioned in 5 above, R could be to have adds only, no entry.
Not quite sure what you mean here, but do the revisions I proposed earlier would meet the additional need you refer to?

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

Very valuable. The spreadsheet to create the trade plan for this would be needed, of course. But it will provide automatic Addons, Pxits, and Fxits, which will allow a trade to go much longer, taking profits along the way, and reenter without user intervention in many cases, as the trade continues in our direction.
Yessir. Also, TradeTrak (and the SmartTP, eventually) will provide a Text file with all the events spelled out.
I think that maaaybe I should add a new Help Panel specifically to explain RASPEG, and document the values being used for that particular pattern. With a couple of examples, one using 100% Entry with A+S, and the other using ToeConfirm with R.
Hmmm...
If I add a HelpPanel, then it "highlights" RASPEG rather than leaving it sort of obscure as an optional override. AND, if RASPEG is going to become a "standard" for Stradicators ... at least for any that logically can identify potential Add+PXit bars ... then maaaybe I should assign it to a dedicated parameter? I'm running out of space ... I can't add any more to Xprt without forcing two columns, so I'd have to eliminate one of the two remaining gray section-separators ... or kill off an Expert - which at this point I'm unable to do until testing determines that one is not needed (such as CumVwindow which is still up for grabs). Maaaybe, if my upcoming dev tests affirm that Wndo can be tied into the first Guru as a function of MAspd, without compromising anything, then I could elim that input (yay) and allow an override input for the TimeFrame Guru that would hard-spec the Wndo if desired.
In that case, the extra RASPE input would not have a "G" ... and maybe it should use a slider approach, with some manual-type-in overrides ...
Basic -14 to +14 slider options: 1-10=S0-S9; 11-14= R1-R4, where neg= Toe+Confirm
... assumptions for those inputs: default A=2, P=1, E=3 settings
... also ... -1 input means S0 means ToeConfirm + FullX w/o PXit ... in that case, use 50+50 for TC.
Optional: type in +/-APExx, where xx=1-14 slider, and APE= specific alternatives to defaults.
Note: this is an Expert slider, likely before the first Guru ... it will be part of what Master can control

C. What do you think about this idea?

Top of the page Bottom of the page
SalimHira
Posted 2/22/2019 11:11 AM (#9378 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
Thank You Ken for sharing and having spent invaluable time of your detailed analysis, and Jim's continued "not letting" up till each stone is turned ... amazing, when great minds work all together.

I certainly do not have any followed-up questions or comments. I did go through all the material, and to best of my abilities attempt to follow through the conversation. Thanks again for the great work.

I can only be a cheerleader at moment and in 3-words, Go For IT !!! ....
----------------------

Jim, as you work on the new changes, code and dev. test all this stuff - is it possible to get the current DLL as it is for us to fiddle and play around with the "new" logic (i.e., Returns, Hull, etc.) that has been implemented in the code since A2. As thinking, the newer suggested changes would not affect the DLL logic, would it, if I am guessing correctly.
Top of the page Bottom of the page
JimDean
Posted 2/22/2019 11:30 AM (#9379 - in reply to #9378)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

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

Re new beta DLL ... it takes a few hours to create a DLL, so I don't do so unless I'm asking team to do testing on it. That's why these posts and the questions (such as A,B,C in my prior post) are so very important. They represent the ONLY opportunities that beta folks have, to influence the design as it progresses.

If you've been following along, you'll have seen that in the past 5-10 days, the meaning and arrangement of the inputs (the most basic aspect of the routine) has changed several times, and the calcs have changed many times.

If I were to release a DLL at any point where that kind of thing is still fluid, then any tests you'd do, and any comments you'd make about how the answers looked, would 95% likely be useless, since things would have changed since then.

This is generally true of all my group-development projects. If it's custom work, then any time the client wants a DLL, I'll do it, but they pay for the time to create it repeatedly.

So ... I can't emphasize strongly enough how important it is for team members to follow along with these posts I'm doing here, and ask questions if they don't understand, and make suggestions asap after the post appears, since that represents "when" I'm working on stuff.

That's why I'm resistant to late-appearing alternative ideas ... I'd have to backtrack too much and usually it would de-stabilize the work I'd already completed. Timeliness in following along with, reviewing and responding to this discussion/progress thread is crucial.
Top of the page Bottom of the page
KenWilsdon
Posted 2/22/2019 1:48 PM (#9381 - in reply to #9377)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi Jim,

We got a new polar bear. He seems to be working better than the last one. Internet is back.

Just to be clear, I am going to make a few comments so RASPEG is firmly in my memory. Let's try this again.

User wants:
Case 1. 100% Entry w/ FullExit only

From your comments, ASPEG HAS to be used for this option, default for R=0, since A&S defaults do NOT match what the user wants. He wants no adds and no pxits. So the string for this option would be
ASPEG
A =0
S =0
PEG = either defaults, or what user wants.
correct

Case 2. 100% Entry w/ PXits &|or FullExit

R=0
A=0
S=6 to 9, taking into account your reply:
correct, but actually A is ignored since S says "NoAdd", so A could be anything

"I think that my "FIRST" comment probably clears this up. Options 6-9 are intended for cases where the user wants a 100% Entry, and wants to use PXits, but not use any Adds. "

This reply clarifies a lot of things. So S=6-9 is a fixed Pxit until the Fxit hits, or until equity in the trade is gone by Pxits. S=6-9 do not apply if A is a value other than zero (as the A options override).
last statement is wrong ... A is subservient to S ... I could change the order to represent this, but "RSAPEG" is sort of hard to pronounce ;~) Also, A says "using S sizing", making it dependent on S ... and S says "NoAdd", thus nullifying A. Imho, that should be clear enough. Am I wrong?

S=6 20% Pxit
S=7 25% Pxit
S=8 33% Pxit
S=9 50% Pxit

PEG same as for the last choice and all choices below. Will concentrate on RAS.

Case 3. 100% Entry w/ Fixed# of Fixed-Size Adds, plus PXits &|or FullExit.

Your reply:

"All are incorrect ... all for same reason. The first number is intended to be the Entry%, which for 1-4 is 100%, and for 5-8 is a "Toe-In" smaller value. The second and following numbers are successive Add%'s. The final nonzero number "doubles" as the final Add, and also as the spec for the (fixed) PXit size - note that it always divides evenly into the preceding numbers in that option. "

Ok. This is where your abbreviated style was unclear. You have
"1-8= Patterns (PXsize= final >0 Add):"

It should be something like "1-8= Patterns (Entry, Adds, PXsize&Final Add= final #>0):"

In this case, for what the user wants in 3, there are a couple of ways this could be done.

A. R=1, if the user wants 100% entry, one 50% add, and all Pxits at 50%.
B. R=0, if the user wants 100% entry
intention is that B is the correct route ... R is for "reducing Adds", S is for all other cases

Now we come to parameter A for R=0. First, You replied to my comment:

If user wants a different configuration than patterns above, he would set R=0,
and adjust A and S as below.
***correct ***

A = # of adds user wants (when R=0; Otherwise, R overrides A; 2= default)
***A=2 is default only if R=0, otherwise A and S are ignored. Not sure if that's what you meant. ***

Yes, that is what I meant.

Now back to 3.

A= #of adds the user wants (R=0, A=2 by default). If other than A=2, user must define A.

Now:
S= 1 if you want each Add in A above to be 40% of entry, and each Pxit to be 20%
S= 2 if you want each Add in A above to be 50% of entry, and each Pxit to be 25%
S= 3 if you want each Add in A above to be 67% of entry, and each Pxit to be 33%
S= 4 if you want each Add in A above to be 75% of entry, and each Pxit to be 25%
S= 5 if you want each Add in A above to be 100% of entry, and each Pxit to be 50%
correct

You replied:
"1-5 correct ... what I think you may be missing, maybe due to the order of letters in RASPEG, is that A is "subservient" to S ... if S does not spec an Add size, then A is ignored. "

I take your comment "A is "subservient" to S" to mean if S=1-5, A MUST be >= 1 (or error msg I guess). Your comment applies to these 5 choices alone. (otherwise it contradicts what you said the purpose of 6-9 are - you are doing one thing with 1-5 [A>=1], and another with 6-9 [A=0], which should be clear in instructions).
no, by "subservient" I mean that if S says "NoAdd", then A is ignored. It appears that the sequence of RAS (vs RSA) is having a greater impact on comprehension than the actual words.
I guess I should switch the sequence.


For case #3, S=6-9 are not an option, as user wants adds.
correct

If user doesn't want adds, A=0, then S=6-9 is appropriate as Case 2 above. So if S=6-9, A being subservient, A MUST =0 (or error msg - Must dummy proof this).
re "MUST" ... no, A *can* = 0 but the program IGNORES it when S says "NoAdd"

Now that we have all that covered, I will try to go faster thru the rest.

Case 4. 100% Entry w/ Reducing-Size Adds, plus PXits &|or FullExit

Reducing size adds would need to use R patterns 2-4, which has Pxits inside.

You replied:

"Wrong - all R patterns 1-8 use reducing-size adds ... that is, as time proceeds, Adds get smaller than the prior Entry/Add. The only "special" case is the "ToeIn" Entry used by 5-8 ... two paragraphs earlier in my writeup, it was poorly written ... 5 & 6 should have said:
5. ToeIn, ToeConfirm (Sum=100%), then Fixed# of Fixed-Size Adds, plus PXits &|or FullExit
6. ToeIn, ToeConfirm (Sum=100%), then Reducing-Size Adds, plus PXits &|or FullExit
... ToeIn is on initial Signal, and Confirm is on next bar that moves up (ie bright color)
That final "..." note is essential - Confirm (ie the second # in R=5-8) works much differently than Adds do ... it happens *shortly after* the ToeIn, *without* a darkbar pullback ... all it needs is a single bright bar to trigger it. This is common on the second bar of a "real" wave", but when an initial bright occurs in a consolidation or retracement, quite often it's not followed by another ... in which case R=5-8 patterns would significantly limit your exposure."

I totally understand that. But you missed my point. Case 4 does not specify ToeIn and ToeConfirm, so options 1-4 are the ONLY appropriate patterns, if the user does not want ToeIn and ToeConfirm. (Case 5-6 use both of these). These all have at least one reducing size add from 100% entry.
Hmm. Options 1-4 are correct ... earlier you said 2-4. The new solution that I spec'd at the end of my prior responses removed R options 5-9 and replaced the ToeConfirm spec method with a simple minus-sign for the entire input. So ... with that ... if you meant to exclude ToeConfirm in your spec, then the input would be +, and R=1-4 would be valid options.

A and S cannot create reducing size adds, so R=0 is not an option for Case 4, and because R>=1, A and S are ignored.
correct

You asked:
"A. Are my explanations and comments sufficient, for all the above?"

My answers above should answer this question.

Case 5. ToeIn, 100%-Toe Confirm, then Fixed# of Fixed-Size Adds, plus PXits &|or FullExit

You replied:
"This is not possible ... maybe it should be. Current logic only allows Toe+Confirm with R=5-8, all of which use Reducing Adds after the Confirm. "

"Since current logic is "either use R or use A+S", it's probably best to maintain that ... otherwise potential confusion might arise from combinations of the three. However, the "ToeConfirm + PXits", with or without A# of Fixed Adds, is a sensible option that needs to be represented. The trick is that each letter can only have single-digits 0-9, and that all components of the process need to be evenly divisible by PXit, and that ToeConfirm should likely offer 4 options: 50,50; 33,67; 25,75; 20,80. After chewing it over a while, I realized that there is a nice elegant solution to it:
a. remove R=5-8 options, since they are simply ToeConfirm echoes of R=1-4
b. specify: if the RASPEG value is *negative*, then Entry is Toe+Confirm; if positive, then it's 100%
c. Toe+Confirm cases use 20,80 if PXit=20 as spec'd by R or S; use TC=25,75 if PX=25; use TC=33,67 if PX=33, and use TC=50,50 if PX=50. "

Ok. So if I understand these options, to have Case 5, it would be negative, and as you say you could use R or S, for R:
no ... since you specified fixed-size, it would be S not R

If R=-1, then 50% ToeIn, 50% ToeConfirm, 50% Pxit (Negative ignores the 100%).
If R=-2, then 33% ToeIn, 67% ToeConfirm, 33% Pxit (Negative ignores the 100,67%).
If R=-3, then 25% ToeIn, 75% ToeConfirm, 25% Pxit (Negative ignores the 100,75,50%).
If R=-4, then 20% ToeIn, 80% ToeConfirm, 20% Pxit (Negative ignores the 100,80,60,40,%).

What I then would be unclear about would be the size of the adds. Would the adds in R=-1 to 4 be
If R=-1, Adds (after ToeIn and ToeConfirm,100%, 50%) or just 50%, or no adds at all.
If R=-2, Adds (after ToeIn and ToeConfirm,100%,67%,33%) or just 33%, or no adds at all.
If R=-3, Adds (after ToeIn and ToeConfirm,100%,75%,50%,25%) or just 25%, or no adds at all.
If R=-4, Adds (after ToeIn and ToeConfirm,100%,80%,60%,40%,20%) or just 20%, or no adds at all.
all of the above are reducing-size options, not fixed size, so they don't apply

Then if:
R= - 0, it would no longer be a 100% full entry, but ToeIn and ToeConfirm, but entry size would be controlled by S, so:
S=0 0=NoAorP, Just ToeIn and ToeConfirm, Fxit (But size not defined; Perhaps have a default 50% ToeIn and 50% ToeConfirm in this one instance - You do not have that option under S available).
my notes at the end of my last long response had a footnote that said when S=0 case was selected (ie Slider=+/-1), the ToeConfirm split would be 50/50

S=1 1=40+20, meaning 20% ToeIn and 80% ToeConfirm, 40% Adds (# controlled by A>=1), 20% Pxits, Fxit.
correct

S=2 2=50+25, meaning 25% ToeIn and 75% ToeConfirm, 50% Adds (# controlled by A>=1), 25% Pxits, Fxit.
correct

S=3 3=67+33, meaning 33% ToeIn and 67% ToeConfirm, 67% Adds (# controlled by A>=1), 33% Pxits, Fxit.
correct

S=4 4=75+25, meaning 25% ToeIn and 75% ToeConfirm, 75% Adds (# controlled by A>=1), 25% Pxits, Fxit.
correct

S=5 5=100+50, meaning 50% ToeIn and 50% ToeConfirm, 100% Adds (# controlled by A>=1), 50% Pxits, Fxit.
correct

Now for R = - 0, S=6-9, where no adds allowed.

S=6 NoAdd+20, meaning 20% ToeIn and 80% ToeConfirm, No Adds (A ignored), 20% Pxits, Fxit.
S=7 NoAdd+25, meaning 25% ToeIn and 75% ToeConfirm, No Adds (A ignored), 25% Pxits, Fxit.
S=8 NoAdd+33, meaning 33% ToeIn and 67% ToeConfirm, No Adds (A ignored), 33% Pxits, Fxit.
S=9 NoAdd+50, meaning 50% ToeIn and 50% ToeConfirm, No Adds (A ignored), 50% Pxits, Fxit.
if you're still discussing Case 5, then S=6-9 don't apply b/c they have no adds, but your Case 5 specified Adds. If however you consider 0 Adds to be a fixed# ... then yes these options are the right ones.

You asked:
"B. What do you think about this idea?"

A -0 for R looks a little strange, as the negative of nothing (zero) logically would be something, not nothing. But if you are able to parse it, it would allow a lot of options (meaning something). I like all the options. It IS elegant. And very flexible.
You're missing something simple but big here. RASPEG (or RSAPEG) is a SINGLE 2-to-6-digit number that is positive or negative. So it's meaningless to speak of "R = -0"

Case 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)

ToeIn, 100%-Toe Confirm, then Reducing-Size Adds require R patterns 5-8.

You replied:
"correct ... but with the change I suggested above, you'd use R=1-4 for reducing-size Adds, OR S=1-5 for fixed-size Adds ... and make the entire entry Negative to spec ToeConfirm. "

We have covered all this above. R from -1 to -4 would allow ToeIn ToeConfirm, reducing size adds, Pxits and Fxits.

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

As mentioned in 5 above, R could be to have adds only, no entry.
Not quite sure what you mean here, but do the revisions I proposed earlier would meet the additional need you refer to?
I don't understand "R could be to have adds only, no entry" ... the first value in the R=1-4 lists is the Entry percentage ... the second value is the first Add. R=5-8 are gone.

Yes. The revisions answered this point.

Now for your final comments:

"Yessir. Also, TradeTrak (and the SmartTP, eventually) will provide a Text file with all the events spelled out.
I think that maaaybe I should add a new Help Panel specifically to explain RASPEG, and document the values being used for that particular pattern. With a couple of examples, one using 100% Entry with A+S, and the other using ToeConfirm with R.
Hmmm...
If I add a HelpPanel, then it "highlights" RASPEG rather than leaving it sort of obscure as an optional override. AND, if RASPEG is going to become a "standard" for Stradicators ... at least for any that logically can identify potential Add+PXit bars ... then maaaybe I should assign it to a dedicated parameter? I'm running out of space ... I can't add any more to Xprt without forcing two columns, so I'd have to eliminate one of the two remaining gray section-separators ... or kill off an Expert - which at this point I'm unable to do until testing determines that one is not needed (such as CumVwindow which is still up for grabs). Maaaybe, if my upcoming dev tests affirm that Wndo can be tied into the first Guru as a function of MAspd, without compromising anything, then I could elim that input (yay) and allow an override input for the TimeFrame Guru that would hard-spec the Wndo if desired.
In that case, the extra RASPE input would not have a "G" ... and maybe it should use a slider approach, with some manual-type-in overrides ...
Basic -14 to +14 slider options: 1-10=S0-S9; 11-14= R1-R4, where neg= Toe+Confirm
... assumptions for those inputs: default A=2, P=1, E=3 settings
... also ... -1 input means S0 means ToeConfirm + FullX w/o PXit ... in that case, use 50+50 for TC.
Optional: type in +/-APExx, where xx=1-14 slider, and APE= specific alternatives to defaults.
Note: this is an Expert slider, likely before the first Guru ... it will be part of what Master can control

C. What do you think about this idea?"

One option would be to put RASPEG at the very end of the Helps, if you want to obscure it. Before they get there, they may get weary of pressing Yes to go to the next screen (it is SO hard *snicker* to press the Y key - I'm being sarcastic here - I'm speaking about those too lazy to read a help screen).
since it has a major effect on output, and since it's an input, and since it has default values, it actually should be a part of HP#1, like all other such stuff. But that would make HP#1 too tall.
If I do add a slider as discussed below, this panel will become HP#2 for that reason.


The negative positive slider idea would be nice, and having +/- APExx makes a world of sense. But does that mean S is out of the picture, that if R=0, there would be no way to control S=0 to 9 Adds and/or Pxits? That would reduce some flexibility. Maybe APESxx would be better. Then the APES would be before the GURUS.
no ... S0-S9 are the slider= +/- 1-10 values as I noted in my description. Maybe you missed the last part of that post ... I may have added it after the initial post ... that's why I texted you and Salim to click on the link and not read the text of the post ... so,worth reviewing the "big blue chunk" again.
Top of the page Bottom of the page
KenWilsdon
Posted 2/22/2019 2:04 PM (#9382 - in reply to #9378)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Thanks Salim, for your kind comments. This is a collaborative effort, and each of us bring certain strengths to the table to make this, and any tool, the best we can. I certainly appreciate all the time and hard work YOU have put into this project, as well. Your efforts have made this a better tool.

Like you, I can hardly wait for a new DLL, but we will have to wait until this development phase is complete. The final product will be AMAZING, and much better than anything N has on the market.
Top of the page Bottom of the page
KenWilsdon
Posted 2/22/2019 2:16 PM (#9383 - in reply to #9381)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Sorry Jim,

My final comments misinterpreted your last paragraph.

"Basic -14 to +14 slider options: 1-10=S0-S9; 11-14= R1-R4, where neg= Toe+Confirm
... assumptions for those inputs: default A=2, P=1, E=3 settings
... also ... -1 input means S0 means ToeConfirm + FullX w/o PXit ... in that case, use 50+50 for TC. "

So options 1-10 take care of S, and -1-10 take care of ToeIn and ToeConfirm with S. My apologies. I assume in all those cases, R=0.
Yup ... S & R are always exclusive of one another, and A only applies if S "needs to know"

Top of the page Bottom of the page
JimDean
Posted 2/22/2019 2:55 PM (#9384 - in reply to #9383)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
OK ... barring the Slider discussion, here is an updated concise definition of RSAPEG, with some notes added. I believe that if it's read carefully, it's self-contained. I know of course that much more could (and will) be written to expand upon it, but I'm trying for a "cheat sheet" here ... (PDF attached)


"RSAPEG" optional input (2-6 digits, pos or neg) for GURU_WaveAgrs2Cnsv

... Sign: Positive means Entry=100%; Negative means Entry as ToeIn + Confirm (on next bright bar)
... ... ToeIn Size always = PXit (spec'd by R or S); Confirm Size always = 100-ToeIn

... R= Reducing-Adds: def=0 => use S instead ... R = specific# of successively-smaller Adds:
... ... 1=100%entry, 50%add; 2=100,67,33; 3=100,75,50,25; 4=100,80,60,40,20
... ... Notes: PXit%= final Add%; if R>0, then S & A are ignored (their values don't matter)

... S= Size (fixed) of (Adds)+PXits as %Entry (only applies when R=0), def=3:
... ... 1=40%add + 20%pxit, 2=50+25, 3=67+33, 4=75+25, 5=100+50,
... ... 6=NoAdd+20, 7=NoA+25, 8= NoA+33, 9=NoA+50, 0=NoA or PX
... A= Max# Adds in a Wave, using S-sizing and *ignoring* R-patterns (0=NoAdds, def=2)
... ... Note: if S=0 or S=6-9, then A is ignored (its value doesn't matter)

... P= PXit #med|dark-bars-gap before another PXit allowed (0=NoGap, default=1)
... E= Entry req'd prior delay-bars since last Wave-End (0=NoDelay, default=3)
... G= Guru# (0-5, where 0 means Master sets the Xprt defaults)

Does this sufficiently clear up ambiguities about the original spec?


Attachments
Attachments RSAPEG Stradic Rules.pdf (20KB - 3 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 2/22/2019 4:18 PM (#9385 - in reply to #9381)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi Jim,

I will comment on a couple of comments from your comments of my comments (Whew!).
========
"I think that my "FIRST" comment probably clears this up. Options 6-9 are intended for cases where the user wants a 100% Entry, and wants to use PXits, but not use any Adds. "

I replied:
This reply clarifies a lot of things. So S=6-9 is a fixed Pxit until the Fxit hits, or until equity in the trade is gone by Pxits. S=6-9 do not apply if A is a value other than zero (as the A options override).

You said:
last statement is wrong ... A is subservient to S ... I could change the order to represent this, but "RSAPEG" is sort of hard to pronounce ;~) Also, A says "using S sizing", making it dependent on S ... and S says "NoAdd", thus nullifying A. Imho, that should be clear enough. Am I wrong?

My new reply:
No, you are not wrong. You may already be IdiotProofing that though, as A is subservient to S. S would ignore A on options S=0,6-9.

===========
I said:
I take your comment "A is "subservient" to S" to mean if S=1-5, A MUST be >= 1 (or error msg I guess). Your comment applies to these 5 choices alone. (otherwise it contradicts what you said the purpose of 6-9 are - you are doing one thing with 1-5 [A>=1], and another with 6-9 [A=0], which should be clear in instructions).

You said:
no, by "subservient" I mean that if S says "NoAdd", then A is ignored. It appears that the sequence of RAS (vs RSA) is having a greater impact on comprehension than the actual words.
I guess I should switch the sequence.

My new reply:

No, it is not the sequence of RAS that is conceptually the problem, but that you have S doing two separate functions. S (or now R) =+/- 1-5 means there are Adds and Pxits, S (or R) = +/- 6-9 means there are no Adds. Just Pxits.

=============
At this point I looked carefully at the new PDF. I left the above in this post because I believe they clarify that we are now thinking along the same lines (finally!).

This PDF is MUCH better.

A couple of comments.

Spelling out R as Reducing Adds helps conceptually.

What is still unclear in the PDF is in this paragraph from post 9377.

"Basic -14 to +14 slider options: 1-10=S0-S9; 11-14= R1-R4, where neg= Toe+Confirm
... assumptions for those inputs: default A=2, P=1, E=3 settings
... also ... -1 input means S0 means ToeConfirm + FullX w/o PXit ... in that case, use 50+50 for TC"

The last line is VERY clear. In the PDF, not quite as clear.

You have in the PDF that negative is ToeIn ToeConfirm,

You also state:

"... A= Max# Adds in a Wave, using S-sizing and *ignoring* R-patterns (0=NoAdds, def=2)
... ... Note: if S=0 or S=6-9, then A is ignored (its value doesn't matter)"

This is good, but could be slightly clearer for the R=-1 case. You have "if R>0", but as you don't mention R<0, the user may be unclear if R=-1 means S=0, means 50% TI, 50% TC and perhaps 50% Add (On second thought, maybe that is what you want. Maybe I misinterpreted the 4th paragraph above. The same cannot be achieved with R=-0, S=9, as that would be NoAdd and 50% Pxit). If the case of 50% TI and 50% TC with no Adds or Pxits, just Fxit is an option you want, then the following is a suggestion. Otherwise, ignore it.

I know real estate is at a premium, but R= -1 is a special case. Maybe this would be clearer. After:

... R= Reducing-Adds: def=0 => use S instead ... R = specific# of successively-smaller Adds:
... ... 1=100%entry, 50%add; 2=100,67,33; 3=100,75,50,25; 4=100,80,60,40,20
... ... Notes: PXit%= final Add%; if R>0, then S & A are ignored (their values don't matter)

Add:
Special case: If R=-1, then S=0 : 50% ToeIn 50% ToeConfirm + FullX w/o Adds, PXit.
=========
One final comment. I don't think RASPEG order needs to be changed. Your definitions in PDF make things so much clearer, that that won't be necessary.

That's all I see. Everything else looks great! I think. We have beaten this horse to death.
Top of the page Bottom of the page
JimDean
Posted 2/22/2019 4:27 PM (#9386 - in reply to #9385)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Thanks Ken

I'll modify the PDF in a while ... sounds like it's pretty close ... and that you understand it.

If I end up creating the Slider, then the "RASPEG" acronym and its notes will be simplified, since the R & S choices, and the ToeConfirm vs All-In options, are all clearly exclusive of one another by virtue of the slider position.

The notes will need to explain each one of course (a list of 14) ... with a note re ToeConfirm. And three small notes for A,P,E ... that should all fit easily onto a Help Pane.

Thanks for beating the horse. It was kicking down the fences. Now it's manageable.
Top of the page Bottom of the page
JimDean
Posted 2/22/2019 4:52 PM (#9387 - in reply to #9386)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Well ... FINALLY ... I found the issue that was causing the outputs to change when the Bars-To-Calc input was changed. As predicted, it took hours of searching around, and once I found the issue (actually, two of them but both similar in nature), it was easy to fix. Whew.

There still is one remaining factor. If I compare two WaveBands, one with say 126 bars showing and the other say with 150 bars showing, it's still *possible* that the first few (or possibly not-so-few) bars of the 126 case won't match the overlapping bars from the 150 case. The reason has to do with the fact that a Wave, once started, has specific rules to end it ... but if you were to start the analysis in the midst of that Wave, the routine would not recognize that a Wave was in place unless there happened to be a bright bar as the very first one of the shorter-width instance.

Part of this problem will be solved once I implement the RSAPEG rules, specifically those that allow partial exits or three-strips-navy rules to end a Wave. Right now, until the logic finds a bar that specifically satisfies the EndVote rule, the Wave can just go on and on and on (usually with a medium red or green color).

However, even when the new RSAPEG and three-strips-navy rules are in place, the same problem might still occur. The disparity will ONLY last until a Navy bar is found that ends any extant Wave ... from that point forward, the two displays and return values will match precisely.

So ... I'm going to put in a "ratchet" clause that doesn't allow the output to actually start, even if it's within the range of the specification, until a navy bar is hit. That should solve the problem for all but outlier cases where navy bars rarely if ever appear ... this would happen for a Bgn=-1, End=-7 pair of negative-overrides for instance.

Another need for this has to do with RSAPEG rules ... several of them "count" bars of one color or another, to track the Wave. If the time-window begins in the midst of a Wave that is visible using a bigger time-window, then even if it found a bright bar to start up mid-Wave, the Add-counts would be off, so the Waves in the two instances could differ.

Actually, this same kind of problem happens with regular vanilla strategy simulation in all of N platforms ... if the starting bar of a test window is "in the middle" of a trade that "would have been active" if the test window had just gone back some additional bars, then that trade (big or small, profit or loss) will either be missed entirely, or might take a shorter form with less or more profit, or even in the opposite direction. So ... whatever solution I come up with will be better (ie more stable) than the existing N platforms do. That should silence any complaints.

HOW to do this?

Well, waiting for one navy bar won't always be enough. The "E" spec provides for a delay between the end of one Wave and the start of the next. The navy bar, once found, won't have a "count" associated with it since the end of the prior Wave will still be unknown.

Grrr.

So, for this to be truly stable, such that any Output never changes regardless of the output window, that means I have to look for a series of navy bars equal to the "E" delay. That's do-able ... but the issue is "what if no such series appears, within the spec'd output range?"

Sigh.

That means I need to create an arbitrary chunk of fully-calc'd bars, BEFORE the requested output window (ie push back the warmup further), to allow room for E navy bars, then a complete wave, then at least one navy bar. But ... who's to say how many bars are needed for a complete wave? With EndV = 4 (high navy thresh and high warn thresh), and with a RASPEG spec that allows for nine Adds with relatively small PXits ... a trade *could* last 6 months ... in the study that a group did with me a year ago (ProfitGrabs), I had a specific trade that actually did last >6 months, without any "weird" settings.

Why does this matter?

Well, when a Return-Output is invoked, currently the code just calc's 10 bars ahead of the desired "target" output bar (for a FL or Scan or a calling routine), so that the "count" outputs (1-9) are correct. HOWever, with this WONderful new wrench in the works, that highly-efficient early concept, which clearly is inadequate, gets totally explodified.

Conclusion ...

1. My default bars-to-calc output will be 0, not 126 ... that is, attempt to provide all possible bars, not a specific window. This will allow for whatever long "pre-search" is necessary (described above), unless the # bars loaded is too small. I can create a popup message (or -999999 return value) for any cases where the pre-search was utterly unfruitful, and no "stable for sure" output values are available. In that case, I'll need some kind of special manual input to override or backwards-extend the search process.

2. This is going to be a problem for ANY Stradicators that use RASPEG ... which ideally will be all of them ... so I do need to find as elegant and efficient solution as possible.


Comments welcome if you see some hole in my logic ...
Top of the page Bottom of the page
JimDean
Posted 2/23/2019 7:55 AM (#9388 - in reply to #9387)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
It always helps to sleep on knotty problems before trying to code solutions to them ... I got some clarity on the issue in the prior post last night ...

===========

A. The RASPE thing has now been polished, which is great ... but the complexity of it (both coding and for users to understand) argues for it to be handled separately, outside of CVW (or any Stradicator, for that matter). So, I'm going to move it to TradeTrak ... which is focused on implementing full trades. This helps minimize the issue of output changing as Bars2Calc is increased, since without RASPE, there's no need to "keep track of" how many Adds have been allocated.

===========

B. There is still, in my mind, one underlying annoyance with the way CVW waves work ... sometimes they drag on long past a rational end (which RASPE would have solved) ... and sometimes they get false-starts in consolidation/transitional zones, or during pullbacks. Part of that can be tempered by changing the Bgn/End Vote inputs ... but doing so limits the usefulness in other ways. The new "three blue strips" rule will help some, but it kicks in pretty late, if at all.

===========

C. So, I'm lifting two (simple) features from RASPE to help out ... neither will complicate the "find a stable place to begin output" issue, but they will help with the issues noted above. A new Expert Input will be added to the VoteGuru ... WavEdgeCntAgrs2Cnsrv. That slider will do four things:

1. It will specify 1-5: off, 5, 4, 3, 2 successive medium-bars will create a warning-bar
... gen'd warning-bar will be olivegrn/maroon; medium-color-bar count restarts if a bright-color bar appears

2. It will specify 1-5: off, 5, 4, 3, 2 warning-bars will create an end to the Wave
... gen'd wave-end bar will be black; dark-warning-bar count restarts if a bright-color bar appears

3. It will specify 1-5: off, 1, 2, 3, 4 bar pause after Wave-end bar, before a new Wave can begin
... brights after end, during pause => alerts; pause includes black/navy that ends prior Wave

4. It will specify #opp-color brights req'd for a Wave-ending Reversal: half of the #3 value (or off)
... prevents "pure reversals" - any such opp-color bright becomes a warning; plotted as silver

5. "If it takes a lot to end, just a few allow begin" ... that rhyme is a memory aid regarding the opposite-interpretation of the slider for rules 1,2,4 versus rule 3. The idea is that the slider moves from Filter to Aggressive to Conservative (like its Guru does) ... Filter mode would have minimal delays between End and Begin, and would require tougher rules to End a Wave.

6. Return-values currently distinguish between bright,med,dark (dark=warn) within a Wave. Between Waves, return-values distinguish between neutral and bull/bear alert states. Warnings generated by rules 1 & 4, Wave-ends gen'd by rule 2, and Alerts gen'd by rule 3 will be treated the same as their "normal" counterparts. That is, Return values will not distinguish between gray or silver versus dark red/grn warnings, or between black and navy wave-ends, or between pause-bright-alerts and vote-based alerts.

7. The new expert-input will allow a negative override "-BER", where: B=#bgn-delay bars, E=#warn|end conversion bars, R=#bright-reversal bars. Each digit can be 0-9 ... 0 means to turn off that particular feature (R=0 means no reversals allowed, since OT cannot do a pure reversal with entry on same bar as prior exit).

... That new C algorithm will I believe greatly minimize the problem with waves continuing too long, abortive reversals during pullbacks, and false-starts during transition. It will be under user-control, and can be toggled off if the user feels their other trading rules protect them from those problems. It therefore acts as an effective substitute for RASFE in that regard ...

===========

D. With that in place, here's how the "search for stable output" process will work:

1. Warmup will be automatically increased by X bars, which will be "inserted" after the first "legit" output bar "could" appear, and during which, a search is made for a Navy bar ... ie one that is gen'd by a normal Vote or by three-blue-strips ... not a "black bar surrogate" from rule C.2 above.

2. If the #1 search is satisfied during the "X" period, the output begins then, with that Navy bar. If a Navy bar is not found during the "X" period, the output begins on the next bar, but a two horizontal thin white lines are plotted through the WaveBand, until a Navy bar is ultimately encountered (if ever).

3. If the #1 search is met, then the search continues (within "X" or after output begins) for a case where the C.3 "pause" rule has been met with certainty. During that extended search, a single horizontal white line is plotted through the WaveBand. This requirement is met once a *series* of Navy+Alert bars reaches the C.3 threshold, or after a full Wave has begun and ended (since a Wave can end due to C.2 even if a Navy bar does not hit).

4. Return-values are not tolerant of uncertainty, since they drive actual trades via Scans, Entries, Filters &/or Exits, or they show up in FL's, CC's etc that are used for discretionary trading decisions. Therefore, any bar that would have a horizontal white line (per rule 2|3) will have an "99999-error" value returned ... 999991 means a C.3 one white line case, and 999992 means a C.2 two white lines case. The "calling" routine (or Script) should be coded to handle these cases appropriately.

5. "X" will be a function of the 1-5 MAspeed input (not MAmeth-related periods) ... X = Input*10 bars ... maybe provide negative-override #bars via C's new Expert control-slider: XxxS, where S= slider value, and Xxx= search bars.

==========

Does all this make sense? Do you have any suggestions to improve it?
Top of the page Bottom of the page
JimDean
Posted 2/23/2019 11:03 AM (#9392 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
I only remove posts when they don't add relevant info ... or if someone reading through from the beginning might be confused by them due to a later change causing them to be *completely* erroneous.

For example, the last three posts offer no useful content for ongoing documentation, so once they've been out there long enough for y'all to read them, I'll delete them.

I do fairly often modify an existing post, adding/deleting/changing text, if I notice an error or omission in the original. That's why I suggest to team readers always to click on the link and jump to the forum to see the final version, rather than just reading the email content from the initial post. The forum post always is the most correct, AND it shows snapshots and bolding, etc, AND it provides attachments.

The alternative would be to create sometimes-multiple "correction" posts after the original ... interpreting that would be a nightmare.

Occasionally, if the changes to the original post are radical, I delete it and repost it with the changes, thus creating a new email notification.

I have found this methodology to work effectively.
Top of the page Bottom of the page
KenWilsdon
Posted 2/23/2019 11:22 AM (#9393 - in reply to #9388)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi Jim,

This IS a fairly elegant solution. While I'm disappointed I will have to wait for RASPE :-( , now that I finally understand it well, I totally understand why. A fleeting thought that did occur to me when I was struggling with it was that this was better put into a "control module for trading" (i.e, TradeTrak) than in each individual stradicator, but the whole RAS part with the 6 cases took my full attention.

Just a couple of questions.

1. In C1, the bars are successive medium-bars. You state in C2 that the bars are "warning-bars". Do you mean successive warning-bars here, or after X number of total warning-bars in the wave?

2. In C4, same question here: successive or total #opp-color brights in the wave?

3. Summarizing D, if a user (let's say) wants all bars on wave visible on screen to have no double or single horizontal lines through the bars at 126 (like we have often tested for the 6 month period, or whatever period they select), but they appear on his screen, the user will need to increase the 126 to some higher value to get rid of those bars. This may be the case if the user is trying to find which settings of PPM, Gurus, Experts work best over the entire visible period chart for a particular symbol. As in the case where you said the Profit Grab group had a run of over 6 months, this could happen. So they may want to increase it by one month (21 bars) or 3 months (63 bars), etc., to see if that eliminates the horizontal bars. Is that correct?

Concerning D5,

5. "X" will be a function of the 1-5 MAspeed input (not MAmeth-related periods) ... X = Input*10 bars ... maybe provide negative-override #bars via C's new Expert control-slider: XxxS, where S= slider value, and Xxx= search bars.

Is this a new separate slider, or is it the same as NumberOfBarsToCalc, or does this replace this slider? If it is new, just out of curiosity, what did you replace to get this slider position? I know you were maxed out of positions for one vertical panel.

All in all, a very good solution, and I am happy ;-) with it.



Top of the page Bottom of the page
JimDean
Posted 2/23/2019 11:50 AM (#9394 - in reply to #9393)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Thanks Ken

Re your 1 & 2 :
By successive I mean in a row. If a bright bar hits, it breaks the row and restarts the count. The series is not necessarily restarted with medium bars - see text of rule for specifics

Re your 3:
Incorrect (unfortunately), unless you’re lucky. The “X” bars occur befor the beginning of the requested output window size is, no matter what the size - increasing the slider size just changes the arbitrary start point - maybe the new shifted same-size X zone will get a clean hit and maybe it won’t. But any Band bars AFTER the white line will be legit for sure. And Band bars with just one white line *might* be legit.
I may provide a negative input option to define a bigger X.

Re slider:
Not sure yet what’s being pulled to make room. Existing Bars2Calck slider remains. Still evaluating whether CumV window needs a slider. Adding yet another would kill off all but one gray section divider - and if that happens, I’ll probably remove the other divider since there is no logical place for just one to be put.
Top of the page Bottom of the page
KenWilsdon
Posted 2/23/2019 12:46 PM (#9395 - in reply to #9394)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Thanks Jim,

Only one comment:

"I may provide a negative input option to define a bigger X."

I think that would be very wise. When there is only half (or so) of a 6 month chart to evaluate the fit of a set of inputs, it becomes less likely that such a pattern will continue into the future. Finding the correct setting would be a lot more difficult. Certainly, stocks can and do change in their characteristics, but if there is an easy way to get a closer fit (like a negative input), the better the near term results should be (logically).
Top of the page Bottom of the page
JimDean
Posted 2/23/2019 1:13 PM (#9396 - in reply to #9395)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
My plan is to experiment and make X big enough by default that it will be very rare for any double white lines to appear, and uncommon to see even a single white line. The cases that might create issues would be Filter patterns, where the specific beiginning and ending of a wave will be less important.

At least that’s what I would anticipate.

Note that whatever happens, if you make the calc window much larger than the period you care about, then the latter part of that window will be white line free. It’s the left side of the window that is the sensitive zone.
Top of the page Bottom of the page
JimDean
Posted 3/15/2019 12:42 PM (#9397 - in reply to #9388)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
I've modified the text and expanded the capability of "C" in the prior post #9388 ... please re-read. As you'll see below, I've added the input for this, and modified the first two Help screens to accomodate it (note both top and bot of Help#1 changed considerably ... I had to shuffle vertical space use a bit).

I chewed over all this stuff a lot, back and forth.

The two extra inputs (CumWindow and WaveEdge) push the # inputs to 14 ... allowing only one "separator" for Xprt. So, to make the most use of it, I moved what were the top two inputs down to just before the output controls ... the two GURU sections are first, visually separated by the all-caps GURU input-prefix.

The presence of those two experts "under" their Guru's means that the Core user will not be able to fine-tune them ... but their association with each Guru (timeframe and voting) makes complete sense, so I decided to keep Core simple by "hiding" them.

The routine has changed a lot since the original VOLeval DLL, so although the SBAS tests were very helpful in refining the inputs, I don't think I can use them to define "preferred Master" settings. And, y'all have said you're not really interested in doing more SBAS. This was a bit discouraging, but I fully understand why you feel that way ... and it created a lot of internal debate for me (part of reason for delay). Without some kind of external "input" to provide "tuned, preferred" Master settings, that input doesn't hold much value.

So ... I can:
a. delete it entirely ... maybe add it back in if/when I have time to do a bunch of SW runs
b. delay the offering further and ask for help with the SW runs, to define useful Master settings

I'd rather not delay, for several reasons. It would take time to set up and explain the tests, and decide how to eval the results ... and wait for testers to get the work done. Also, I need to get a move on, re other things.

My leaning is to go with "a", and just comment out the Master code.

What do you think of "a" vs "b"?

Here are updated snaps ... please review carefully and comment ...

(CVWeval V2 Parameters.png)



(CVWeval V2 HelpPanel-1.png)



(CVWeval V2 HelpPanel-2.png)



Attachments
Attachments CVWeval V2 Parameters.png (177KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-1.png (469KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-2.png (274KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 3/15/2019 1:28 PM (#9398 - in reply to #9397)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Here is a "c" alternative to consider for the Master slider. Please study the prior post before reading this, and consider the question to be "a, b or c" ...

c ... use "inituitive logic" for now, to set up Master patterns that generally relate to how the routine is being used ... as a Filter, or to define both Entry and Exit for Trades, or to prospect just Entries, or to specifically provide Exits. Later on, maybe, this could be revised or expanded based on SW runs.

9 Filter patterns: outer loop= Voting guru= 1,2,3 with inner loop = TimeFrm guru= 5,4,3
... Voting guru is set up to minimize choppiness with low values; TimeFrm guru presumably should be looking at the "big picture". Vote=1 + TimeFrm=5 would be *very* broad-brush

9 Trade patterns: outer= Voting guru= 2,3,4 with inner= TimeFrm guru= 2,3,4
... "big pic" Voting thru "more focused", and inner TimeFrm loop counterbalances that by starting with "tighter" sensitivity first ... but all combo's are represented

9 Entry patterns: outer= Voting guru= 3,4,5 with inner= TimeFrm guru= 3,4,5
... need a decent set of timely entries, so don't use Voting=1/2 which is broad-brush ... TimeFrm options similar to Filter but in reverse order ... don't use 1/2 to avoid late-wave or consol blips

9 Exit patterns: outer= Voting guru= 3,4,5 with inner= TimeFrm guru= 3,2,1
... for "tight" trades, exits should be timely ... so allow the TimeFrm to be more reactive


NOTE: this is intuitive ... if I embark on a "study" of this it will burn up a lot of hours and will only have just my opinion ... and (most dangerous aspect) might compel me to play with other inputs etc which opens up another pandora's box.

LATER: (maybe) ... if I have time to do SW runs focused on these four categories, then I could retain the 36 settings described above, and add more from the SW results.

NOMENCLATURE: probably I'd change from "PreferredPatternMaster" to something evocative of the above, like "MasterSetsFiltrTrdNtrXit"

I updated the snaps in the prior post to show this new name for the Master slider
Top of the page Bottom of the page
JimDean
Posted 3/15/2019 2:12 PM (#9399 - in reply to #9398)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Hmm ... Thot I was done with this ... but since no response to either postings or my texts, I'll add another thought to consider ...

I failed to consider that the CumVolMeth should be part of the Master variants. Since it applies equally to Core and Xprt, only the classic variants should likely be part of the mix.

However, maybe 36*4=144 is a bit excessive for the Master (???) ... alternative below ... ALL FOUR variants use CumMeth=1,2,3,4 as "inner" loop ... total = 16*4 = 64 patterns ...

16 Filter patterns: outer loop= Voting guru= 1,2 with middle loop = TimeFrm guru= 4,3
... Voting guru is set up to minimize choppiness with low values; TimeFrm guru presumably should be looking at the "big picture". Vote=1 + TimeFrm=4 would be very broad-brush

16 Trade patterns: outer= Voting guru= 3,4 with middle = TimeFrm guru= 2,3
... "big pic" Voting thru "more focused", and inner TimeFrm loop counterbalances that by starting with "tighter" sensitivity first ... but all combo's are represented

16 Entry patterns: outer= Voting guru= 3,4 with middle = TimeFrm guru= 3,4
... need a decent set of timely entries, so don't use Voting=1/2 which is broad-brush ... TimeFrm options similar to Filter but in reverse order ... don't use 1/2 to avoid late-wave or consol blips

16 Exit patterns: outer= Voting guru= 4,5 with middle = TimeFrm guru= 3,2
... for "tight" trades, exits should be timely ... so allow the TimeFrm to be more reactive

Please comment ... snaps updated ... I'll likely go with this "c" option, or something similar.
Top of the page Bottom of the page
Jump to page : 1 2 3 4 5
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.