Cumulative Volume Indicator DISCUSSION
JimDean
Posted 1/3/2019 9:17 AM (#9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Please use this thread for Q/A and Discussion about VOLeval, etc.

The thread with the distribution info is here: http://tradetight.org/forums/thread-view.asp?tid=1431
Top of the page Bottom of the page
JimDean
Posted 1/3/2019 9:55 AM (#9180 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Here are initial comments sent via email ... please post in this thread in the future ... thanks!

FROM MARK:

It sounds like it will “standardize” the visual so you don’t have to adjust your thinking as much to understand what’s being presented as you change options.

For marketing, a grid of “what you get” at each of the 3 levels would be good.

Some will be using the chart every day for visual confirmation of trades.

I’ll be using the chart to help me visually determine the best potential inputs and my primary use will be the return values - so I especially like the idea of a table listing all Return-input options and the value that they’ll return.

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

FROM SALIM:

Flabbergasted when I saw below - kudos to yah. I really have no comments on anything yet, till I test-drive the demo, which I confirm of receipt of it in your other email sent.

BUT (hehe), one thought while driving to work (which you may already taken care of somewhere below), in any case sharing, was to provide various options on Plot displays, i.e., if individual did not want to view Histograms but Large Horizontal bars only (can than shrink indicator pane), and so forth.

Other thought was - latency. This arises from observation of using MTV extensively, I observed a latency of 1-3 bars. I don't foresee that to be an issue on VOLeval, since each bar independently evaluated. Simply mentioning, but no biggie.

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

From observation of last nite's presentation, I feel the VOLeval may be invaluable to my methodology whereupon,

For example, I look for pockets of "imbalance" in price .... i.e., where "impulsive" buyers/sellers shoot price up/down, and "responsive" buyers/sellers step in to stop it, which may occur within the few bars between the Large-bar-In, couple/few small bars wiggle within, than, Large-bar-Out. That's the pattern I am search for "unfilled orders" where good chance price may Return too (i.e., still some buyers/sellers left out prior to that large imbalance earlier and emulate again the same move or possibly faze out).

Though I am not looking specifically at entry/exits from VOLeval, my objective would be to extract information from individual volume bars to provide me certain patterns I am interested in via Omniscripting, and make "decisions" based upon what I am viewing with all other price action formation and other indicators.... which for me a bit of pre-planning for entry/ exit is needed for that ultimate expectation of price turn to possibly happen or not at the designated few Bars, which VOLeval may point it out for me beforehand.

Great for Option traders to formulate their strategies to.
Top of the page Bottom of the page
JimDean
Posted 1/3/2019 9:58 AM (#9181 - in reply to #9180)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

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

If you could provide more detail re your understanding of and feelings about each bullet point (esp section D), that will help ... a lot of time is involved in this work and I want to choose a path that each of you feels is likely worthwhile. And yes, there will be a grid ... but more importantly, a walkthru video that gives quick overview-training and comparisons of the three versions.

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

Hi, Salim

Re latency... sorta par for the course when using MA's ... but I do provide choices and their MA periods are actually pretty short (speed=1,2,3 use 8,12,16 periods ... and WMA has minimal lag). Slope periods are short also (2,3,4). So, barring very extensive work to implement some Ehlers MA's (hard to create "bounded" versions of those), or maybe adding in ZMA, it is what it is. I'll consider a bounded ZMA if I can figure out how to iteratively calc it.

Re the new plot thing ... I think that you'll find the proposed layout to be quite handy-dandy without any variants of it. If I'm wrong, I'll probably see it as I do the work, and will provide a simpler form. Coding for plotting is time consuming so I don't want to arbitrarily generate alternatives.
Top of the page Bottom of the page
JimDean
Posted 1/3/2019 11:58 AM (#9187 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
As I said, I don't yet have 2019 installed, so I've not yet compiled things for it.

It takes me a long time (aprx 4 hours) to set up a new year's installation on my machine ... lots of steps besides the normal procedure. I'll be doing it within a month ... hopefully you can get by with OT 2018 for the nonce.

The testing that I requested does not require any other indicators.
Top of the page Bottom of the page
JimDean
Posted 1/3/2019 2:45 PM (#9189 - in reply to #9187)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

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

During the demo session, I tried to quickly check/confirm that the return-output focus-list t,p,k "counts" were correct, when compared to an identically-configured plot. I had the return-param BarsToCalc set =10, to minimize calc time, but to allow for up to 9 bars to have the same state for counting (the output counts max at 9 bars). The plot BarsToCalc was defaulted to 126 ... which should provide the same (visual state) bar count.

I found what seemed to be an error ... the counts for bars with a given Slope-Vote (-3 to +3) did not match what the Plot seemed to be saying when set to +2 for Slope colors. I've been laboriously testing that ... for Slope, Stack and TrdZon return-counts vs plot-counts.

I was able to repeat the error ... and beat on it with lots of debug outputs. But I couldn't seem to figure it out.

Then the head-slap moment occurred. It turned out that I had *one* of the input param's for the FL column different (fast MA speed) than that param for the plot (med MA speed). After a loud Argh, I made them identical, and repeated my tests.

It turns out that all is well ... there was no bug. Apparently my rapid jumping around during the Skype session created a disparity of the inputs.

Just so you know ... the math in your DLL is correct.
Top of the page Bottom of the page
JimDean
Posted 1/3/2019 3:37 PM (#9190 - in reply to #9189)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
OK I've been doing some testing on my "3 favorite" symbols, over the 6-mo timeframe. I've got some preliminary conclusions regarding the value of the PVT method (7&8), which earlier I had thought possibly to kill off ... PVT used to be inputs 3&4 (natural progression from OBV, since neither use intra-candle info).

I've now concluded that PVT is a viable candidate, so I am moving it back to the 3&4 inputs as it was earlier. This will differ from your DLL, but only in the sequence not in the results.

I've been also testing PVT and III methods with four different Sliding Window settings (1-4 = Wide to Tight). The Windows seem to have a significant impact on the results, so I consider this an important tuning opportunity ... especially since my starting point of 110,84,60,37 bars (the help has this backwards) was pretty arbitrary.

From my limited 3-symbol, two method tests (all other inputs default), it seems pretty decisive that "4" (the tightest 37-bar window) is consistently worse than the three wider windows.

Also, it appears that "1" (the widest 110-bar window) is not as good as 2 or 3, but it's not as bad as 4.

These, by the way, are the kinds of "conclusion summaries" that I hope to hear from y'all, regarding all the different inputs, using the test procedure I outlined.

SO ... for my in-progress revision, I'm going to modify the assignments of the Cum Window bars to home in on the apparent sweet spot. The new Wyd2Tyt bars for 1-4 will therefore be 110, 90, 70, 50.

Y'all don't need to change your testing ... except maybe prioritize testing sequence for the CumWndoWyd2Tyt using settings of 2, 3, 1, 4.
Top of the page Bottom of the page
JimDean
Posted 1/4/2019 11:29 AM (#9196 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Here are specific characteristics that I'm suggesting you "score" in the ten columns. If we all use the same approach, it will be MUCH easier to consolidate the results. Scoring: 1=poor, 5=great.

"Characteristics" to evaluate ...

Lag (ie delays in starting &/or ending the TradeZone)

Chop (ie whether a "visual price-trend run" has a continuous TZ, vs one that is on-off-on-off)

Dir'n (ie incorrect when TZ's show up in "flat" choppy-price areas or in the wrong bull/bear direction)

Mark, if you feel up to it ... maybe you could tweak the XLS to show three sets of three columns, with these labels, for each of three Symbols ... and one Total Score column.

Thanks for helping to get this process organized ... it will really add value!
Top of the page Bottom of the page
JimDean
Posted 1/4/2019 4:12 PM (#9199 - in reply to #9196)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
OK ... I've made a huge amount of progress today. I got the new Plot panel in very quickly, and it's just as nifty as I'd hoped. I also got *most* of the Help panels updated ... there are now SEVEN of them. Panels 5 & 6 provide fully revised descriptions of the new -1 to -33 Return options.

There were a bunch of earlier fixes as well, described in prior posts.

My plan was to get this recompiled and out to you by 6pm ... and I didn't expect to have all the new features working. However, I am SOOOO CLOSE right now (4p), that I'm going to finish up the important stuff ... I need to revise the Return output code to match the new patterns described in the Help. You won't be using this for the group-testing process, but after that I think you'll want to play with it.

Therefore, the new DLL will be out to you maybe by 8-9 PM, with everything but the (possible) additions of two Guru sliders, and spawning of Powr vs Flex vs Edge versions.

Here are snapshots that will likely be helpful to you ... plus a Zip file with all of them. You should read them ;~)

NOTE: I have updated all the attachments (Zip and Snaps) in this post, after the final release in the wee hours. So, the panels displayed here are the "official A2 version". The DLL is available from the attachment at this link: http://tradetight.org/forums/thread-view.asp?tid=1431#M9203


(VOLeval A2 Combo Plot.png)



(VOLeval A2 Details Plot.png)



(VOLeval A2 Parameters.png)



(VOLeval A2 HelpPanel -1.png)



(VOLeval A2 HelpPanel -2.png)



(VOLeval A2 HelpPanel -3.png)



(VOLeval A2 HelpPanel -4.png)



(VOLeval A2 HelpPanel -5.png)



(VOLeval A2 HelpPanel -6.png)



(VOLeval A2 HelpPanel -7.png)



(VOLeval A2 Returns 1-33 (Landscape).png)



Attachments
Attachments VOLeval A2 Params, Help & Charts.zip (5032KB - 0 downloads)
Attachments VOLeval A2 Combo Plot.png (25KB - 0 downloads)
Attachments VOLeval A2 Details Plot.png (24KB - 0 downloads)
Attachments VOLeval A2 Parameters.png (255KB - 1 downloads)
Attachments VOLeval A2 HelpPanel -1.png (193KB - 0 downloads)
Attachments VOLeval A2 HelpPanel -2.png (249KB - 0 downloads)
Attachments VOLeval A2 HelpPanel -3.png (332KB - 0 downloads)
Attachments VOLeval A2 HelpPanel -4.png (302KB - 0 downloads)
Attachments VOLeval A2 HelpPanel -5.png (237KB - 0 downloads)
Attachments VOLeval A2 HelpPanel -6.png (252KB - 0 downloads)
Attachments VOLeval A2 HelpPanel -7.png (340KB - 0 downloads)
Attachments VOLeval A2 Returns 1-33 (Landscape).png (310KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 1/5/2019 10:42 AM (#9207 - in reply to #9199)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
OK ... this is overkill but I think a viable method to download the A2 DLL is available now. For some reason, the initial zipped copy did not work on my original post last night. So I created a new post with three variants of attachment packaging, and then downloaded all of them, and tested each individually in OT. THEY ALL WORK (per the appropriate instructions). Here is the link to that new post:

http://tradetight.org/forums/thread-view.asp?tid=1431&posts=7#M9205

I also tried emailing those three variants to each of you ... as per usual, "mr sucky google" rejected every one of the gmail attempts. Mark please let me know if the copy to your comcast account worked, and which if any of the attachment types made it through alive.

Don't forget to make sure the final seven characters of the file are "nsl.dll"
Don't forget to right click > properties > UNBLOCK
Top of the page Bottom of the page
SalimHira
Posted 1/5/2019 11:02 AM (#9209 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
Good Morn' All,

I confirm to have successfully implemented the new A2 version.

If anyone needs me to send the DLL from my email, can do so, not sure if it'll help, but can try.

I'd like to test these symbols: ATVI, QCOM, and MAT.

Thanks.
Top of the page Bottom of the page
JimDean
Posted 1/5/2019 11:06 AM (#9210 - in reply to #9209)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Yaay! A spot of sunshine!

Salim, I know you got the email copy ok because it always worked before. If you would like to simply go back to the very original post with the A2 announcement and instructions, you’ll see that I redid the attachments (with explanations). Please test those, and let me know your experience. I’d like to clean up all the other postings.

Thanks!
Top of the page Bottom of the page
MarkHolstius
Posted 1/5/2019 11:12 AM (#9211 - in reply to #9207)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 210
100100
Location:
USA: IL, Sleepy Hollow
Everything's working fine now for me too.

Jim - any chance you could snag an example or two of areas / plots that you see as fitting your characteristics (especially with the great new plots) where 0 is good and 5 is the worst?

1) Lag (ie delays in starting &/or ending the TradeZone)

2) Chop (ie whether a "visual price-trend run" has a continuous TZ, vs one that is on-off-on-off)

3) Dir'n (ie incorrect when TZ's show up in "flat" choppy-price areas or in the wrong bull/bear direction)

Each of the 3 of us testing may have different standards for what constitutes / defines each of the 3 and it would be unfortunate to do 1000's of tests based on incorrect assumptions.

Mark
Top of the page Bottom of the page
JimDean
Posted 1/5/2019 11:35 AM (#9213 - in reply to #9211)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Hi, Mark ... I suppose that I could horse around for an hour and sift through things to provide illustrations ... that would effectively calibrate your eyeball and mind to be similar to mine. That *might* be wise ... or maybe not.

One of the benefits of having three helpers with this is that we apply four different minds and viewpoints to this "holistic" evaluation. I don't want y'all to use a microscope for each chart ... I want a ten-second (max) look-see, and three scores regarding whether you think the VOLeval TradeZones shown for that chart with those param settings are "generally helpful for trading" ... by scoring it re Lag, Chop and Direction.

I think that all of you likely know what those three words mean ... I described it to each of you on the phone individually, and I posted a short definition.

If I go any further than that, then I'm guessing you'll try to find out which charts "match" the ones I post as examples ... and you might be "observing" something on my samples ... unconsciously ... that I did not intend. I've found in the past that charts sometimes confuse the issue ... since everyone "sees" something somewhat different.

Having said all that ... here are two charts. I did not work hard at all to find them. Bot are QCOM ... the first uses default settings, and the second has all the "play with these" param-sliders all the way to the right (maxed out) ... except for the CumMethod=4 which needs to be the same for apples to apples.

I think it should be hugely obvious which is "better" that the other one ...



(Sample Using Defaults - QCOM.png)



(Sample Using RS-pinned - QCOM.png)



Attachments
Attachments Sample Using Defaults - QCOM.png (173KB - 0 downloads)
Attachments Sample Using RS-pinned - QCOM.png (175KB - 0 downloads)
Top of the page Bottom of the page
MarkHolstius
Posted 1/5/2019 11:50 AM (#9214 - in reply to #9211)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 210
100100
Location:
USA: IL, Sleepy Hollow
Another “Heads up” / question Jim,

In your instructions you specify;

3. Lock in SpikeCap = 2, LastBar=0, BarsToCalc=126, MixWtd input=3, and MAvgSlope input=2. The calc's and impacts of those features are already fully tested and their impacts are predictable and not terribly significant. Don't change any of these values during the testing described below.

In the updated version, the MAvgSlopePdsFstSlo default value is 3;

Just want to clarify whether you want us to change it to 2 or leave it at 3?

Mark


(defaults.png)



Attachments
Attachments defaults.png (118KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 1/5/2019 11:56 AM (#9215 - in reply to #9213)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Here's a little more info to work from ... you need to wander around and play with variations of params a bit on your selected symbols, to get a feel for the range of how things can change. That will give you some *persepective* ... which will be useful if you stick to the three symbols you've chosen:

Salim's symbols ... ATVI, QCOM, and MAT
Mark's symbols ... SPY, PAYX, and HAS
Lou's symbols ... PCAR DLTR TSCO

RE: Lags
All indicators that use MA's and LRS's have lag. The questions here are ...
1. is the start of the TZ so late in a run, that it likely would not overlap earlier signals, or (worse) that it allows trades to start only near the tail end of the run, when it's about to reverse? If so, that's BAD.
2. if the start was "okay", but the endpoint of the TZ drags out way waaay past the point where the run exhausted and possibly even reversed, then that might allow a new trade to start too late. If so, that's BAD.
... there's almost always more Lag with longer MA and LRS speeds, and using pure-SMA's (and max fuzz)

RE: Chop
The more reactive (less laggy) that you make an indicator, the more it tends to fragment ...
1. since this is not a "trading strategy", it's not necessarily bad if the TZ starts at a good place, early in a run, but then turns off before the price move has fully completed. But if a whole lot of little TZ's appear throughout the course of the run, even late in the run, it's hard to distinguish which is best, and that's BAD.
2. if a "choppy" TZ input-pattern gives decent early flags for runs (as per #1), you also have to consider that maaybe your normal entry-signal-generating System won't happen to fire a signal precisely within the small choppy TZ points ... so you'd miss out on the trade, and that's BAD. (unless you're using the TZ *as* the entry signal).
... there's almost always more Chop with shorter MA and LRS speeds, and using pure-WMA's (and no fuzz)

RE: Direction
Sometimes the market gets jittery and volume spikes or price pop/drop appears, without going anywhere ...
1. when the input param settings seem to allow bullish TZ's to show up during times when Price seems to be pretty consistently bearish (or untrade-ably flat), or bearish TZ's when price is bullish or flat, that's BAD.
2. if those #1 kind of bad TZ's appear and are pretty "wide", rather than just being a bar or three "blip", then it's more likely that your entry system might fire (by mistake, too) ... and that's REALLY BAD.
... my guess: correct Direction is most likely a function of the selection for CumMethod and SlidingWindow


OKAY ... I hope that helps!
Top of the page Bottom of the page
MarkHolstius
Posted 1/5/2019 12:09 PM (#9218 - in reply to #9214)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 210
100100
Location:
USA: IL, Sleepy Hollow
Thanks Jim,
Nothing changes in the spreadsheet because that (MAvgSlope) isn't one of the variables we'll adjust.
Mark

(Not sure why this posted above yours...)

Edited by MarkHolstius 1/5/2019 12:10 PM
Top of the page Bottom of the page
JimDean
Posted 1/5/2019 12:39 PM (#9221 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
REMINDER:

Although Mark's spreadsheet is INCREDIBLY helpful, please remember that it's only *one* of the 8 steps that I wrote out (second post in the Distribution thread).

Note that after the spreadsheet is completed, it that post says ...

7. From your observations in 6.a-e, write out a list of (at least) ten different input-patterns that you feel are *the* most useful. That is, each pattern will specify five numbers ... one from each of the a-e choices. Be sure to send that list to me. If you provide more than ten, great (using a spreadsheet to keep track during tests might be smart) ... but please try to "sort" the list (somehow) if >10 choices.

8. Last step: for each of the top-ten input-pattern selections (lock in one at a time), vary the CumSlidWndo input (1, 2, 3, 4), checking your selected Symbols for each, and "grade" the results ... that is, whatever, metrics or holistic gut feel you used to determine the ten-best in step 7, use that same means to decide for each pattern which are the *two best and two worst* CumSlidWndo selections (not counting 0).
Note: this step is IMPORTANT, but requires the others to be completed first to make its results meaningful. The CumSlidWndo input has a big impact, but its current 1,2,3,4 settings are somewhat arbitrary ... I will use your feedback to change the window-sizes related to 1,2,3,4 inputs, to home in on the "ideal".



When I wrote that, the spreadsheet with automated total scores that are all sortable was not part of my thinking. But with those capabilities, the "top ten" mentioned in step 7 should probably be the "top 50" or so ... based on the distribution of SORTED total scores.

Step 8 is *important* ... since it affects things a lot ... but because the internal window options are arbitrary (this is a unique idea with no "industry standards"), I didn't think it made sense to add yet another full tier to the #6 arrangement (ie another column and lots more rows on the spreadsheet). So, please don't forget about step 8 ... and please do run through those tests on as many of the "high scored" input-patterns from your #6-completed SS, that you can afford to spend time on. I suspect that input will be one of the "crucial" ones ... so more data is better.

Thanks again!
Top of the page Bottom of the page
JimDean
Posted 1/5/2019 12:49 PM (#9222 - in reply to #9221)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
I've just gone back to that "instructions" posting and added some bolded annotations that y'all should take a look at, please ...

http://tradetight.org/forums/thread-view.asp?tid=1431&posts=7#M9176
Top of the page Bottom of the page
MarkHolstius
Posted 1/6/2019 11:33 AM (#9227 - in reply to #9223)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 210
100100
Location:
USA: IL, Sleepy Hollow
There are a number of problems I found while using the spreadsheet yesterday that I’ve tried to address with a new version of it that might help you as you continue testing, Salim and Jim.

The time spent looking at a chart is just a small portion of the testing and data collection.

I wasn’t as familiar with the naming and organization as you are, Jim, so I had difficulty locating the correct input to modify. VolObOg, MApdsFMS, FuzzyEquiv, & TrdZonBgn, didn’t correspond with the actual Param names, and I was also losing time making sure I was changing the correct one in the vertical param list vs the horizontal list in the spreadsheet.

It also took time make sure I was entering the correct value in the correct cell (Lag, Chop, Dir) for each Symbol.

And, time is also lost when moving from the SS to OT and back.

To alleviate some of those problems, I’ve modified the spreadsheet so that it resembles the input for the indicator and highlights which value needs to be changed as you work thru the 540 tests (1,620 chart views, 4,860 cells to either leave as 0 or change to 1-5).

Column A matches the indicator inputs, with the ones Jim wants to be modified highlighted in green.
You’ll find that you can scroll left and right and the value to be changed on the next run is highlighted in darker green.
Entries can be made in rows 18-26 for each of 3 symbols.
Those cells appear blank due to conditional formatting. They actually contain zero and will change to blue when any number is input.
The sums, average, etc., are at the far right and the data will probably need to be copied / transposed to facilitate analysis and ranking when complete.

I won’t be using the spreadsheet at this time, but thought it would be of value to you.
It’s extremely difficult to manually enter data in almost 5,000 cells without errors (essentially impossible with that many from my experience), so I hope this will help minimize the data entry error problem.

I’ll hopefully be sending my results later today.

Mark


(modified spreadsheet.png)




Edited by MarkHolstius 1/6/2019 11:36 AM

Attachments
Attachments modified spreadsheet.png (104KB - 0 downloads)
Attachments Initial testing grid modified.xlsx (51KB - 2 downloads)
Top of the page Bottom of the page
MarkHolstius
Posted 1/6/2019 2:19 PM (#9228 - in reply to #9227)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 210
100100
Location:
USA: IL, Sleepy Hollow
Here's another update to the spreadsheet that may avoid some more entry errors by color coding the measurements.
Also added row 27 so you can enter a 1 to note that the test has been done (it tracks those completed - even if they had all zero's).
Also added summations in rows 28-31 for future analysis.

Salim - you can start using this wherever you left off on your other one if you want, and if you'll attach your "old" spreadsheet I'll transfer your data to this new one and we can combine them.
If you want, you can attach the old one and I'll transfer it before you start again.

Mark

(modified spreadsheet ver02.png)



Attachments
Attachments modified spreadsheet ver02.png (151KB - 0 downloads)
Attachments Initial testing grid modified ver02.xlsx (67KB - 1 downloads)
Top of the page Bottom of the page
JimDean
Posted 1/6/2019 2:38 PM (#9229 - in reply to #9228)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

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

The changes look interesting, BUT ... I just realized that this SS will NOT work for the two major purposes that I outlined in my email several hours ago. Please go back and re-read it ... you'll see me mention "sorting" a couple of times, to help me mine data.

In my version of Excel (2007), the Sort feature only allows me to sort on COLUMNS, not on rows. Your original spreadsheet, which DOES work for my primary needs, has rows and columns flipped compared to the new one.

Can you please flip rows vs columns on the new one?

If not, please do not submit results to me in this new format, since I won't be able to use the sheet to do my data mining.

Sorry if this means you wasted a bunch of time. I didn't realize that you were reversing the layout.
Top of the page Bottom of the page
JimDean
Posted 1/12/2019 1:22 PM (#9242 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Need some advice, asap please ...

First, skim the post I just made in the Training thread:
http://tradetight.org/forums/thread-view.asp?tid=1433&posts=5#M9241

RE: Intermediate variances on "neutral" (vote=0) cases for Slope, Bar, and Stack votes)

I recently created "alerts" for the main CVwave (aka TradeZone) colors and return-values ... so now, the "navy" color can be purple or darkgreen when it looks like a new bear or bull Wave is about to start. I've echoed those colors in the return output, as a "neutral set" of 4, 5, 6 (where 9-7 are bull and 1-3 are bear). So, range for "T" is 1-9.

Since the individual net-vote-ranges for Slope and Stack (Bar is a special case) can go from -3 to +3, the Return outputs go from 2-8 rather than T's 1-9 (above). I'm thinking of creating nuances on the "neutral" zero-vote for these as well ... so the 1-9 pattern is consistent.
Note that a "neutral=0" vote comes about by all three slopes being = fuzzy-0, or one =0 and the other two -1 and +1 ... or by one +2 and the other two each -1 ... or one @ -2 and others @ +1 ... or one zero and others +2 and -2 ... or one zero and others +3 and -3 (these last two are pretty unlikely). The point is that a "zero" vote can represent different situations.

So, if I created the intermediate-zero vote cases, where 5= pure zero and 4/6 being sort of bear/bull "alerts" ... then I need logic to make that decision. Earlier, Salim suggested to me that looking at the slope of the votes themselves (ie the lime/blue/crimson curves on plot#2) ... so maybe I should do that to determine the alerts.

That is ... if the sum of the regular votes nets out to be zero (maps to "5"), then I parse that into 4,5,6 using the net *slope* of those votes. The slope would be simple ROC ... ie diff between the bar's value and the prior bar's value ... which could be anything from +6 to -6 but normally is between +2 and -2. If the sum of those ROC-slopes is, say, > +1, then the neutral would become a bull alert for that Slope/Stack category ... if sum of ROC-slopes is < -1 then it would be a bear alert. (I would see how it hashes out on some charts to decide what the +1/-1 threshold should be).

Finally, although the BarVote only counts for 1, I've created nuances for it already ... I'd expand those using similar conceptual logic, to have three intermediate states.

Summary: all output return-states, and color-palletes, would have nine states, and the nine would always be in groups of three-threes. (this is very much like MTV btw). If the user wanted to build filters or logic that uses "alerts", they could do so either on the overall CVW state "T", or on the component Slope, Stack, and Bar (P,K,B) states.

LATER: I implemented the 4,5,6 distinction for the non-TZ-wave cases, but not via the slopes approach ... it's simply tied to a relatively low number of votes (scaled by the Bgn/End inputs).
Top of the page Bottom of the page
KenWilsdon
Posted 1/23/2019 12:06 PM (#9249 - in reply to #9242)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi everyone,

I am jumping on the beta testing late. Trying to get up to warp speed from impulse.

The symbols I have chosen are AAPL,PAYX,HAS (the latter 2 because they were on the group of 3, and Mark has other commitments).

====
Jim
====

Your idea about a reentry signal is a good one in the last post where you asked our opinions. Will get to the post prior to that when I am no longer filling out SS.
Top of the page Bottom of the page
JimDean
Posted 1/23/2019 4:09 PM (#9252 - in reply to #9249)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
IF YOU HAVEN'T STARTED THE STEP-6 TESTING YET, then use the newly-posted MOD-10 spreadsheet here:
http://tradetight.org/forums/thread-view.asp?tid=1431#M9251

KEN: If you've already started using MOD-9, no sweat ... I'll transfer your data when you send it to me. There is no difference between the two for the first tab, which is the only one you use for Step6. I explained the Step-7 (my job) and Step-8 (phase two for you) process in great detail in that post.

SALIM: I emailed you a copy of the MOD-10 with your Step6 info in it, and did my Step-7 thing to prep it for Step-8 for you. USE THAT SHEET ... but READ THE INSTRUCTIONS in the linked post and call me if you don't understand 100%. Thanks.
Top of the page Bottom of the page
JimDean
Posted 1/23/2019 7:28 PM (#9253 - in reply to #9252)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Repost from above ... info

This is simpler than the prior question, but both are needed to get this tied up.

Currently, each of the categories T,P,K,B (and XYZ and ABC) for CVW, Slope, Stack, Bar net votes and individual Fast/Med/Slow-MA slope + FvS,FvM,MvS-MA stack votes have DURATIONS tracked, and output (the lower case t,p,k,b,x,y,z,a,b,c values previously described ... such as for Return = -1 being Tt.PpKkB, etc).

Currently, each of the duration counts tracks the overall state ... ie bullish, neutral, bearish ... the counts currently do not restart when the brightness of the color changes ... they only restart when green changes to red or navy, etc.

Keep in mind that duration output max out at the single-digit "9" count.

I'm thinking that maybe I should change the duration counts to restart every time the brightness changes ... that is, a lime green to a medium green would restart the count, etc.

Reasoning for this ... *during* a "wave" (if this is being used for entry logic), each time the color goes from dim or medium back to bright, that would seem to be a good time to re-enter or maybe add-on to the position. And if that's desireable, the duration-value being "1" (with the state being 9 or 1) would be the flag that tells you to do it.

Subsequent change (A3 version)
I've made the native mode track each color-variant ... ie any time a Vote or other metric with a Return value of 1-9 or 2-8 changes to another value, the counter increments (max's out at 9). You can toggle this to just track the "sign" (ie green vs blue vs red) of the value by putting a minus sign on the FuzzyBand input (ie -3 not 3).
Top of the page Bottom of the page
JimDean
Posted 1/23/2019 7:29 PM (#9223 - in reply to #9222)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Repost from before, with additional info ...

Starting to ruminate about what the inputs would look like, if I added two Gurus. Arbitrary limitation (related to OT param panel popup) ... max height of 15 lines (param's plus "section-separators").

This would be slightly-rearranged "VOLxprt" version ... same pattern-inputs as now, but with Cap input deleted, and LastBar+Bars2Calc combined ... per the "nifty" explanation at the end of this post. Removal of those two not only reduces what user needs to fuss with, but also frees up two "slots" for the new gurus (so as not to force a second column on the Parameters Pane).

My prelim thinking re Guru mapping ... this may well change once I am able to review your spreadsheets ...
TimeFrame Guru provides automated settings for the following three expert sliders, and contributes to the automated setting of the fourth (MAvgSlopePdsFst2Slo).
Frequency Guru provides automated settings for the following three expert sliders, and contributes to the automated setting of the one just above it (MAvgSlopePdsFst2Slo).

VolCumulMethod expert slider is independent of the two Guru's since it's the core focus of the Indicator.

NOTE: if it turns out that CumSlidWndoWyd2Thn does not "mesh" well with the TimeFrame Guru ... I suspect that it will not ... then in that case I would move it down just below the VolCumMethod slider (making it independent of the Gurus), and would fully map the control of MAvgSlopePdsFst2Slo to the TimeFrame Guru (rather than also mapping it partially to the Frequency Guru). Again ... these mappings are just prelim guesses ... may well change after I've data-mined your spreadsheets.

... Layout Section ...
TIMEFRAME_GURU ... Short2Long ... controls next 3 and influences MAvgSlope
MApdsFMSorSm2Lrg
MixWtdHweExpHesSim
CumSlidWndoWyd2Thn ... if VolObOg=0, then CumSlid input sets RawV SpikeCap
MAvgSlopePdsFst2Slo

... Voting Section ...
FREQUENCY_GURU ... Many2Few ... controls next 3 and influences MAvgSlope
FuzzyBandNone2Large
TrdZonBgnCmbNetVote
TrdZonEndSepOppVote

... Overall Control ...
VOL_CUMUL_METHOD ... VolObOgVpVgAdAtNiNt
BarsToBeCalculated ... combines LastBarToCalcB4HRE & NumberOfBarsToCalc
OutputReturnHelpPlot


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

QUESTION: if the "full" version (VOLxprt) has that set of 12 inputs (+3 headers), where nonzero values of the non-Guru inputs serve to override the "auto" settings implied by their related Guru (if any) ... THEN, would there be a "marketing" need for an "easy" version (VOLeasy or VOLcore) that has only these 5/6 inputs ... ?

TIMEFRAME_GURU ... Short2Long

FREQUENCY_GURU ... Many2Few

VOL_CUMUL_METH ... VolObOgVpVgAdAtNiNt

(maybe also CUM_SLIDING_WNDO, if one of its settings isn't clearly "the best")

BarsToBeCalculated ... Output window

OutputReturnHelpPlot ... Output format


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

NOTE: In order to replace LastBar and BarsToCalc inputs with just one, I apply some logical reasoning. The BarsToBeCalculated input is an integer slider from 0 to 260, but allows neg# manual input. Its input value is interpreted differently, depending on whether a Plot output or a Return output is desired.
=== Return outputs usually just need 10 bars calc'd, so that the various "duration digits" can have their full 1-9 bar range ... the main thing re Return is to be able to specify the *final* bar, which is being displayed in FL or used for a Scan ... so, when Return is spec'd, the integer in BarsToBeCalculated *means* "#bars before HRE for last calc'd bar". (manual negative# input spec's a particular YYMMDD bar-date)
=== Plot outputs usually go all the way to the HRE, but sometimes only the most recent few months or couple of years are needed ... bars before that just waste calc time ... so, when Plot is spec'd, the integer in BarsToBeCalculated *means* "#bars to plot, ending at the HRE". (manual neg# input means plot all bars to the left of a gap on the right - input defines gap size)


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

In the A3 version, I've modified five inputs so their ranges start with 1 instead of 0 (and of course the default and max inputs increase by one) ... all the logic remains the same. PURPOSE ... once Gurus are added, the Expert sliders that a Guru rules over will be ignored (ie Guru-gen'd value for them will be used), for every such slider that has a ZERO input. The inputs affected by this are: SpikeCapOffTyt2Wyd, MixWtdHweExpHesSim, VolObOgVpVgAdAtNiNt, CumSlidWndoWyd2Thn, FuzzyBandNone2Large

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

The snapshot below has notes that might help explain how the Gurus consolidate existing inputs ... this results in the 15-line "full" list of inputs above ...

(Guru Param Ideas.png)



Attachments
Attachments Guru Param Ideas.png (277KB - 1 downloads)
Top of the page Bottom of the page
JimDean
Posted 1/25/2019 12:34 PM (#9256 - in reply to #9223)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
(third reposting of this info ... had to clean up the snaps and some text ... sorry for repetition)

Informational Update re Progress ... no need for y'all to do anything ... most of these things have been mentioned in prior posts, and this post just announces their completion and implementation ... note that this implements the new Guru's (not yet functional), and rearranges inputs, etc as described in post just before this ...

Here's what I've done so far (broad strokes) for the A3 version (y'all have A2):

• dual-strip middle in Plot#2 (was #1), and big changes to Plot#3 (was #2)
• created minimal plot-1 with TZ band and 3 strips
• allow CumTyp=0 to have +incV /-decV TZ's (not bull/bear)
• Slope pds FMS input => 1-3 (2, 4, 6) with opt neg actual pds 2-10
• reverse Rtn minus-sign flag => NOT in active TZ
• Colors: Bgn7: 7, 6-4, 3-0; Bgn6: 7-6, 5-3, 2-0; Bgn5: 7-5, 4-3, 2-0
• ReturnT: 9 8 7 9 8 7 9 8 7
• TZ colors = grn/red, brighter for TZ votes closer to TrdZonBgn, new 1-9 map:
..... Bull TZ: 9= maxTrdZonBgn, 8= medTZvotes, 7=fewTZvotes ... 7= "warning"
..... TZ Off: 6= almostBullTZ, 5= no clear bias, 4= almostBearTZ ... 4 & 6 = "alerts"
..... Bear TZ: 1= maxTrdZonBgn, 2= medTZvotes, 3=fewTZvotes ... 3= "warning"
• neg FuzInp sets CntBig => counts track +1/0/-1 sign, vs std 1-9 detail levels
• shift param ranges >0 (prep for later Gurus): SpikeCapOffTyt2Wyd,
..... MixWtdHweExpHesSim, VolObOgVpVgAdAtNiNt, CumSlidWndoWyd2Thn, FuzzyBandNone2Large
• merge LastBarB4HRE & NumberOfBarsToCalc to BarWndoToCalculate (0=all):
..... Rtn: assume 10 calc bars, input= LastBarB4HRE; neg= ALL bars preceding LastB4HRE
..... Plt: assume thru HRE, input= FirstBarB4HRE; neg= plot all to the left of that gap
• add Rtn's 31-38 for B.bUuHh; 39=cappedV; 40=CumV; shift T.tPpKkB
• remove SpikeCap input (for any Cum calc assume inp=3, else SlidWndo def's Cap)
• revise gray param section headers and add two (nonfunctional) GURU param's
• updated first and second Help panels for all prior changes

So, the existing "expert" inputs are now pretty much ready for the two new Guru inputs to made functional, once I get the Step8 info back from Salim and Ken ... and the Plot revisions and Return expansions are completed ... and I've gotten a start on the Help panel revisions. Here are snaps of the new Param's panel (with two nonfunctional Guru inputs, and a two of the Expert inputs moved) ... and the first two Help panels ... note especially the major changes to the summary of Return-value options shown on panel#2 ...

(VOLeval A3 Parameters.png)



(VOLeval A3 HelpPanel -1.png)



(VOLeval A3 HelpPanel -2.png)



Attachments
Attachments VOLeval A3 Parameters.png (173KB - 0 downloads)
Attachments VOLeval A3 HelpPanel -1.png (302KB - 0 downloads)
Attachments VOLeval A3 HelpPanel -2.png (275KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 1/25/2019 4:23 PM (#9257 - in reply to #9256)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
The Gurus are now functional! ... and their 5*5=25 variations (seems about right) make useful sense ... ie they logically vary the patterns in a smooth and explainable manner.

In order to make this work consistently and logically, I needed to "reverse" the slider for the required (TrdZon aka Wave) End votes ... that is, when we require 7 votes to BEGIN a Wave, we are making it harder for one to begin. This will reduce the number of bars that are in red/grn waves. So, it makes more sense to have the End vote requirement slider have a similar effect ... as it's moved to the right, it should also reduce the number of bars that are part of red/grn waves. Therefore, what used to be an End vote slider that went from 1-3 votes, the new one now goes from 3-1 votes.

To help users grasp this, and not get too focused on actual vote numbers (which are after all "internal logic"), I changed the names of those two sliders ... and when I did, I removed the "TrdZon" from the picture since I'm using "wave" now to describe the overall green / red regions. The new names are:
BgnNetRqVotFew2Mny = 1-3
EndOppRqVotMny2Few = 1-3
... this makes the left-to-right slider impact for those two to have a similar visual effect as sliding the FuzzyBand from right to left.
... THAT makes it logical and easy to understand how the new "Guru_WavesBig2Small" input relates to those three subsidiary "expert" inputs ... when the Guru slides from left to right, the Waves go from including most if not nearly all the bars, to a relatively small percentage of the bars being in waves.
... We will need to remember, when examining the spreadsheet "scores", that I've reversed the End input

The Guru for the Trading Time Frame, which has the MApds, SlopePds, and MAcalcMeth as it's subservient expert inputs also maps to them logically ... right to left on the Guru has the same "kind" of effect that moving any of them individually right to left would have. The only "tweak" I did was to move the "Mix" option from the first to the last of the list ... the new MAcalcMeth input is:
WtdHweExpHesSimMix = 1-5
... I deliberately restricted the slider to max=5 ... if someone wants the Mix, they manually type in 6. Reason for this is that none of the five slider options in the Guru_TimeFrmFst2Slo input "map" to that "Mix=6" input.
... We may need to remember, when examining the spreadsheet "scores", the old "0" method is now "6"

As mentioned a couple of posts above, when I initially laid out the theory of the Xprt and Core versions, that the Cumul-Vol method input would be Guru-less ... and that since the Sliding Window is (still) as yet uncertain as to its range, interactions and usefulness, I've kept that out of the Gurus. Also, I mentioned earlier that the Cap limit would be handled in a more hidden fashion (see above). Finally, I also mentioned earlier that I was combining the 2nd and 3rd to last "output window" controls into a single one, that offers the same degree of useful control.

The NET RESULT of all this is what I think is a very orderly, understandable input collection. The attached snaps are updated from the prior post ...




(VOLeval A3 Parameters.png)



(VOLeval A3 HelpPanel -1.png)



(VOLeval A3 HelpPanel -2.png)



Attachments
Attachments VOLeval A3 Parameters.png (186KB - 0 downloads)
Attachments VOLeval A3 HelpPanel -1.png (303KB - 0 downloads)
Attachments VOLeval A3 HelpPanel -2.png (275KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 1/26/2019 2:53 PM (#9258 - in reply to #9257)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
and noowww ... here's CVWxprt and CVWcore!

Today I built in the code to allow the Xprt and Core variants of the routine to be gen'd from the same code (therefore keeping everything consistent). Also, I got the Guru defaulting and Expert overrides in place and tested, using the "shifted" param-lists (VOLeval A2 param's that could be zero now start with one ... except the CumVol Method and SlidingWindow inputs, since they aren't controlled by a Guru).

I spent much of the day creating the "promised" bottom half of the first Help-pane, which has a lot of useful info:
1. tells you the specific values that were input (and whether they "override" the Guru-default)
2. reports the "derivative" internal-calc metrics-of-interest (MA pds, Methods, Vote thresholds, etc)

Two trios of snaps are shown below, one for CVWxprt and the other for CVWcore. Outputs are the same of course.


(CVWxprt A1 Parameters.png)



(CVWxprt A1 HelpPanel -1.png)



(CVWxprt A1 HelpPanel -2.png)



(CVWcore A1 Parameters.png)



(CVWcore A1 HelpPanel -1.png)



(CVWcore A1 HelpPanel -2.png)



Attachments
Attachments CVWxprt A1 Parameters.png (173KB - 0 downloads)
Attachments CVWxprt A1 HelpPanel -1.png (428KB - 0 downloads)
Attachments CVWxprt A1 HelpPanel -2.png (276KB - 0 downloads)
Attachments CVWcore A1 Parameters.png (120KB - 0 downloads)
Attachments CVWcore A1 HelpPanel -1.png (328KB - 0 downloads)
Attachments CVWcore A1 HelpPanel -2.png (273KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 1/28/2019 7:38 AM (#9259 - in reply to #9258)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

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

To clarify ... this is the "last chance" to comment on the Xprt/Core input arrangements I've posted previously. I don't plan on sending out another "intermediate" DLL if I can help it ... creating the DLL's is too time-consuming to do on a whim, and introducing "corrections" to a DLL's source is very awkward.

So, please look over the snaps, and give me your reactions as best you can. I'm mainly asking about "how it looks" re conceptual arrangement of things ... and also the extra detail at the bottom of the first help panel.

ALSO ... please let me know when you expect to complete the testing. Thanks!
Top of the page Bottom of the page
JimDean
Posted 1/28/2019 10:31 AM (#9261 - in reply to #9259)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
NOTE: (probably too late) ... ATVI, HAS, and PAYX all start off (usually) with a bullish green wave, even though when viewing the 126 bars I spec'd, it seems like the price action is anything BUT bullish. However, if you flip to a 9-month view, it's apparent that all of those had a fairly well established, clear uptrend prior to the arbitrary 6-month boundary.

QUESTION: did you notice this (ie the prior runup) during your testing, and interpret your results appropriately, or did you treat those lime band indications as "really bad direction" rather than "a continuation with too much lag"?

If you treated it as "really bad direction", to the best of recollection, did that mismatch heavily influence your voting for those symbols, or did the considerations of the middle and right side of the chart mainly rule the day?

Thanks
Top of the page Bottom of the page
JimDean
Posted 1/28/2019 10:56 AM (#9262 - in reply to #9261)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
I posted about this earlier ... this is the corrected version ... SIMPLER conclusions ... please review

Here is a new mapping I'm using that goes from -7 to +7 votes, to -4 to +4 return "T" values and three tricolor groups for the Wave Band.

Greenish/Pinkish tricolor Bull/Bear sets:
bright = ENTRY = enough net votes to begin a wave (can occur during the wave too)
medium = not quite enough to begin, but not enough opposite-votes (if any), to end
dark = WARNING = weak support for that direction, but not enough opposite-votes (if any), to end

Not-in-Wave tricolor sets:
dark-navy-blue = indeterminate case that doesn't seem to be leaning clearly towards bullish or bearish
blue = net votes are getting close to total required to begin a new Bull Wave (this used to be dark-green)
purple = net votes are getting close to total required to begin a new Bear Wave.

Of course, any time the Net votes are >= the Bgn threshold (and the #opp votes don't cancel it), the color is bright, and Wave begins if it's not already active.

PREVIOUSLY, I logic'd my way into finding TWO thresholds, one for weak and the other for warn ... in addition to the simple threshold for "begin". This was FLAWED, in that there are only three colors, so I can only use TWO thresholds ... and the begin thresh is one of them. SO ... the italicized comments below that develop two thresholds for warn and weak have been mushed together at the end for a single useful threshold between weak and warn ...

Coming up with "warning" thresholds is tricky since Bgn = net votes (sum of pos, neg & zero) while End = opposite voles (regardless of what other votes are). There are a variety of combinations, given that Bgn can be 5, 6, 7 and End can be 1, 2, 3 ... the table below maps it out:

Bgn=5,End=3 Bull warn upper thrsh: -2 & +5 => +3; lower thrsh: -2 & +0 => -2 ... so <= +0/1
Bgn=5,End=2 Bull warn upper thrsh: -1 & +5 => +4; lower thrsh: -1 & +0 => -1 ... so <= +1/2
Bgn=5,End=1 Bull warn upper thrsh: -0 & +4 => +4; lower thrsh: -0 & +0 => -0 ... so <= +2
Bgn=6,End=3 Bull warn upper thrsh: -2 & +5 => +3; lower thrsh: -2 & +0 => -2 ... so <= +0/1
Bgn=6,End=2 Bull warn upper thrsh: -1 & +6 => +5; lower thrsh: -1 & +0 => -1 ... so <= +2
Bgn=6,End=1 Bull warn upper thrsh: -0 & +5 => +5; lower thrsh: -0 & +0 => -0 ... so <= +2/3
Bgn=7,End=3 Bull warn upper thrsh: -2 & +5 => +3; lower thrsh: -2 & +0 => -2 ... so <= +0/1
Bgn=7,End=2 Bull warn upper thrsh: -1 & +7 => +6; lower thrsh: -1 & +0 => -1 ... so <= +2/3
Bgn=7,End=1 Bull warn upper thrsh: -0 & +6 => +6; lower thrsh: -0 & +0 => -0 ... so <= +3
... so, warnings for End input= 3,2,1 & Bgn input=5 => 0,1,2; Bgn=6 => 1,2,2; Bgn=7 => 1,3,3
... where 0,1,2,3 warn-thresholds are pos during Bull and neg during Bear waves
RESULT: for "most" waves, "warning" bar(s) will appear (unless price-reversal on mod-high volume)

The intermediate color is less important from my POV (please comment if you differ) ... it shows a weakening of the wave-strength, but not severe enough to be "questionable". So, it's somewhere between the Bgn (net) threshold input, and the Warning (net) threshold from the table above ...
Bgn=net5, End=opp3, Wrn=0 Bull weak upper thrsh: avg(5,0) = 2/3
Bgn=net5, End=opp2, Wrn=1 Bull weak upper thrsh: avg(5,1) = 3
Bgn=net5, End=opp1, Wrn=2 Bull weak upper thrsh: avg(5,2) = 3/4
Bgn=net6, End=opp3, Wrn=1 Bull weak upper thrsh: avg(6,1) = 3/4
Bgn=net6, End=opp2, Wrn=2 Bull weak upper thrsh: avg(6,2) = 4
Bgn=net6, End=opp1, Wrn=2 Bull weak upper thrsh: avg(6,2) = 4
Bgn=net7, End=opp3, Wrn=1 Bull weak upper thrsh: avg(7,1) = 4
Bgn=net7, End=opp2, Wrn=3 Bull weak upper thrsh: avg(7,3) = 5
Bgn=net7, End=opp1, Wrn=3 Bull weak upper thrsh: avg(7,3) = 5
... so, weak-Wave for End input= 3,2,1 & Bgn input=5 => 2,3,3; Bgn=6 => 3,4,4; Bgn=7 => 4,5,5
... where 2,3,4,5 weak-thresholds are pos during Bull and neg during Bear waves
RESULT: for "most" waves, some "weak" bars will appear (unless sharp price reversal with high volume)



As noted above, I can't implement these TWO thresholds for "weak" and "warn" colors ... I need to mush them together for a single threshold between those two colors (the thresh between weak and strong is the BgnVot input). Therefore, averaging the two above into an "orderly" pattern results in ...

Threshold for EndVote input= 3,2,1 & BgnVote input=5 => 1,2,2; Bgn=6 => 2,3,3; Bgn=7 => 3,4,4
... that is, if the net votes equal or better those values, it's "weak" ... if < those values, it's "warn"



I realize this may be sort of difficult to follow, but please try to ... it's hard to come up with reasonable rules for things like this, and I appreciate thoughtful feedback. This affects both the Return and Plot outputs, and could be the basis for strategy entries and exits.
Top of the page Bottom of the page
JimDean
Posted 1/28/2019 1:15 PM (#9264 - in reply to #9262)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
additional weak/warn vote threshold tweaks, after testing ...

I noticed when testing the arrangement above that the distribution of warn-weak wasn't bad, but could be improved. Also, it makes some sense to have the thresholds differ for each slider-increment, rather than being the same for two different settings (ie 2,2 or 3,3 or 4,4).

Additionally, since bearish/short runs tend to be quicker to end, and have more volatile retracements (ie dead cat bounces), I introduced a bull/bear distinction for the weak-warn thresholds so that warnings appear more readily for bearish waves ... the new thresholds are:

Bullish Waves: for EndVot=1,2,3 & BgnVot=5 => Thrsh=0,1,2; Bgn=6 =>1,2,3; Bgn=7 =>2,3,4;
Bearish Waves=more warns: BgnVot=5 =>Thrsh=-1,-2,-3; Bgn=6 =>-2,-3,-4; Bgn=7 =>-3,-4,-5
... that is, the farther from zero the threshold is, the more warnings will appear (vs being labelled as weak)


(note that all of these are within the ranges determined two posts earlier, but have additional "smarts")
(also - none of these color-threshold tweaks impact the overall duration of the green or red waves you tested)

similarly ... make thresholds for Alerts between Waves to be tougher for Bearish than Bullish
Top of the page Bottom of the page
SalimHira
Posted 1/28/2019 10:25 PM (#9265 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

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

Here are early observations coming to mind:

1. On Help-Panel #2 that relates to Formula Builder pane of any OmniScript - after we Copy / Paste the omniscript, do we need to manually change the last two parameter BarsB4Hre & ReturnType ? Or, it stays AS IS wherever we plug that omniscript.

2. should this NOT be BEAR WAVE ? Your have BULL WAVE twice.
(#9262 - in reply to #9261)
"purple = net votes are getting close to total required to begin a new Bull Wave."

3. Could you please define the following in layman's words please ? How should it be interpreted in a real trading instance ? It's used quite extensively of its importance. i.e., does it define, maybe losing momentum, ROC reversing, volume itself significantly changing, etc.... #9262 - in reply to #9261

"SO ... the italicized comments below that develop two thresholds for warn and weak have been mushed together at the end for a single useful threshold between weak and warn ... "

IMHO, we should than be able to follow the rules as it states accordingly, thereafter.

4. One minor thought - on the bright colors

" Greenish/Pinkish tricolor Bull/Bear sets:
bright = ENTRY = enough net votes to begin a wave (can occur during the wave too) "

My thoughts here is that many times, the trend has already ended before it starts (confirmation bias), what kind of color(s) or Return values should we be observing that may be the case... I do understand the Slopes and Stacks and Bars horizontal bar will provide early clues.... Just searching for additional help clues on your side to observe while trading.
'''''''''''''''''''''''
Afterall, it all does look pretty good overall extensively written coverage in how it is explained in so much detailed, I'd never have thought of learning sooo much about VOLUME & PRICE itself.

Thank You.

Top of the page Bottom of the page
JimDean
Posted 1/29/2019 6:05 AM (#9266 - in reply to #9265)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Hi Salim - thanks for your thoughtful reply

1. The top of the Help Panel instructs the user to replace the two “variables” in the function call with values, and indicates the range of those values. It says to copy the formula then paste it into the omniscript field. That seems to me to be fairly clear. What didn’t you understand?

2. Thanks. Yes. BearWave. Fixed. (A copy-paste oversight).

3. A Warning might be used for an early exit, especially if you have a way to re-enter when/if the wave resumes with a bright color, later. The exit could be partial or full. For very short term grabs, Weakness could be used the same way. Either could be used for scaling out gradually (with subsequent bright restarts used for scaling back in). I will build a System and Stop that allow the user to specify in the Params what to do when a Warning or Weakness is encountered.

4. The earliest bright color in a Wave is often right at the start of the Trend - that is, in many cases it’s a leading indicator (due to Volume component). However it’s not a crystal ball - it can’t know how long a move will last, and therefore you sometimes see a bright color just before a reversal. But it does change hues (green-Red/blue) pretty quickly compared to some other approaches. I think the answer to your Q is more related to Elliott wave theory - that is, crystal ball stuff. My recommendation is to tighten stops gradually as a trend progresses - ie as a function of time.

Hope this helps!
Top of the page Bottom of the page
JimDean
Posted 1/29/2019 6:28 AM (#9267 - in reply to #9258)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Ref the snaps in message 9258 …

A. How do you feel about help panel #1? …
1. Are the summary one-line descriptions helpful? (Later panels describe more fully in most cases).
2. Do you “like the appearance”?
3. Is the new bottom half “Actial Inputs and Derivatives” understandable? Can you make reasonable guesses as to what the derivative values on the R half of the lines are referring to?
4. Are the relationships between the Gurus and their related Expert inputs fairly clear? (No example shown with asterisk - if an expert nonzero override is used, a “*” appears between the equals sign and the value.)

B. Most importantly- now that you’ve seen the two versions, do you think two (Xprt and Core) are “needed” for effective marketing?

C. Finally - I could allow negative inputs for the two Gurus, which would “map” to the “best” combinations of the various Experts, Willy-nilly, based on your Excel results. There could be maybe 20-50 such negative manual entries possible. (Or even via slider). I could do them separately (derived from subset sorts of your SS info), so the two negative Guru categories interact somehow - not necessarily in perfect ways though - OR I could set up one of them as a Master slider which controls every input except the last two. Doing any of this would have a LOT of sbas, and those “master” patterns wouldn’t necessarily “flow” rationally (ie slow to fast etc). But I am considering doing this if y’all think it will be helpful and not confusing.
(I’m not keen on setting up a new slider since that puts us over 15,into a second panel column - nor am I excited about repeating the whole user-editable Text file thing that MTV uses. But it’s possible for a later release if folks request it).
Top of the page Bottom of the page
KenWilsdon
Posted 1/29/2019 11:27 AM (#9268 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi guys,

Here are some answers to your questions Jim. *** is prior post questions or statements.

***To clarify ... this is the "last chance" to comment on the Xprt/Core input arrangements I've posted previously. I don't plan on sending out another "intermediate" DLL if I can help it ... creating the DLL's is too time-consuming to do on a whim, and introducing "corrections" to a DLL's source is very awkward.
***So, please look over the snaps, and give me your reactions as best you can. I'm mainly asking about "how it looks" re conceptual arrangement of things ... and also the extra detail at the bottom of the first help panel.
***ALSO ... please let me know when you expect to complete the testing. Thanks!

Answer: Looks like it is well organized, and fairly clear, end of first panel looks good. It provides a quick reminder of values.

Suggestion: One suggestion related to your response to Salim's question:

***1. The top of the Help Panel instructs the user to replace the two “variables” in the function call with values, and indicates the range of those values. It says to copy the formula then paste it into the omniscript field. That seems to me to be fairly clear. What didn’t you understand?

Suggestion: In your MARKETING of this product would be to give some examples of how the return values relate to a chart with the indicator on it. e.g., show where on a chart -1 to -10 appears (maybe by circling a -2 or -8 on two charts, along with the setting to get the chart), -11 to -20, etc. Many of us are visual learners (part of being in the YouTube generation), and having something like that would bring a new user up to speed faster, as they could compare a sample chart and settings to what they see on their chart. ("I like what I see, and I know I can get this as a return value, but which one is it that I am looking at right now on the chart"? - Answer that question, and things will be a lot clearer for end users). I realize some returns are for different MA's or calcs, but they should be shown as well, or a short demo video tying charts to both inputs and return values would be helpful. This is because the sliders go from 1 to 5, but the returns go from -1 to -40. The natural question is, how do the 2 relate? And how does it relate to what I am seeing? This will be a confusing part to many potential buyers. Most are not strong programmers.

Answer: I expect to finish today.

?***NOTE: (probably too late) ... ATVI, HAS, and PAYX all start off (usually) with a bullish green wave, even though when viewing the 126 bars I spec'd, it seems like the price action is anything BUT bullish. However, if you flip to a 9-month view, it's apparent that all of those had a fairly well established, clear uptrend prior to the arbitrary 6-month boundary.

***QUESTION: did you notice this (ie the prior runup) during your testing, and interpret your results appropriately, or did you treat those lime band indications as "really bad direction" rather than "a continuation with too much lag"?
?
Answer: Answered above?.
?
***If you treated it as "really bad direction", to the best of recollection, did that mismatch heavily influence your voting for those symbols, or did the considerations of the middle and right side of the chart mainly rule the day? ?

Answer: HAS was a problem? one way, as it looks like it had an earnings announcement where the gappy spike occurs at the beginning of the 6 month period. In the early days of the testing, this did influence me in regard to direction, but I normally needed at least 2 trades to go in the wrong direction for direction to be voted very bad( that being one of them). My reasoning is that the system should compensate for unusual market volume relatively quickly. As I moved along in testing, this became less of a consideration. It did affect lag as well.? As I was getting familiar with the process of scoring, I realized that it should go more toward lag than direction, and weighted it more heavily that way.

Answer: As for PAYX, I treated it as more lag than direction, unless it was getting out at the bottom of the down wave at the -6 month point (about July 28-30), then I penalized it for direction as well.

***Ref the snaps in message 9258 …
A. How do you feel about help panel #1? …

Answer: It looks pretty good to my eyes.

***1. Are the summary one-line descriptions helpful? (Later panels describe more fully in most cases).

Answer: Yes they are helpful. Again a demo video giving what the one liners mean would be helpful.

***2. Do you “like the appearance”?

Answer: Yes

***3. Is the new bottom half “Actial Inputs and Derivatives” understandable? Can you make reasonable guesses as to what the derivative values on the R half of the lines are referring to?

Answer: These would be guesses only. I would not be certain of the return values, and would probably have to do quite a bit of testing to figure them out. See my comments above.

***4. Are the relationships between the Gurus and their related Expert inputs fairly clear? (No example shown with asterisk - if an expert nonzero override is used, a “*” appears between the equals sign and the value.)

Answer: I think they are pretty clear.

***B. Most importantly- now that you’ve seen the two versions, do you think two (Xprt and Core) are “needed” for effective marketing?

Answer: Yes. The Core version is all that many will want to tackle with 6 sliders.

***C. Finally - I could allow negative inputs for the two Gurus, which would “map” to the “best” combinations of the various Experts, Willy-nilly, based on your Excel results. There could be maybe 20-50 such negative manual entries possible. (Or even via slider). I could do them separately (derived from subset sorts of your SS info), so the two negative Guru categories interact somehow - not necessarily in perfect ways though - OR I could set up one of them as a Master slider which controls every input except the last two. Doing any of this would have a LOT of sbas, and those “master” patterns wouldn’t necessarily “flow” rationally (ie slow to fast etc). But I am considering doing this if y’all think it will be helpful and not confusing.
(I’m not keen on setting up a new slider since that puts us over 15,into a second panel column - nor am I excited about repeating the whole user-editable Text file thing that MTV uses. But it’s possible for a later release if folks request it).

Answer: I personally don't think that is needed.
Top of the page Bottom of the page
JimDean
Posted 1/29/2019 11:43 AM (#9269 - in reply to #9268)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

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

Re the return values - see earlier post #9199 posted on 1/4. Of course it’s noy totally up to date but I hope that the help panels about returns (albeit dense) and the big sidewise table snapshot help clarify things.

Returns for slider input -1 to -40 are very “orderly” once you understand the pattern - each “-x1” value is a meld of several (up to 7) piece of info, and the nine cases after that in sequence provide individual detail of each item. Help panel #2 is a concise summary.

Not all return items have corresponding plot colors. Many are durations (ie counts) of a given color. But nearly all of the capital-letter returns have color related plots, where 1=very red/bear and 9=very bull/green.

The new help panels will explain and will be more extensive. Problem with providing detail info in videos is that it can’t be quickly ref’d later. But it does make sense to do a video walkthrough to familiarize users.

Thanks again.
Top of the page Bottom of the page
SalimHira
Posted 1/29/2019 4:25 PM (#9270 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
In response to post #9267 questions, I concur with Ken's comments while not to repeat myself either, and Jim's clarifications clears any doubts, with high emphasis on "C" - it is not needed, imho. Thanks.

p.s. I am trying to complete the SS by tomorrow late evening, if all goes well with my schedule - but trying sooner.
Top of the page Bottom of the page
JimDean
Posted 1/29/2019 4:56 PM (#9271 - in reply to #9258)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Thanks to both of you.

I’m a bit confused about Kens response re the bottom half of Help pane 1 with the input values and the derivative info. Specific questions:

1. Is it clear that the first value in each of the first eight lines is the input value (if a guru or an asterisk), or if no asterisk, it’s the expert-input’s Guru-assigned value?

2. Is it clear that the other values on the line after that are:
A. Not answers but rather internal derivatives of the inputs
B. For which of those labeled values can you understand the labels. Which not?
C. Do you think it’s helpful to users for me to provide that info?

====

New question:
Since the Core version does not provide “fine” control over the six subsidiary expert inputs that the Gurus define, I’m thinking that it does not make a lot of sense to provide as-extensive output detail for that version (since user can’t really “tweak” things in detail). So, I’m thinking about limiting the Core Plot output to just the simplest “Wave Band plus three strips” option, plus the “explanatory-but-not-very-useful” plot #3 that has the various raw components all stacked on top of one another (Cumvol, vol, colored ma’s, colored dots, etc). Also, the Core Return would be limited to the first T.tPpKkB output and its breakout options, plus the CumVal.
Of course the Core DLL is less expensive - not sure if the subscription would be or not.
What do you think?
Top of the page Bottom of the page
KenWilsdon
Posted 1/29/2019 10:05 PM (#9272 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Jim,

I’m a bit confused about Kens response re the bottom half of Help pane 1 with the input values and the derivative info. Specific questions:

1. Is it clear that the first value in each of the first eight lines is the input value (if a guru or an asterisk), or if no asterisk, it’s the expert-input’s Guru-assigned value?

- - - I assume you are referring to the CVWxprt Help panel, specifically those in the Trading Timeframe Inputs and the Voting Sensitivity Inputs. I assume the Guru sets the values of each of the next 3 lines to the value after the = and before the ";"

2. Is it clear that the other values on the line after that are:
A. Not answers but rather internal derivatives of the inputs

-------Not totally clear what an internal derivative of inputs means. I understand derivatives from calculus, but you are using it in a different sense. I assume you mean what is after the ";" in each line. That is clearly the description of what the slider does.

--------Does the Guru number in first line in section set the value to what follows = and before the ";" for each of the next 3 lines? That is what I assume is the case. I hope that is clear.

B. For which of those labeled values can you understand the labels. Which not?

--------I dont understand WtdHweExpHesSimMix; Wtd is obviously weighted, but the rest is cryptic. bEMA is also one that I am not familiar with. The rest of the first 8 lines I can figure out.

C. Do you think it’s helpful to users for me to provide that info?

--------Yes, it helps them to understand what the control on the slider does.


What you suggest for the Core version seems reasonable for the stripped down version.
Top of the page Bottom of the page
SalimHira
Posted 1/30/2019 9:46 AM (#9275 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
I will attempt to summarize to your questions. I pretty much understand but some concerns too - but herewith, is what may need clarifications in addition:

What are WavesBig2Small ? ... folks may need to reflect upon that.

How the CumSlidWndWyd2Thn affects the slider, and if not satisfied, user can override by manually typing them ?

Pls expand on WtdHweExpHeSimMix - lost here and/or anyone who see it, cannot make out what may be happening here.

============
1. Is it clear that the first value in each of the first eight lines is the input value (if a guru or an asterisk), or if no asterisk, it’s the expert-input’s Guru-assigned value?

>>> I recall how it was used in MTVxprt, so assuming its the same.

2. Is it clear that the other values on the line after that are:

A. Not answers but rather internal derivatives of the inputs

>> It is not clear, imho.

B. For which of those labeled values can you understand the labels. Which not?

>>> see above

C. Do you think it’s helpful to users for me to provide that info?

>>> Definitely. With only the DLL on hand, its difficult to comprehend as we all are used to going into the OmniLanguage itself of source code to read the "definitions" when things become blurry for recollection.
Top of the page Bottom of the page
JimDean
Posted 1/30/2019 9:47 AM (#9274 - in reply to #9272)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
I've modified Help Panel #1 as shown in the snap to clarify the meaning of WtdHweExpHesSimMix ... please let me know if this clear enough ... ie that it refers to the calc method used for the MA's as being Wma, Ema, Sma, or a mix of those (within the confines of one line of text, that is ;~).
Also ... Help Panel #2 now more clearly describes how to get the single-digit "T" value output. And I've modified the Core version of HP#2 to only show the -1 (thru -10), -11 and -12 options.

I've also implemented a Core vs Xprt distinction re what outputs are provided with each:
Plot: Core does not offer the Plot with the Slope Histo, dual-barV strips, and Stack Histo (now= Xprt option #3)
Return: Core does not offer return-options 11-38, and 39-40 are mapped to 11 & 12 for core. That is, the "net result" return "Wave T.tPpKkB" and its nine breakout-digits-options is provided for Core, but not the detailed "Slope P.QqRrSs" or "Stack K.LlMmNn" or "BarUH B.bUuHh" information.
... I'll likely provide a lower price for the Return subscription for Core, as well as for its DLL

I'm going to provide licenses to BOTH Xprt and Core for people who buy Xprt, so they can use either (both give same answers).

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

KEN: the SS you sent me last night does not contain the final 140 cases ... just the first 400.

BOTH (esp Ken, since he missed the prior Skype): I'd like to do a Skype-training-demo today for you ... what EST times do you have available? (sooner better than later)

(CVWxprt A1 HelpPanel -1.png)



(CVWxprt A1 HelpPanel -2.png)



Attachments
Attachments CVWxprt A1 HelpPanel -1.png (427KB - 0 downloads)
Attachments CVWxprt A1 HelpPanel -2.png (273KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 1/30/2019 10:26 AM (#9276 - in reply to #9275)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

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

I posted some answers and a couple of updated snaps about the same time you posted your reply, so you may not have noticed them ... if not, please review my prior post.

I'm discouraged to hear that the bottom half of HP#1 is apparently pretty much a mystery. I'd have thought that the labels which match the listing in the upper half would have clearly ID'd those rows as being related to the various Parameter inputs ... and an equals sign followed by a value would have been fairly obvious as representing the value input by the user. HOWEVER, with the hope of improving it, I am going to REVERSE the meaning of the asterisk ... that is, values will have an asterisk if the Guru set them (ie they were input as zero but "used" as the noted value). I hope that will help. See snapshot below for those revisions.

I'm also surprised that an abbreviation like:
MA pds: Fst= 3, Med= 6, Slo= 12
... is so hard to understand. The user can SEE the MA curves on the output plot ... and the Fast/Med/Slow "idea" is basic to the program ... so why is that abbreviation too obscure? Please keep in mind that the panel has max-height (ie #row) limitations.
... and the other "detail-y" info on following lines seems to be even less cryptic (maybe "bEma" looks odd, but I think they "get it" that it is "sort of" an Ema ... later Help describes bEma)

Regarding your comment about wanting info that you otherwise might have gotten out of viewing OLang:
a. this routine is too complex to report the intermediate values for *everything* that is going on
b. much of the "coding mechanism" is proprietary so I don't want to make it easy to duplicate
c. the other Help Panels (presented previously in thread) describe the calc methods qualitatively ... a LOT MORE than Nirvana typically explains their plugins.


Re WavesBig2Small ... would you prefer "WavesWide2Thin" ? I'm suprised that the idea of a "Big Wave" vs a "Small Wave" is hard to follow ... unless you don't get what a "wave" is. The "wave" is a series of bars that are all the same family of bullish (green) or bearish (red) hues. Again, there is a limit of how many lines I can include on this screen ... what would you suggest?

Re CumSlidWndWyd2Thn ... the final part of the definition line says "or typed" ... which means the user can type in the number of periods they want. I don't really want to encourage people to do that so I don't want to make a big deal out of it ... I considered not even mentioning it except in a video. Is it also unclear to you that the user has an option of manually typing int FFMMSS for the second input? I debated whether to make that obvious, too.

Re WtdHweExpHesSimMix ... I tried to clarify that in my prior post which you probably didn't see before responding ... is the new one-liner adequate?

(CVWxprt A1 HelpPanel -1.png)



Attachments
Attachments CVWxprt A1 HelpPanel -1.png (432KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 1/30/2019 11:05 AM (#9277 - in reply to #9276)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
OK ... I've modified the HP#1 to define the Guru meanings ... hopefully the explanations of "Fast" for the first one and "Big" for the second will do the trick.
I also added a subtitle line for the headers of the guru sections on the top half (Xprt only), to help clarify how the Guru "drives" the Experts when they are zero.


(CVWxprt A1 HelpPanel -1.png)



(CVWxprt A1 HelpPanel -2.png)



(CVWcore A1 HelpPanel -1.png)



(CVWcore A1 HelpPanel -2.png)



Attachments
Attachments CVWxprt A1 HelpPanel -1.png (461KB - 0 downloads)
Attachments CVWxprt A1 HelpPanel -2.png (273KB - 0 downloads)
Attachments CVWcore A1 HelpPanel -1.png (331KB - 0 downloads)
Attachments CVWcore A1 HelpPanel -2.png (215KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 1/31/2019 6:51 AM (#9278 - in reply to #9276)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
A few small changes worth noting:

1. I modified the param names for the gurus to use caps: GURU_TymFrmFst2Slo and GURU_WavAgrs2Cnsrv ... required removing "e" from "Wave' and changing "Time" to "Tym" so that it still fit on the param pane and in the message boxes. Reason: later, there *might* be a need for another slider for Master Presets ... if so, I might need to remove the intermediate "Voting Sensitivity" label-line to make room for the new one on top. In that case, the all-caps "GURU" will help visually divide the two sections.

2. I modified the -7 return value to be "B.b" instead of just "B" ... thus including the duration-bars with that output, since the Core version does not offer other alternative outputs to obtain the "b". In line with that, I also modified the 2-digit return values to T.t, P.p, K.k (in both Core and Xprt), and the Q.q, R.r, S.s, L.l, M.m, N.n, U.u & H.h for the other 2-digit return options avail in Xprt. The decimal makes it simpler for the user to parse the two pieces using the functions INT() and FRAC().

3. Minor mods to output format for HelpPanel #2 to reflect the decimal changes above, AND to clarify what the second-to-last option is ... now says "BarVol (neg=cap)" rather than "Capped RawVol".

4. Also ... I fixed the plotting so that when the Sliding Window is off, there are no cyan/pink histo's below the zero line to show what was removed from the left side of a nonexistent window. Along the way, I also tweaked the dot-plotting for that plot so the dots don't get quite so huge (in some y-axis situations), and also are a bit tighter together ... but still readable.


(CVWxprt A1 Parameters.png)



(CVWxprt A1 HelpPanel -1.png)



(CVWxprt A1 HelpPanel -2.png)



(CVW A1 Detail Plot (noSWndo).png)



Attachments
Attachments CVWxprt A1 Parameters.png (173KB - 0 downloads)
Attachments CVWxprt A1 HelpPanel -1.png (460KB - 0 downloads)
Attachments CVWxprt A1 HelpPanel -2.png (275KB - 0 downloads)
Attachments CVW A1 Detail Plot (noSWndo).png (47KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 1/31/2019 11:22 AM (#9279 - in reply to #9278)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
FOUR QUESTIONS for y'all:

1. I'm undecided about my earlier idea regarding leaving out one of the plot options for Core. It's so useful for diagnosing "whys" that I think maybe I should leave it in. I'm talking about the one that is option #2 in your A2 DLL's ... with the Wave band on top, then Slope histo+curves, then dual strips for BarV, then Stack histo+curves. (no matter what, I will limit the Core Return values to just the T.tPpKkB overall set)
Is that plot "high-value and fairly essential" to making the Core version understandable?

... I'm thinking of ways to use the test results to best effect ...

2. I can use the Step6 & Step8 results in combo, to determine what the "most commonly viable" patterns are for each of the two Gurus. That is, the GURU_TymFrm would allow *negative* values, which would assign its three experts based on which have provided the "best" results in the testing (independent of the other Experts). Similarly, I can do the same for the GURU_Wave input, where its negative inputs would assign patterns of its three Experts based on their independent results. The sequence from -1 to whatever (-5 or -10 maybe) would not be Fst2Slo or Agrs2Cons, but rather Best2Good "scoring".
What do you think?

3. I can use the Step8 results to create a new "PreferredPatterns" slider that would be at the very top. It would assign values for *every one* of the 8 experts, based on tier-sorting within the "Fours" results ... (WavAgrs2Cnsrv looping within TymFrmFst2Slo looping) ... all suggestions would (likely) be "four" scores ... using overlap of Ken and Salim results ... probably about 50 options. This would *not* require me to create a Preset Text file ... it would all be internal mapping. If I do this, then the existing Guru's and Experts could override those PP's if they are nonzero (will adjust input ranges for CumMeth and SlidWndo to accomodate). The PP slider would be in Core & Xprt.
What do you think about this?

... of course there's no way to be sure whether the PP's or the neg-Guru options will actually work out to be amongst the "best" for a given user's situation. I'm fairly confident that our methodology, re separate eyeballs, three scoring cat's, and carefully chosen spectrum of symbols will yield generally useful results.

4. This one needs some explanation ...
... the *really handy* think about the PP and the neg-Guru options is when someone wants to pair up CVW with other stuff in a strat, and use StratWiz to find good fits. SW can simply loop thru the ~50 likely-fairly-good PP options, rather than having to do a bunch of not-very-likely-to-be-useful permutations that would be needed if SW was asked to loop thru all the experts in a tiered fashion.
... in fact ... once the 50 are chosen for PP, I might set up a SW run that uses CVW for entries and exits, and loops thru the 50 to determine which are the most profitable for a big list of stocks ... then provide PP a negative range, where the SAME 50 are mapped, but in a different "SW profitability" order (rather than the pos-50 sort described above).
Creating these variants on the Gurus and creating the PP is not terribly difficult ... much easier than (and faster-executiing) than any "preset text file" type of approach.
What do you think about the SW-profitability-sorted neg-PP-input option?
Top of the page Bottom of the page
KenWilsdon
Posted 1/31/2019 3:12 PM (#9280 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi Jim,

RE:

Q1.

>>> My thinking is that it is not fairly essential. Core users will probably people who don't care so much about the nuts and bolts, but just want something that works. it will be more likely that Xpert users will want to know the whys. It also provides another plot as a reason to upgrade.

Q2.

>>> That would be a good option for a new user to get started, as well as a good starting place for core users to get experience with CVW.

Q3.

>>> So question 3 is different than Q2. A master slider. Good idea. That allows the Q2 answer to give more granularity than the Q3 option, if a user wants that, without going through all the permutations. If people like to tinker in a broad sense, this would certainly help them.

Q4.

>>> I think that is a good idea. If the markets change over time, then a new SW sort could be done later, and they still would allow their use, even if the order changes somewhat.
Top of the page Bottom of the page
JimDean
Posted 1/31/2019 3:24 PM (#9281 - in reply to #9280)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Re Q4 (and 3 and 2) - clarification

All of these slider-controlled preset patterns would be hard coded, not driven from a text file, or in any other way modifiable by the user. I’m thinking of killing off the Preset file entirely from MTV and doing a similar hardcoded approach (I’ve sent an email to all MTV owners requesting N/Y as to whether they’ve created any custom presets). Hardcoded means no slowdown to read a file. And a lot less code to implement. I’m thinking ahead about paradigms that I might implement in all the other stradicators.
Top of the page Bottom of the page
JimDean
Posted 2/1/2019 3:48 PM (#9287 - in reply to #9278)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
More changes ... to introduce the "PreferredPatternsMaster" input ... (reposted due to prior errors)

To do this, I had to eliminate one of the gray param-pane "headers", but with GURU capitalized I'm hoping the two separate GURU sections remain clear.

The new PPM input does function, but its predefined set of 50 input patterns is set to gobbledegook for now ... once I get the rest of the Step 8 scores back from the two of you, then I'll be able to analyze them and establish the "50 best" (or some other number).

If the PPM is nonzero, then all the other Guru and Expert inputs can be zero ... and must be, if the entire pattern is to be utilized. I revised the input sliders for the two Gurus and the Cum Method and Wndo Experts to reserve zero for this purpose (shifted the two Expert input-meanings by +1). Help panels have been fixed for this stuff, as well.

The internal logic is really, REALLY versatile. If you set a nonzero PPM, then you can choose to set any of the Gurus &/or Experts to nonzero values ... it will use the PPM pattern for any that remain zero. Of course, if a Guru is nonzero in that situation, then it overrides the defaults for any of its subsidiary Experts (that themselves are zero).

It really does make "obvious" sense once you get it ... but to clarify, I enhanced the bottom half of Help Pane #1 to allow the "default-flag" to be "^" if PPM sets the value ... or be "*" if a Guru sets the value ... or nothing if the Expert itself was nonzero.

Please carefully study the input-combo and let me know if this is clear, from the snaps below.

... Later on, I might also allow PPM to be negative, which would utilize input-patterns that Strategy Wizard determines to be typically profitable ... but I need to wait till I get the NXF-shell routines in place for that (see my RTF file posted here)

... Also, maaaybe (need to see testing), I might allow the Guru's to be negative, to utilize "optimal" combo's of their three related Experts ... this could be pretty handy but it would require one more set of a few hundred Tests (an extension to the results of Step 8). I'll wait to eval Step 8 before I present that to y'all ... if you have the stomach for it. ;~)


(CVWxprt A1 Parameters.png)



(CVWxprt A1 HelpPanel -1.png)



(CVWxprt A1 HelpPanel -2.png)



Attachments
Attachments CVWxprt A1 Parameters.png (177KB - 0 downloads)
Attachments CVWxprt A1 HelpPanel -1.png (476KB - 0 downloads)
Attachments CVWxprt A1 HelpPanel -2.png (275KB - 0 downloads)
Top of the page Bottom of the page
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
KenWilsdon
Posted 3/15/2019 3:45 PM (#9400 - in reply to #9399)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Some general comments, after comparing Post 9344 (last screen shot of parameters) with Post 9397.

1. Moving the CumWndoPdsWyd2Thn to under the Guru_TymFrmFst2Slo makes sense.
2. Moning the CumObvVptMixAcdNnn to under the CumCalcMasterOutput also makes sense.
3. The name MasterSetsFltrTrdNtrXit makes more sense for what it is supposed to do.

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

"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
...
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.

Please study the prior post before reading this, and consider the question to be "a, b or c"

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

I have stated before that I am willing to run SW runs on a remote computer I have access to 24/7, and it is already loaded with OT2018. This could be started almost as soon as the dll and SW is set up properly. I can give you access to that so things would be set up exactly as you desire. You could run an incremental or exhaustive run, whichever you prefer. So b. is an option.

I think a. would be an option only if you want it "out the door" immediately. I prefer b or c.

c also makes sense. While many parameters and functionality have changed since the testing, they were changed BECAUSE of the testing (for the most part). The intuitive logic is better now after our first test than it would have been without that testing.

Having 9 filter patterns, 9 trade patterns, 9 entry patterns, 9 exit patterns does make sense, but your cautionary note:

"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."

is a concern. This stradicator could be adjusted and tweeked "until the cows come home", but its functionality is already obvious. I think the worst form of the 80/20 rule would come into play: Spend 80% of future time on (at most) a 20% improvement (I doubt it would be anywhere near 20%).

Therefore, my preferred options would be b,c,a in that order. While the SW is running, you could focus on some other tasks you need to get done.

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

Concerning your suggestion in Post 9399,

"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 ... "

My own feeling on this is that while the CumVolMeth does change the results somewhat, the other factors like begin and end and # of bars for reversal and slope and MA periods are far more important and changes the results to a greater degree. Ideally, the 36 or 64 variants would pick the best of the 4 CumVolMeth for that particular variant, and in the Xprt version, the user could fine tune with the CumVolMeth slider.

I agree that the classic variants should be used.

These are my opinions.
Top of the page Bottom of the page
JimDean
Posted 3/15/2019 4:07 PM (#9401 - in reply to #9400)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Thanks for offer re SW

My concern is not machine time. It’s setting up the tests, then evaluating the results that will take significant time. It requires NFX modules first. Roughly a week of work not counting SW runs.

If you’d like, please propose in detail how you think the tests should be structured, to identify the best settings for each of the four categories. The specs should include how the strategies should be structured, what constraints on the looping, what performance Params should be in focus, and how the tens of thousands of runs should be culled in Excel.

Need specs for each of the four cat’s: Filter, Trades, Entries, Exits.

Heads up - this is not easy to do ;-)
Top of the page Bottom of the page
SalimHira
Posted 3/15/2019 4:35 PM (#9402 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

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

Glad to see you back after a short hiatus. Well and strong :-).

At first, I was leaning primarily to option (a) - simply roll it out, tweak, q/a, enhancements, etc... at later date after bringing in more feedback from actual purchased users of the DLL, who may also want other options, tweaks, etc. added... You may have to revisit an enhancement version at later date anyways, imho.

Than, skipping (b) as lots of tests and interpretations, I prefered option (c), I liked that a lot, but again, this statement caught me to say - STOP !!

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

I like option (c) for simple reason that "no entry is similar to an exit that must be taken just for the sake of taking an exit just cause an entry is made to counter" - as its all based on a "PRIME" price location whereupon Entries & Exit happen.... analogy to real estate / property location - good location (higher price, higher reward) v.s. depressed location (lower price, lower reward). In retrospect, if I am only trading Longs (or only Shorts), than an entry location is very important for me, unlike taking arbitrary entries every time all conditions are satisfactory an entry is taken.

I think you have already conveyed well in your post as I am explaining it in a generic manner via another angle option (c).

So, its still option (a), and option (c) if without delay, if it is not likely to add more hours, delays, beta testing, etc. and you feel its a viable solution first time around to add to DLL. (keep it for next enhancement with addt'l feedback from users, plus incorporate option b in it too with possibly more beta testers on hand), imho.

Therefore, my preference would be a, with hesitancy on c & b.

Hope it helps. Thanks.

p.s. Oops - I just read Ken's post after writing above - hehe, we have in reverse order, and more chaos for Jim.
Top of the page Bottom of the page
KenWilsdon
Posted 3/15/2019 5:22 PM (#9403 - in reply to #9402)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi Salim,

Yes, you may be right. Upon further reflection, and reading Jim's reply to my post, options b or c both sound like it will take a month or more. Neither one would save time, or extra work for Jim. Both will require extensive testing. Since Core is designed for a "high level" view, it can function in the short term as a poor man's Master Set. Looking at option c again, Jim points out that it would be just his opinion, probably by the SBAS squinting option over lots of charts. This will add a layer of subjectivity to a basically objective stradicator.

Thinking of the N users, they would probably have more confidence in a SW run that sets the Master Set, rather than a SBAS Master Set, even though those "squinty eyes" have a lot of experience and a calculating brain behind them.

So, as you point out, users will have suggested enhancements and tweaks. If there is some time before the enhancements with option a (very likely), the upgrade would be a much better product with a Master Set. Option b still requires some SBAS time as well to choose the best variants.

So I guess I am saying that I think option a may be best, as the stradicator is very useful as is. So I am switching to a, b, c as my order. If the SW tests can be set up properly after option a is out the door, that could be the basis of a future upgrade.

Jim, Perhaps they could initially be based on the Core settings to find the best options for Filter, Trades, Entries, Exits, and then based on those initial best settings, refine with the Xprt variants to arrive at a usable Master Set. Those settings that produce the greatest common gain upon the most number of stocks (similar to what the Global Optimization setting is supposed to do in OT, except in greater quantity of variants over bull, bear, and flat markets). Those are my initial thoughts.
Top of the page Bottom of the page
JimDean
Posted 3/15/2019 5:37 PM (#9404 - in reply to #9403)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

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

First - option C only takes about 20 min for me to do. It’s not Sbas, but rather just logical thinking. The idea is to give the newbie a starting point, not a recommended solution. The Help and vid training would emphasize this. Maybe an hour or two of fiddling with charts, as well, to assure that my intuition is not wholly off base.

Imho it’s mechanically better to include the Master input in the initial release even if it’s not very sexy. That way, if/when an in-depth SW based set of results are avail, it’s easy to enhance the existing input without forcing all users to modify existing function calls, focus lists, etc. Option A would not be friendly later on.

Re Kens comments on SW. it’s much more complex than one paragraph. Maybe 30 paragraphs would provide a decent outline but the equiv of 100 paragraphs would really be needed. I’ve done things like this before. It’s not easy. And I can’t afford the time now.

So, C it shall be. But hopefully y’all can offer some constructive comments re what the intuitive options should be for the C-Master settings. Or maybe how many is too many and how few is too few. Ken suggested that including four (of ten) method variants was too many. If so, what smaller subset, specifically, would you suggest.

Specifics are what I need, to whatever degree you have an opinion.

Thanks.
Top of the page Bottom of the page
JimDean
Posted 3/16/2019 8:41 AM (#9405 - in reply to #9404)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Along the lines of option C ... that is, keeping the Master slider, and coming up with a rational subset of the three pattern sliders that are avail in the Core (and Xprt) versions, here is what I'd think would be a reasonably fast path, which would leverage the huge amount of work already done on the SBAS spreadsheets ...

Target:
Determine the best subset of patterns for four application-categories: Filters, Entries, Exits & Trades ("FEET"). Ideally it would be an equal # of each, and a fairly short list. There could be some overlap - ie the same pattern might be useful as a Filter and also as an Entry, etc.

First ... this should be focused solely on the sliders that would NOT be subject to further tweaking as a result of the tests. That is, leave the Expert sliders as is, and vary only the Gurus (plus a subset of the twelve CumV calc method options). By going this route, there will be no temptation to tweak the inner workings any further ... that is, my response time to the testing will be fast and final.

Second ... this should have fewer columns than the prior "step six" tests, and should not have a "step 8" followup. That will keep testing time low, and prevent exhaustion-related testing "cross-eyed" impacts. I think that 125 columns (compared to the ~500 used before) will do it.

Re the Method choices:
The two Gurus each have 5 positions (which vary their two sets of four subsidiary Experts). The CumV Method has 12 positions (-6 to +6) ... half of which are avail in Core. +6 is raw volume so it can be ignored. +1 to +5 are the four classic methods plus a "pure average" of the four. Since the chart changes to a lesser *but significant* degree as the slider moves through those five, compared to +1 to +5 changes for either of the Gurus (more or less, for different Symbols), the CumV Method input is sort of a "medium vernier", in between the Gurus and their subsidiary Experts. The way that the CumV method slider impacts the charts, afaict from cursory review, is hard to pin down in a "general" way. Therefore, it's hard to intuit which choices are best for Filters vs Trades vs Entries vs Exits. That's why I think it's important to "study" it a bit further, via SBAS.

Re the Symbols:
I think that three per person is still a good choice, to represent a spectrum and also to help minimize weariness. Probably it would be a good idea to use different symbols than have been SBAS'd before.

Re the Scores:
This is the thing that I'm not as certain of. Presuming y'all are willing to do this final limited SBAS round, I'd like your comments about them.

Option A: Use the original Lag/Chop/Dir categories
Advantages ... fully "understood" and familiar; only 3 questions so existing SS's don't need mod's
Disadvantage ... they don't "directly" address the four target categories - interpretation is req'd.

Option B: Use four specific Filter Entry Exit Trades categories
Advantages ... easy to sort thru results to conclude which to use for the Master slider
Disadvantage ... I'd need to spend 2-4 hours to modify the SS's to accommodate four scores

Option C: Use three Filter Entry Exit categories (like the prior BgnEnd tests)
Advantages ... minimal interpretation needed ... use combo of Entry+Exit scores to define Trades
Disadvantage ... possible that the "combo" interp might yield some oddball conclusions

Both B & C would utilize arbitrary zigzag plots (similar to the BgnEnd tests) to help normalize the SBAS perspectives. This is probably a good thing, since part of the difficulty that I encountered in consolidation of the results before came from what *seemed* to be very different "interpretations" of the Filter Entry Exit BgnEnd tests that I got back from S+K ... in a lot of cases, the conclusions seemed nearly opposite from S vs K, thus calling a lot of the test into question. I'll resurrect the definitions of the Filter Entry Exit scoring guidelines, and provide three (instead of just two) zigzag lines, to help avoid this.

What do you think? Are you willing to help out with this final SBAS set? Which of A,B,C do you prefer?
Top of the page Bottom of the page
KenWilsdon
Posted 3/16/2019 9:53 AM (#9406 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi Jim,

I favor option B over A or C. While it would take a few extra hours to set up SS, once the SS and results are completed, it would be done, and interpretation is minimal. Option C uses 3 of the 4 areas of B anyways, so why not just add a fourth and get one more detail that eliminates most oddball conclusions. Option A requires further interpretation than should be necessary at this stage.

I would be willing to help in one more go for 125 columns on 3 stocks, as you suggest.
Top of the page Bottom of the page
SalimHira
Posted 3/16/2019 10:17 AM (#9407 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
Good Morn' Jim and Ken:

I concur with Ken, option "b" and willing to do the beta tests. Happy weekend.

Top of the page Bottom of the page
JimDean
Posted 3/16/2019 11:30 AM (#9409 - in reply to #9407)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Thanks, guys!

Here are some new symbols (from my orig 30-syms culled from Nas-100) to work with, that reflect a spectrum of price behaviors during the past 6 months ...

WBA ... udfd
CTAS ... dfduf
MAR ... udfdfud later replaced with SPY due to bigjump issue
PCAR ... udufdud
NCLH ... ududuf
ADP ... udfduf
ALXN ... udfdu
LILAK ... ufdufdufuf

Each of you, please pick FOUR from the list that you feel represent a good spectrum of price action (ie mixes of "identifiable" up, dn, flat).

First come, first serve.

Then I'll review each set of four and cull one out ... unless you're willing to do four apiece (since I have to change the SS anyways - let me know).

suggestion: if you prefer to actually trade "extended" holds, or if you prefer "briefer" holds, then pick symbols that reflect that ... ie briefer => smaller-atr zigzags, extended => bigger-atr zigzags
Top of the page Bottom of the page
JimDean
Posted 3/16/2019 1:56 PM (#9418 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
There are no lines or dots on the band as previously discussed ... that has moved to TradeTrak per prior posted decision.

Here is a recap of the colors which might appear on the "Band" ... they are explained in detail in the following post.

1. bright color lime/pink can initiate a new wave ... for that, bright must pass input netBgnVot thresh
... (new wave only starts after input-required delay-bars since last wave end ... see next post)

2. once wave begun, subsequent brights mean net vote has increased since prior bar's net vote
3. once wave begun, medium grns/reds mean net vote has decreased since prior bar's net vote

4. during a wave, dark grn/red "Warn" means >=half of input oppEndVot thresh has been hit
5. during a wave, dark grn/red "Warn" can be created from the new med-cnt rules (or special sum rule)

6. wave end due to hitting input EndVot thresh, or due to bright bar in opp dir'n, has navyblue bar
7. wave end due to warn-count or 3-blue-strips rules, has black bar

8. between waves, medblue/purple bars show Alerts if NetVot >= half of BgnVot threshold
9. between waves during delay period, lime/pink bars converted to lightblue/violet Alert bars
... otherwise, between-waves is navy blue.
Top of the page Bottom of the page
KenWilsdon
Posted 3/18/2019 1:05 PM (#9424 - in reply to #9423)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
"Is A3 important? Do you understand the logic? Should be tweaked?"

I think A3 is important, as from the other 2 tests Salim and I have done, there were many times that exits were well past the pivot point of the wave, and sometimes even making a winning trade to be break even, or even a loss. Having the ability to logically leave a stock whose volume pattern is "flatlining" on the indicator, while the stock itself is meandering slowly against the trade, is a valuable ability to control. While A1 and A2 do this too, being able to have some control over such a situation is very worthwhile. I understand the logic, and think it is a useful addition to A1 and A2. I do not see anything here that needs to be tweaked.

========

Is B3 important? Do you understand the logic? Should be tweaked? (specifics please)

Going through B3 b you have this sentence. "An extreme-conservative approach uses a threshold of 2, ie a warning after two mediums ... an aggressive approach uses a threshold of 5, ie a full exit after 5 mediums (without any intermediate bright bars). "
This is a little confusing in the logic because of how it is worded. You state for a conservative approach it is a warning after 2, while for an aggressive approach it is an exit after 5. The B section seems to be dealing with warnings more than exits. While I understand that a series of warnings can lead to an exit, and this seems to be what this sentence is indicating, maybe something like
oops ... my copy/paste error ... should say "a warning after 5" ... fixed

"and an aggressive approach after hitting a threshold of 5, it is no longer a warning but a full exit after 5 mediums (without any intermediate bright bars).",
or some such verbiage, would make it a bit clearer. The logic I think I understand, it's just the use of exits here instead of defining an exit using the term warnings causes a full stop in thinking.

"c. The medium-bar count *resets to half its threshold value* after any dark-color warning bar (gen'd by any B1-3 method) is encountered. That is, since the dark-color bar is "very weak", fewer ongoing medium-bars are required to generate an additional warning, than if a bright-bar had restarted the series at zero."

That makes sense. If a dark-color bar is "very weak", then the trend is finding significant drying up of interest in the stock direction. That should mean we should be ready to get out at a moment's notice, which the rule allows.

"d. The reset-to-half rule is intended to help accelerate the creation of a full-exit (using A3 rules), when an extended series of medium-bars appear but without enough opposite-votes to create many A1 or A2 warnings ... this is more likely to occur when the input EndVote is fairly high (such as for Filter applications). "

That also makes sense. Filters can be used for re-entries using other methods. B3 as a whole would make the indicator more sensitive to the fluctuating day by day patterns in the indicator, but get out of a trade when the going is good. I see no need to tweak this.

========

"Is C3 important? Do you understand the logic? Should be tweaked? (specifics please) "

g. The intent of this set of rules is to allow for significant variation in the number of "delay" bars between waves, either reducing or increasing the actual time-gap based on the strength|weakness of the CVW bars during the gap. Depending on the part-D slider input, it's possible for there to be NO net-time-delay after the full-exit bar (if part-D slider is very aggressive, and if the full-exit bar was an opposite-direction bright bar, and if the bar just after the full exit was also bright opposite-direction) ... or it's possible that the time-delay between waves might be 2-3x as long as the simple C3c bar-count rule might imply, if there are a succession of flip-flop-direction Alerts.

Yes, it is the flip flops that kill a trading account. It looks like rules C3 c-f are to make sure the wave is really the start of a new wave, and not just a consolidation zone or Elliot wave abc flutter. That makes sense, and hopefully dollars. No suggestions here.

========

For D

"Do you understand the logic? Should the D2-4 mappings be tweaked? (specifics please) "

I understand the logic of the sliders, the only thing that will require some thought is the OFF switch is at opposite ends in different options, but that is to be expected if you go from Agrs2Cnsrv. It is fine the way it is, and makes logical sense. It probably should not be tweaked. Your explanation is good.
oops ... my mistake ... Slider=1 => off (ie never converts)

========

Reviewing your changes to A3ab.

The major difference to A3a seems to be:

"The count *restarts at zero* if a bright-color bar that meets the BgnVote threshold is encountered (not just a "strengthening bright" case)."

That makes sense, giving priority to the BgnVote, but resetting the count to A warnings.

Prior A3b said

"b. When the series-count of warnings hits a threshold that is derived from an input-slider (see part D below), the bar where the hit appears becomes a black full-exit bar. An extreme-conservative approach uses a threshold of 1, ie full exit on every warning ... an aggressive approach uses a threshold of 4, ie a full exit after 4 warnings (without any intermediate bright bars). "

New A3b says:

"b. If a "strengthening bright" bar appears (fairly likely since NetVote can easily increase after a Warning condition), then the current warning-vote count is *reduced by one* (min=half of warn>exit threshold). "

Ok. I see. The strengthening bright" bar is given its own logic in reducing the warning vote. Makes sense. No complaints there..

========

General Comments.

This seems to be an important slider to the whole functioning of the CVW system. The way you have described it is pretty clear. I think it is more helpful to you to do what you are doing, to give the rationale for what you are suggesting, and to ask specific questions for us to answer. It also focuses our attention on the matters that mean the most to you.
thanks for bearing with me!
Top of the page Bottom of the page
JimDean
Posted 3/18/2019 1:25 PM (#9423 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Sorry about changing things mid-stream ... I've refined the rules for part A3ab (warnings > exits) ... all else the same ... also includes fixes from Ken's and Salim's responses

OK ... relaxing Sunday ... lemme try this again, with a different approach. Your feedback is valuable to me, and I just need to find a better way to explain things, and a more focused way of asking questions that might assist me. Please *ignore* the prior post about this, to prevent confusion. Hopefully this explanation *IS* clear enough to use in a Help manual for new-users. I've deleted my prior long post, and replies to it, since this restates it hopefully with much greater clarity.

There are three things which I'm addressing now, all of which are very important imho, esp re the "trading" mode of CVW (vs filtering). Two of them bear on timely exits, and one is intended to help prevent nuisance "chop" entries. I'll deal with them one at a time ... first, explaining the *intent* (which if you disagree, I'd like feedback on), then explaining the rules for implementation, *without* using detailed examples which seem to be more confusing than helpful. I'll try to ask *specific* questions that y'all can answer succinctly.

A. Converting "dark" band-color "warning" bars to "navy|black" band-color "full-exit":

... 1. The primary means of creating a (navy) full-exit is when the number of opposite-wave-direction-votes hits the threshold-value defined by the EndVote input. This is functional and settled.

... 2. Another way that a (navy) full-exit appears is when all three of the "strips" are navy ... that is, the net of 3 Slope votes = 0, net of 3 Stack votes = 0, and net of two CurBar votes = 0 ... each of these incorporates fuzzy logic, etc. This happens occasionally, when a wave peters out but never quite gets enough opposite votes to trigger A1. This is functional and settled.

... 3. NEW logic creates a full-exit shown as a black bar to clarify what caused it, but the Return value is the same as a navy-bar case. It allows a succession of dark-green/red warning bars (see part B for detail re how warnings appear) to trigger an exit. This is a more "normal" situation than A2, and often provides a usefully-earlier exit than A1 might.
... ... a. "Succession" means a series of dark-bar warnings, possibly separated by medium-color "weakening" bars which have no impact on the series-count. The count *restarts at zero* if a bright-color bar that meets the BgnVote threshold is encountered (not just a "strengthening bright" case).
... ... b. If a "strengthening bright" bar appears (fairly likely since NetVote can easily increase after a Warning condition), then the current warning-vote count is *reduced by one* (min=half of warn>exit threshold).
... ... c. When the series-count of warnings hits a threshold that is derived from an input-slider (see part D below), the bar where the hit appears becomes a black full-exit bar. An extreme-conservative approach uses a threshold of 1, ie full exit on every warning ... an aggressive approach uses a threshold of 4, ie a full exit after 4 warnings (without any intermediate bright bars).

Is A3 important? Do you understand the logic? Should be tweaked? (specifics please)


B. Converting "medium" band-color bars to "dark" color bars ... that is, converting in-wave "decreasing strength" bars to in-wave "warning" bars. The purpose of warning bars is to inform the user that adverse "votes" are getting stronger, and that a full end of the wave may be imminent.

... 1. The primary means of creating a (dark-green/red) warning is when the number of opposite-wave-direction-votes hits *half* of the threshold-value defined by the EndVote input. This is functional and settled.

... 2. Another way that a warning-bar is generated is when the three "strip" vote-categories are all "nearly" neutral ... that is, the net of 3 Slope votes is +1|0|-1, and the net of 3 Stack votes is +1|0|-1, and the sum of all seven votes is +1|0|-1 ... this echoes the logic of A2, with looser limits since it's creating a warning rather than a full exit. This happens reasonably often, during consolidation and mild-pullback situations. This is functional and settled.

... 3. NEW logic creates a dark-color warning bar, shown as a different shade (darkolivegreen/maroon - new feature not previously discussed) to clarify what caused it, but the Return value is the same as a dark-green/red case. It allows a succession of medium-green/red "weakening-strength" bars to trigger an exit. A "weakening" bar is one with a lower net-Vote than the prior bar (within an active Wave).
... ... a. "Succession" means a series of medium-bars. The count *restarts at zero* if a bright-color "strengthening" bar is encountered.
... ... b. When the series-count of medium-color bars hits a threshold that is derived from an input-slider (see part D below), the bar where the hit appears becomes a darkolivegreen/maroon "warning" bar. An extreme-conservative approach uses a threshold of 2, ie a warning after two mediums ... an aggressive approach uses a threshold of 5, ie a warning after 5 mediums (without any intermediate bright bars).
... ... c. The medium-bar count *resets to half its threshold value* after any dark-color warning bar (gen'd by any B1-3 method) is encountered. That is, since the dark-color bar is "very weak", fewer ongoing medium-bars are required to generate an additional warning, than if a bright-bar had restarted the series at zero.
... ... d. The reset-to-half rule is intended to help accelerate the creation of a full-exit (using A3 rules), when an extended series of medium-bars appear but without enough opposite-votes to create many A1 or A2 warnings ... this is more likely to occur when the input EndVote is fairly high (such as for Filter applications).

Is B3 important? Do you understand the logic? Should be tweaked? (specifics please)


C. Delaying new-Wave "bright-bar" inception (delay-logic explained in C3):

... 1. The BgnVote input-slider defines a net-sum-of-seven-Votes threshold that must be met, in order for a Wave to begin. This creates a "bright" bar (lime/pink). Once the Wave is active, the meaning of a subsequent bright bar changes ... lime/pink then indicates that the net-vote of the current bar is *stronger* than that of the prior bar (also true of wave-inception-bar, but disregards threshold). This is in-place and functional.

... 2. It's possible in some circumstances that a sudden direction-reversal might occur ... ie a bright bar of the opposite-direction *during* an active Wave. Since OT cannot mechanically process a "pure same-bar, single-Order reversal" via a TradePlan, and since this can sometimes (esp with low-threshold BgnVote inputs for Filters) be a single-bar blip without follow-thru in the new direction, CVW treats an opposite-color bright-bar during an active Wave as a full-exit (black color), ending that Wave but not on its own initiating a new Wave in the opposite direction. This is in-place and functional.

... 3. After a meaningful "move/trend", oft-times a period of Consolidation (calm or volatile) occurs, while the market rebalances or recovers from a major news item. The time required for this is nearly impossible to predict since the reason for the state-change is not conveyed by volume-price data. During this time, false/nuisance-chop "entry" signals are prone to appear from simple logic, which can quickly eat away both profits and trader-confidence. Therefore it's prudent to "intelligently delay" the start of a new Wave.
... ... a. An input-slider (see part D below) defines a required "delay Vote" threshold to be met, after a Wave ends, before a new one (in either direction) can ensue. This vote combines a count of actual bars with an adjustment for the strength and direction of those bars. Once the vote has passed the delay-Vote threshold in a given direction, any "bright" bar whose net-Vote meets the input BgnVote requirement will initiate a new Wave.
... ... b. Delay-votes between Waves are tracked separately for bullish and bearish cases ... that is, the Delay-vote for Bullish might be met, allowing a new Bullish wave to begin with a bright(lime) bar ... at a time when there is an insufficient Delay-vote to allow a Bearish wave to begin with a pink bar.
... ... c. Delay-votes are incremented by one for *both* Bull and Bear for every navy (ie neutral) bar *after* the full-exit bar gen'd by A1-3 rules ... that is, there is always at least one intermediate bar between the end of one Wave and the start of a new one (ref C2 TradePlan limitations).
... ... d. An "Alert" bar (blue=bull,purple=bear) occurs between-Waves, when the NetSum of seven Slope +Stack +CurBar votes hits half of the input BgnVote threshold, in a given direction. When an Alert bar appears, the Delay-vote *for that direction* is incremented by one (ie in addition to the normal C3c increment). Also, it *decreases* the Delay-vote *for the opposite direction* by one (ie nullifying the normal C3c increment). Alerts have Return values of 4=bear & 6=bull (5= navy|black full-exit or neutral).
... ... e. If the delay-vote has not yet passed its C3ab threshold, then any C1 "bright" bar is treated as a "strong Alert" rather than the beginning of a new Wave. This shows up as a an Alert with a somewhat lighter shade of blue|purple for bull|bear, but creates the same 6|4 Return value as a normal Alert. (This color alternative is a new feature not previously discussed).
... ... f. When a C3e "strong Alert" occurs, the Delay-vote *for that direction* is incremented by two (ie in addition to the normal C3c increment). Also, it *decreases* the Delay-vote *for the opposite direction* by two (ie net of this and normal C3c increment = decrement of one).
... ... g. The intent of this set of rules is to allow for significant variation in the number of "delay" bars between waves, either reducing or increasing the actual time-gap based on the strength|weakness of the CVW bars during the gap. Depending on the part-D slider input, it's possible for there to be NO net-time-delay after the full-exit bar (if part-D slider is very aggressive, and if the full-exit bar was an opposite-direction bright bar, and if the bar just after the full exit was also bright opposite-direction) ... or it's possible that the time-delay between waves might be 2-3x as long as the simple C3c bar-count rule might imply, if there are a succession of flip-flop-direction Alerts.

Is C3 important? Do you understand the logic? Should be tweaked? (specifics please)


D. New WavWEDcntAgrs2Cnsv Expert input Slider = 1-5 (controlled by VoteGuru):

1. This input defines the thresholds used by rules A,B,C. It also has negative-override option (Xprt version only of course) that allows the three thresholds for Warnings, Exits, and Delays ("WED") to be separately specified. "Aggressive" implies the user wants to minimize non-committal "neutral" zones, loosening requirements for Waves to start and making it more difficult for Waves to end.

2. It's harder for Waves to start, if the Delay-vote-threshold is higher. So, a slider=1 "aggressive" input sets low delay-vote thresholds, and slider=5 "conservative" input sets higher thresholds. The planned threshold-mapping is 2,3,4,5 delay-votes (slider=1=off = no required delay), as defined by C3 above.

3. It's harder for Waves to end, if the A3-Warning-count threshold is higher. So, a slider=1 "aggressive" input sets higher warning-count thresholds, and slider=5 "conservative" input sets lower thresholds. The planned threshold-mapping is slider 2-5 => 4,3,2,1 dark-color-warning-bar-votes (slider=1=off = warnings never "create" a full-exit), as defined by A3 above.

4. It's harder for Warnings to appear, if the B3-Medium-count threshold is higher. So, a slider=1 "aggressive" input sets higher medium-color-bar-count thresholds, and slider=5 "conservative" input sets lower thresholds. The planned threshold-mapping is slider 2-5= 5,4,3,2 medium-color-bar-votes (slider=1=off = medium-color bars never "create" a warning), as defined by B3 above.

Do you understand the logic? Should the D2-4 mappings be tweaked? (specifics please)
Top of the page Bottom of the page
SalimHira
Posted 3/18/2019 1:42 PM (#9425 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

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

This is a much better explanation than prior, as I had literally been pulling hair and been going at it all weekend, and just could not digest it.... As requested, here are my responses:

Is A3 important? Do you understand the logic? Should be tweaked? (specifics please)

Yes. I followed the logic upto A3a. I had to re-read A3b the last part in paranthesis "(without any intermediate bright bars)". I'd be assuming (1st thought) the counts would re-start, etc. without having read part D yet. (no need to explain, I'll figure it out in the DLL)
Figuring it out in the DLL is counter-productive ... please in future always note any points of confusion. Once DLL is out there, I don't want to have to make any avoidable fixes. That's what this thread is about.
Refer to A3a to understand this ... intermediate bright bars *restart* the count.


Is B3 important? Do you understand the logic? Should be tweaked? (specifics please)

Definitely. Re-visit couple times to understand. What is difference btwn olivegreen/maroon (3) and dark-olive/maroon (3b) ... could not follow logic around it.
No need for tweaks, imho.
both colors are the same darkolivegreen ... typo ... fixed

Is C3 important? Do you understand the logic? Should be tweaked? (specifics please)
Very important. Definitely, as much better explained.
Not in imho, as good as it can be :-). Very excited to see these features in action.

Do you understand the logic? Should the D2-4 mappings be tweaked? (specifics please)
Yes to the best of my abilities. To my knowledge, I don't see anything or reason to tweak any further.

My only question comes to mind: does this DLL make a very stable knowledge-base from aggressive to conservative trading base of Volume-related platform for studies that covers all aspects of relationship between Price & Volume.
I don't know what you mean by "make" a knowledge base. It does not store samples like GA does, to create new or adapt existing code dynamically.
No, it does not cover "all aspects" ... that's pretty open-ended. It uses the CumVol paradigm price-logic to assign directionality to Volume, and from that adjusted Volume it seeks to find places where "volume-supported" bullish and bearish trends begin and end.
It does NOT do a "price study" at all ... I've deliberately been careful to leave out any logic of that nature. MTV handles all that, while ignoring volume. So, CVW and MTV should ideally be used in conjunction with one another (as Filters, anyways).


Thanks.
Top of the page Bottom of the page
JimDean
Posted 3/18/2019 2:13 PM (#9427 - in reply to #9425)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Thanks guys for your timely and thoughtful responses. I've modified both of your posts to provide answers in blue (please review), and as appropriate I've revised my original post to correct mistakes and misleading verbiage.

I've currently gotten the part A and B (and D) features in place. Part C is much tougher to code correctly, but I'm working on it.

Thanks again!
Top of the page Bottom of the page
JimDean
Posted 3/18/2019 5:07 PM (#9428 - in reply to #9427)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
OK, need some help here ...

I realized that there is a flaw in my strengthening/weakening Band color scheme (& return-value). The concept is correct and useful, but it's missing a common third option ... I had no color to represent a case during an active Wave where the netVote sum for the current bar is the SAME as that of the prior bar (and it's not a Warning). If it is a Warning, that simply repeats for every bar that it's valid for.

But if it's just a "normal" bar during a Wave whose netVote sum is unchanged from the prior bar, then it needs a NEW color, to distinguish it from increasing or decreasing bars. This is particularly important re decreasing-bar (aka "Medium" color bar) distinctions, since Medium-decreasing bars are used to determine Warning bars (see part B of prior post).

I've added two new intermediate-green/red colors to the band output ... in-between bright and medium, with *relatively* clear shade/hue-differentiation. I'd previously added (see a couple of posts ago) black as a WaveEnd variant of navy, and royalblue/mediumorchid as BrightAlertDuringDelay variants of blue/purple, and darkred/darkolivegreen as MedColorCountWarning variants of firebrick/darkgreen.

The attached snap whould make this clear ... note that all the "new" color variants are negative number "cases" in the latter part of the select case list. I've provided brief one-line explanations of each, space permitting in my editor.

Also, I attached a snap of SPY that shows most of the various colors ... please don't spend a lot of time on it ... just there to give you a feel for how the hues/shades vary.

THE PROBLEM:

I've previously noted the fact that most of those negative-number color-variants are RETURNED with the same value as their positive counterparts, since they have the same net-logical reporting-impact as far as the calling-routine cares ... for example, it doesn't really matter *how* a Warning was generated (passing EndVote/2 threshold vs count of Medium bars) ... just that it *is* a Warning.

However, these most recent two new negative-number colors, denoting during a Wave that there is no change in the netVote from the prior bar, have no positive-number counterpart that I can use for Return values ... which MUST be single-digit.

The only "available" unused single-digit return value is zero. I can assign these "same-net" cases *both* to zero, but unfortunately that means the *direction* (bull/bear) of the current Wave is NOT shown, unlike all the other values except for 5 which is a neutral bar when no Wave is active.

THE QUESTIONS:

Should I use 0 as the Return value for both of these two Active-Wave no-netVote-change-since-last-non-Warning-bar cases?

Can you think of cases where a "unclear direction" 0-output in the Focus List (versus the direction-specific 1-9 values) will create confusion ... where you'd need to know the direction in order to make the correct decision?


Please note that you aren't allowed to look at the chart for clarification ... the Return values are also used by OmniScans etc which can't "see" the chart.
A calling-routine can "remember" what direction the Wave was headed, when some previous bar was nonzero (could be prior bar, or ten bars back, etc). I know how to handle that in the coding ... but its not simple to do in a Script that OScan or ColorCharts, etc might use.

(Band 16-color Map.png)



(Expanded Band Colors Example.png)



Attachments
Attachments Band 16-color Map.png (428KB - 0 downloads)
Attachments Expanded Band Colors Example.png (131KB - 0 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 3/18/2019 5:32 PM (#9429 - in reply to #9428)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
THE QUESTIONS:

Should I use 0 as the Return value for both of these two Active-Wave no-netVote-change-since-last-non-Warning-bar cases?

Can you think of cases where a "unclear direction" 0-output in the Focus List (versus the direction-specific 1-9 values) will create confusion ... where you'd need to know the direction in order to make the correct decision?

::::::

The only case I can think of is if this is automated with no user input. Then the (e.g., ATM) program will be unsure *at that point* whether it is bullish or bearish, not keeping track of prior bars returns. This might be the case with addon trades or partial exits if an Nbar type condition is met without at least some bar being +/- ive. Really, here, you are dealing with a +0 and a -0 situation, but have only 0. If a discretionary trade is being done, then there would be no problem. But I could foresee automated problems.

as you say,

"A calling-routine can "remember" what direction the Wave was headed, when some previous bar was nonzero (could be prior bar, or ten bars back, etc). I know how to handle that in the coding ... but its not simple to do in a Script that OScan or ColorCharts, etc might use."

YOU can do that, but generally N does not do that, imho. And as you say, coding that would not be trivial.

Even though you say,

"The only "available" unused single-digit return value is zero."

I notice from your code you have N0 and -N9 available. If you have no other plans for that -N9 slot, could you use that in conjunction with N0? Then it would be a simple matter of separating the +ive and zero from the -ive in a code.

That's the only suggestion I can give.
Top of the page Bottom of the page
JimDean
Posted 3/19/2019 5:59 AM (#9436 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Here is a simple cheat sheet for Band colors:

Greenish is an active Bull Wave
Reddish is an active Bear Wave
Blue/Black/Purplish is in-between Waves
Bright means strong, Dark means weak


PS ... I've cleaned up some prior posts that were developmental or had become incorrect or redundant ...
Top of the page Bottom of the page
JimDean
Posted 3/19/2019 8:45 AM (#9439 - in reply to #9423)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
I've got all of the logic coded for the Med>Wrn, Wrn>End, and Bgn-Delay features described in post 9423. I've done enough visual testing (using the eight new symbols) to draw some conclusions ...

1. The Bgn-Delay logic is entirely useless. The only helpful thing that came out of that thinking was converting a bright-opposite-bar pure-reversal into an exit. I fiddled a lot with the delay logic, and found that:
1a. It has very little effect (for example, comparing a delay-value input of 1 to an input of 9 (!).
1b. The effect that it has is almost universally harmful ... it mainly just gives up $$ with late entries.
1c. Out of about 250 wave-tests, there were only maybe 2 or 3 where it slightly helped.
... so, I'm deleting that logic from the code (just keeping the reversal fix).
... part of the reason it didn't help is that other logic already prevents "chatter"

2. The Med>Wrn and Wrn>End logic is *consistently* helpful. It's been a little tricky to figure out what the slider settings should be, but it definitely tightens up the exits nicely in many cases.
... so, the new Expert slider will just tie to that logic, and will be named WavMWEcntAgrs2Cnsv

This also means that band-color cases -4 (royalblue) and -6 (mediumorchid) which had noted delayed-brights, are no longer in play ... shown in snap of post #9428.
Top of the page Bottom of the page
JimDean
Posted 3/19/2019 9:33 AM (#9440 - in reply to #9428)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Here is a consolidation of several prior (deleted) posts, with an elegant revised final solution.

The original problem was that a new "intermediate" color/state during an active Wave was needed ... when the netVote of the current bar exactly equals that of the prior bar. In that case, the Wave is neither "strengthening" nor "weakening". I created intermediate green/red shades for this, but since Return values from 1-9 are already all in use (and beneficial), I was stuck with returning Zero for *both* bull and bear "intermediate" cases.

It's very likely that people will want to sometimes use CVW with OScan or CC's or ATM, etc to simply identify whether the state is Bullish, Bearish, or in-between. The explanation below solves that problem nicely ...

Here's how OmniScan or ATM or ColorChart etc OScript-formula *might* be set up to distinguish a bullish from bearish from inactive-wave, taking into account all possible Return-states from 0-9 ...

All I need to do is to modify the return-value for the -2 input-request case. Currently CVW(...,-2) returns just the "t" duration as described earlier ... where "CVW" represents a "call" to the routine, per the HelpPanel #2 format ... and that "t" all by itself wasn't very helpful anyways.

So, I have altered the -2 Return-option to provide "dT.t", where "T" is the color value 0-9 (for grins), "t" is the duration, and "d" indicates the DIRECTION of the active Wave ... bear=1, bull=9, inactive=5. If a Focus List is sorted on this in descending order, all bullish will be grouped, then all in-between, then all bearish. Secondary tiers will relate to the strength of the wave.

Thus, the Direction of the Wave can ALWAYS be determined using a simple extraction formula from a SINGLE call to CVW:

Bullish Direction: int( CVW(...,-2) /10 ) = 9

Bearish Direction: int( CVW(...,-2) /10 ) = 1

Inactive Wave: int( CVW(...,-2) /10 ) = 5
Top of the page Bottom of the page
JimDean
Posted 3/19/2019 11:25 AM (#9441 - in reply to #9440)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Simplification is GREAT!

When changing the -2 Return option to dT.t as described in the prior post, I realized that MANY of the 40 Xprt Return options are NOT necessary (nor are some of the Core options).

I've removed all the options that returned only a single digit ... for example P and p ... since the "P.p" option return-value can *easily* be parsed (OScript or OLang) into P using Int(...) and into p using Frac(...). See an example of how that works for the slightly more complex new "dT.t" -2 Return option, in the prior post.

This means that Xprt now has 18 Return options instead of 40. And Core now has 7 instead of 12.

Snaps show updates to the two Help Panels. NOTE: I've deactivated the other "wordy" Help panels since they are way way out of date. I've changed the note just under the HP#1 header to refer the user to a "Help Manual", which will be a PDF with plenty of info (and maybe a few snapshots).

Do you think that any info beyond what is shown below is *really* needed for popup Help, if a complete PDF Help Manual is separately provided?

(CVWeval Parameters.png)



(CVWeval HelpPanel-1.png)



(CVWeval HelpPanel-2.png)



Attachments
Attachments CVWeval Parameters.png (192KB - 0 downloads)
Attachments CVWeval HelpPanel-1.png (469KB - 0 downloads)
Attachments CVWeval HelpPanel-2.png (294KB - 0 downloads)
Top of the page Bottom of the page
SalimHira
Posted 3/19/2019 11:49 AM (#9442 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
Do you think that any info beyond what is shown below is *really* needed for popup Help, if a complete PDF Help Manual is separately provided?

Most likely not, as sufficient, imho.

The PDF Help manual idea is sound, as can be edited on the fly without having to re-compile DLL, and be replaced as needed - while popup Help manual more work involved, including restriction of content display.

For the pdf, a thought came into my mind about linking or providing location of the PDF file in OT directory where it may reside from your popup Help.
Top of the page Bottom of the page
KenWilsdon
Posted 3/19/2019 12:26 PM (#9444 - in reply to #9441)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi Jim,

Great to see you came up with a simple solution to yesterday's problem, and at the same time found a simpler way to return variables useful to the user.

First, a general comment. I know this may be a "quick" screen shot. You have Master Set in a couple of spots, and PPMaster in at least one other spot. As my understanding from the other day is we were going to go with Master Set, this needs attention.

Also, I noticed in the Actual Inputs and Derivatives section, you refer to HelpPanel#4, so if you are limiting Help panels to 2, then this should be changed also.

"Do you think that any info beyond what is shown below is *really* needed for popup Help, if a complete PDF Help Manual is separately provided?"

Probably no other info required on HP1 or 2 if in the PDF.

I am sure you are already planning this, but in the PDF, be sure to highlight the usefulness of the return values in everyday discretionary trading, and (like in my case) using this for automated trading. Most "Non-techie" people will probably stick to return values -1 and -2, and possibly -17 and -18 on occasion. Some real world examples there would be very useful, as well as how to use the Int and Frac functions in OLang to get what they want for an Omniscript ( I know that is super basic, but some are afraid of coding). I am sure between the PDF and the introductory video you are planning, everything will be covered satisfactory.
Top of the page Bottom of the page
JimDean
Posted 3/19/2019 1:00 PM (#9445 - in reply to #9444)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Thanks for comments.

Salim: OT can "recognize" additional PDF Help manuals that are simply copied into the Manuals folder. However, putting it there would make the CVW installation process more complex. I currently already have a TT_Help-Manuals folder in the SDK, for such things. I'll consider adding an optional installation-step to the posted instructions, that users can do if they wish.

NOTE: please check the snapshots that I post more carefully ... that's a big part of what the "DevTeam" members are needed for. Prior to a couple of minutes ago, the snapshot for HP#1 was *obviously* incorrect ... the input-explanation line for WarnConvertAgrs2Cnsv wrapped to a second line, and referred to "BgnDelay" which I made specific note had been eliminated. The snapshot has since been fixed. Please help backstop me on obvious stuff like this. It will also help y'all to better understand what's going on. Thanks.

Ken: good catch re PPMaster and HP#4. I've fixed them in the code and will update the snapshot in a little while. I found just one instance of each ... if there are two of either, please let me know where.

I also have revised the param name ... it says "WarnConvert..." now instead of "WavMWEcnt..." ... hopefully much clearer. I'm currently fine-tuning the rules for the conversions ... this logic does a bang-up job of tightening the exits, without chopping things up too much. Hooray!

I'm still debating re some extra Help Panels ... I'll do a complete Help Manual, but some things might be useful to "look up quickly" on a popup Help Panel #3, such as the CumV Method options (twelve of them), and maaaybe a somewhat more detailed explanation of the Return options. It makes more sense to move the explanations for plot options to a PDF, since I can include snapshots there with arrows etc.
Top of the page Bottom of the page
KenWilsdon
Posted 3/19/2019 1:21 PM (#9446 - in reply to #9445)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

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

Ken: good catch re PPMaster and HP#4. I've fixed them in the code and will update the snapshot in a little while. I found just one instance of each ... if there are two of either, please let me know where.


No, looks like that got them all

I also have revised the param name ... it says "WarnConvert..." now instead of "WavMWEcnt..." ... hopefully much clearer. I'm currently fine-tuning the rules for the conversions ... this logic does a bang-up job of tightening the exits, without chopping things up too much. Hooray!


I agree that "WarnConvert..." is a much better name describing its functionality.

It makes more sense to move the explanations for plot options to a PDF, since I can include snapshots there with arrows etc.


I agree, the plot options are better in a pdf.
Top of the page Bottom of the page
JimDean
Posted 3/19/2019 1:44 PM (#9447 - in reply to #9445)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
OK ... prior snap is now updated for PPMaster and HP#4 glitches.

I'm working now on what the range should usefully be for the new WarnConvert expert input. Currently, as the input goes from 2-5, the #bars for Warn>End go from 4-1 and from Med>Warn go from 5-2. 1= off, ie no conversion.

My testing indicates that an input of 5 ... ie 1 Warn > End and 2 Med > Warn, seems to work very nicely ... it's good for situations where there are no "partial exits" supported by the Trade Plan ... all "warning" bars are essentially replaced by full-exits.

Testing also indicates the an input of 2 ... ie 4 Warns > End and 5 Meds > Warn, seems always to be too late ... I've not checked carefully but I suspect that the conversion doesn't really "kick in" very often, with that setting. So, I could afford to kill off this one.

The default input of 3 ... ie 3 Warns > End and 4 Meds > Warn, seems to help noticeably, and in comparison to an input of 5 (above), it prevents extended runs from being chopped in 2-3 parts during mild pullbacks or pauses. It allows for 2 successive Warns to remain as is ... which is nice if the Trade Plan (or manual trading) does support Partial Exits.

An input of 4 is what you'd expect ... sometimes like 4 and sometimes like 5. But it's not clearly in the "yay I want PXits" nor in the "I can't handle PXits" camp. So, maybe, it could be left out.

Sooooo ... I'm thinking of changing the slider from 1-5 range to a 1-3 range, where 1=off/no-convert, 2= same as current default (3, above PXit-case), and 3= same as current 5 (no-PXit case, above). Those choices are certainly easier to understand ... AND, a negative override allows user to spec anything from 0-9 separately for Med>Warn and Warn>End, so nothing is really "lost".

IF I DO THAT, then I need to rearrange the Guru mapping somewhat. The VoteGuru is from 1-5. It currently maps directly into the Fuzz Expert as 1-5. And it currently maps in a "staggered" fashion into the 1-3 BgnVote (=>4-6 votes) and 1-3 EndVote (=>4-2 votes) sliders, like this:
Guru: 1, 2, 3, 4, 5
BgnV: 1, 1, 2, 2, 3 => votes: 4, 4, 5, 5, 6
EndV: 1, 2, 2, 3, 3 => votes: 4, 3, 3, 2, 2
... note the "stagger" so that varying the Guru provides different mixes of Bgn & End thresholds.

If I expand this idea to the WarnConvert slider, then since it's dealing with the End of the Wave, I'd want to stagger it's 3 choices versus the EndVote. And since the "1" Convert input means "off", it should probably be the one that is least-represented.
Warn: 1, 2, 2, 3, 3 => W>E: N, 3, 3, 1, 1 & M>W: N, 4, 4, 2, 2
... to stagger that with EndV, I'd need to modify the EndV map to be:
EndV: 1, 1, 2, 2, 3 => votes: 4, 4, 3, 3, 2 ... note that the default remains the same
... and if I do that, then since I want BgnV to stagger with EndV, I'd modify it to:
BgnV: 1, 2, 2, 3, 3 => votes: 4, 5, 5, 6, 6
... which I sorta like better since imho, "6" is a tradeoff that reduces false blips, w/o too much lag

Do you follow this explanation? Do you think it's a good idea to cut the Warn slider from 5 choices to just 3? Do you think the revised "stagger" scheme is a good way to go? (Please, if you don't follow this, ask now rather than waiting for DLL)
Top of the page Bottom of the page
KenWilsdon
Posted 3/19/2019 2:02 PM (#9448 - in reply to #9447)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

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

Sooooo ... I'm thinking of changing the slider from 1-5 range to a 1-3 range, where 1=off/no-convert, 2= same as current default (3, above PXit-case), and 3= same as current 5 (no-PXit case, above). Those choices are certainly easier to understand ... AND, a negative override allows user to spec anything from 0-9 separately for Med>Warn and Warn>End, so nothing is really "lost".

IF I DO THAT, then I need to rearrange the Guru mapping somewhat. The VoteGuru is from 1-5. It currently maps directly into the Fuzz Expert as 1-5. And it currently maps in a "staggered" fashion into the 1-3 BgnVote (=>4-6 votes) and 1-3 EndVote (=>4-2 votes) sliders, like this:
Guru: 1, 2, 3, 4, 5
BgnV: 1, 1, 2, 2, 3 => votes: 4, 4, 5, 5, 6
EndV: 1, 2, 2, 3, 3 => votes: 4, 3, 3, 2, 2
... note the "stagger" so that varying the Guru provides different mixes of Bgn & End thresholds.

If I expand this idea to the WarnConvert slider, then since it's dealing with the End of the Wave, I'd want to stagger it's 3 choices versus the EndVote. And since the "1" Convert input means "off", it should probably be the one that is least-represented.
Warn: 1, 2, 2, 3, 3 => W>E: N, 3, 3, 1, 1 & M>W: N, 4, 4, 2, 2
... to stagger that with EndV, I'd need to modify the EndV map to be:
EndV: 1, 1, 2, 2, 3 => votes: 4, 4, 3, 3, 2 ... note that the default remains the same
... and if I do that, then since I want BgnV to stagger with EndV, I'd modify it to:
BgnV: 1, 2, 2, 3, 3 => votes: 4, 5, 5, 6, 6
... which I sorta like better since imho, "6" is a tradeoff that reduces false blips, w/o too much lag

Do you follow this explanation? Do you think it's a good idea to cut the Warn slider from 5 choices to just 3? Do you think the revised "stagger" scheme is a good way to go? (Please, if you don't follow this, ask now rather than waiting for DLL)


Hi Jim,

Yes, I follow the explanation. And based on your testing, it sounds like cutting from 5 to 3 makes sense for the Guru. And since the Xprt user can fine tune anyways on WarnConvert to override the Guru default, it sounds like a good option.

Top of the page Bottom of the page
SalimHira
Posted 3/19/2019 2:02 PM (#9449 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
Do you follow this explanation? Do you think it's a good idea to cut the Warn slider from 5 choices to just 3? Do you think the revised "stagger" scheme is a good way to go? (Please, if you don't follow this, ask now rather than waiting for DLL)

If you cut the Warn slider, can it still be manually input / over-ride by user ?

Please elaborate a little more how "stagger" work in real trading circumstances. Thanks.
Top of the page Bottom of the page
JimDean
Posted 3/19/2019 2:09 PM (#9450 - in reply to #9449)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Salim:
Please reread the post re your first question ... it explicitly states that you can override, and how.

Your second question is touched on in the post as well, re partial exit plans vs full exits ... and mentions of chop vs continuance, and mention (re BgnV) of nuisance vs a bit extra lag for one case.

(please, read more slowly and carefully ... the last three or so posts you've made have either had errors, or asked questions, that the post I made which occasioned them already addressed. I'm not very interested in "elaborating" if the stuff that I've already written is being skimmed over. Thanks)

Top of the page Bottom of the page
JimDean
Posted 3/19/2019 3:00 PM (#9451 - in reply to #9450)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
OK ... got a new one for y'all ...

We no longer have delay-logic between waves ... but we do still have Alerts. Which don't at present "do" anything (ie in terms of potentially executing an Order in a TP).

Sometimes (I've done almost no testing for this), there are multiple Alerts that fire well before the BgnVote threshold is met, which starts the Wave.

I'm thinking of adding some logic that will Convert a succession of common-direction Alerts (if not interrupted by opp-direction alerts) into a Wave Begin, even if the BgnVote is not met.

I'm providing a snapshot that illustrates what the benefits might be. The circles on the indicator show places where purple or blue alerts fire in succession (sometimes with navy in between) ... and the ovals above them on the price chart span the SAME bars, showing what an early Begin might mean.

This is pretty exciting ... but hey it's just ONE chart. I did not cherry pick ... I just happened to notice this and am now writing the post.

Upside is obvious ... earlier entries for trades or filters. Potential downsides:
1. could create false-entry chatter in consolidation
2. if EndVote threshold is low, the earlier Begin might get killed before trend is well established

I could hard-code it ... ie, after "A same-dir Alerts with no opp-dir Alerts intermixed, and <=B navy-bars in-between, then initiate a new Wave in the direction of the Alert".

Or, I could link it to the WarnConvert slider (=> WarnAlert slider) ... A & B could have three expert configurations ... maybe: 1=off, 2= 3 & 1, 3= 4 & 0 ??? ... of course the negative-override would allow A & B to be explicitly spec'd along with the currently M & W warning-related overrides.

What do you think? Specifically, can you imagine additional downsides? Do you think I should tie this in to the same new slider (no room for another slider)? What should A and B be?


(CVW A2 Alerts Example.png)



Attachments
Attachments CVW A2 Alerts Example.png (48KB - 0 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 3/19/2019 3:27 PM (#9452 - in reply to #9451)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi Jim

This is great news!

False starts are obviously aa potential downside. Other than that, no.

Probably should be on the slider, with a value to change the # of alert bars, or non option.

All I have to go on to base A or B is the above chart, so I can’t help with that. From the chart, 2 bars looks about right.
Top of the page Bottom of the page
JimDean
Posted 3/19/2019 3:48 PM (#9453 - in reply to #9452)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Thanks, Ken. Do you mean 2 bars for A, for B, or both?

Here's the tougher question ... refer back to the post that discusses staggering with BgnV and EndV vs Warn ... I'm still in process of testing those variants.

But intuitively, if there are three Alert Convert options (AB1off, AB2, AB3) ... such as off, 3&1, 4&0 or maybe off, 5&2, 3&0 ... etc ...

Should the "likelihood" of the Alert Convert occuring "track with" the "likelihood" of the BgnVot requirement being met?

That is, if only 4 BgnVotes are needed, should the Guru-mapped Alert pattern be easier or harder to satisfy, versus the alternative Alert pattern that's Guru-paired with 6 BgnVotes being required?

The first way (4+ easier) would "underscore" the impact of the BgnVote setting
The second way (4+ harder) would "smooth" the impact of the BgnVote setting.

Should the likelihood of the Alert parallel the likelihood of an End occuring early, or should it be paired with an extended less-choppy End?
Top of the page Bottom of the page
JimDean
Posted 3/20/2019 3:34 PM (#9455 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
CVW uses "standard" Cumulative Volume calculations. Bars with zero volume will essentially flatline the CumV calc during that time at whatever level it had before them. All slopes will quickly reach zero (horizontal), and stacking will relatively quickly move to zero ... so net Votes will be zero. This will cause any active Waves to exit fairly soon, and will prevent any new Waves from starting.

Once Volume reappears, unless it's huge, just a bar or two here or there is unlikely to be enough to cause slope & stack votes to appear since MA's require lots of bars.

So, my guess is that during times when a symbol is not actively traded ... ie when a signif percentage of bars have no volume or very little here and there ... then CVW will flatline.
Top of the page Bottom of the page
JimDean
Posted 3/22/2019 12:43 AM (#9457 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
... revision for upcoming SBAS testing, if we do it ...

Ken's symbols ... I replaced MAR with SPY, since MAR has a goofy bigjump>consolidation issue
SPY
PCAR
NCLH
CTAS

Salim's symbols ... they are more short-term-y and it's my guess that fits your usual M.O. pretty well.
WBA
ADP
ALXN
LILAK
Top of the page Bottom of the page
JimDean
Posted 3/23/2019 9:52 AM (#9459 - in reply to #9457)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
As a result of extensive discussion and discovery of an "elegant" solution for Add/PXit modelling within the Stradicator, I'm revisiting some prior conclusions. May seem like back&forth wastes time, but it affects a LOT of future work ... better to carefully plan than haphazardly backtrack.

First ... with Ken's very gracious and time-consuming help, we came up with what looks like a good paradigm to define how NAPF (entry,add,pxit,fullx) scaling options might be specified and implemented within CVW (or other stradicators, as a common standard), *without* requiring any additional input sliders. This re-opens the "equity calcs in the Strad vs in TradeTrak" question ... addressed in later post).

The VoteGuru will have three Experts, abbreviated: Fuzzy, BgnV & EndV. All three will have positive and negative slider values, ranging from -5 to +5 (0= use Guru or Master mapping).
I'm undecided re negative slider values in Xprt or just Cstm versions, but since Cstm distinction offers typed-in overrides that Xprt doesn't, I'm leaning towards including the neg-slider ranges in Xprt as well ... they're simple to understand. My "marketing plan" is for most people to buy Xprt.

The "WarnConvert" slider that I used for testing will disappear, and its functionality (ie how PXit Warnings are created from Mediums and FullX's are created from Warnings) is being fully absorbed by the EndV slider. Parallel to that, several Add-method alternative rules are being meshed with the BgnV slider (w/help from +/- of Fuzzy).


The new -5 to +5 EndV slider will be:
+EndV: 1(4v34)30%, 2(3v23)40%, 3(3v34)30%, 4(2v23)40%, 5(2v34)30%
- EndV: 1(4v45)20%, 2(3v22)50%, 3(3v45)20%, 4(2v22)50%, 5(2v45)20%
... meaning:
S(EvMW)Sz%, where S=slider-value, E=#opp-dir Votes for FullX (half that value creates a Warn), M= #medium-grn/red bars to create a Warn, W= #dark-grn/red Warns to create a FullXit, Sz= size of PXits relative to 100% Entry (can create early FullXit, and affects Equity calcs).
... notes:
+1 to +5 are "recommended middle of the road" choices; -1 to -5 are "extreme" choices
#opp-dirn Votes to force Wave-End (ie FullX) are 4,3,3,2,2 for both +1>+5 and -1>-5
MW-patterns alternate for 3,3 and 2,2 Vote-options; less-useful 4-Vote option has just one MW
MW=34 means 4th warn-PXit => FullX and 3rd med-weakening => PXit; 22=quickFX, 45=slowFX
... counting:
M-count => MedToWrn/2 when Warn hits; intermed brights decrement count by 1 (min=0)
W-count decrements by 1 for each intermed Bright, but never below WarnToFullXit/2 value
... override VMWPp (Cstm, manually-typed):
V=#EndVotes (1-7) ... 1|5-7 may be illogical in combo with BgnV in some situations
MW= #med > wrn & #wrn > end ... each can be 0-9
Pp=PXit Size ... can be 10-90%
... note: it's possible to create "dumb" BgnV rules, esp in combo with EndV &/or Fuzzy


The new -5 to +5 BgnV slider will be:
+BgnV: 1(4vAf)50%1, 2(5vAt)40%2, 3(5vAf)50%1, 4(6vAt)40%2, 5(6vAf)50%1
- BgnV: 1(4vAn)0%0, 2(5vAx)30%3, 3(5vAn)0%0, 4(6vAx)30%3, 5(6vAn)0%0
... meaning:
S(BvAR)Sz%N, where S=slider-value, B=#net Votes for Entry (half that value creates an Alert, but I might kill off Alerts since they don't "do" anything), AR= Add-creation-rule to be used (see below), Sz= size of Adds relative to 100% Entry (affects early-FullX and Equity calcs), N= max# of Adds allowed in a given Trade-Wave (to prevent adds near End of Wave).
... Add-creation:
Adds occur on Bright bar following some non-bright, no-warn bar, for a limited #Adds/Trade-Wave
Af=few: max-1/Trade = Bright after Medium-weakening, and Bright netVote must be >= BgnVote
At=typ: max-2/Trade = Bright bar after Medium-weakening bar, w/o any netVote requirement
Ax=xtra: max-3/Trade = Bright after Med-weak OR after Neutral-same-vote, w/o netVote reqmt
... limitations:
NetSize during trade varies = Entry+Adds-PXits thus-far; *max*= Ntry+Add% (Ntry=Toe|Full)
If NetSize-PXitSize => FullX, no adds; if NetSize-2*PXitSize => FullX, Add ok if Add% <= PXit%
... override VRNLPp (Cstm, manually-typed):
V=#BgnVotes (1-7) ... 1-3|7 may be illogical in combo with EndV in some situations
R=0(An), 1(Af), 2(At), 3(Ax) rule
N=max#Adds during Trade-Wave ... can be 0-9
L=NetSizeLimit during Trade = Entry(Toe%|100%) + L*Add%
Pp=rule-based Add% ... can be 10-90%
... note: it's possible to create "dumb" EndV rules, esp in combo with BgnV


The new -5 to +5 Fuzzy slider will be:
+1 > +5 spec same Fuzz factors as -1 > -5, but max Fuzzy pct will be less than current
Negative Fuzzy slider means Trades use "Toe-In" Entry method, rather than 100% Entry
... ToeIn rules:
Initial BgnV Bright bar enters with An=20%, Af=30%, At=40%, Ax=50%
Bright 2nd bar of Wave increases size to 100%; this does not "count" as an Add
If 2nd bar *not* Bright, then don't increase unless an Add-rule is met later
... notes:
If EndV's PXit% is >= ToeIn%, then if no 2ndBright or Add, the 1st PXit may end the trade
If no 2ndBright, then *max* NetSize during trade is Toe%+Add% (ie smaller than 100+Add)
... override BbbPpTt (Cstm, manually-typed):
Tt=ToeIn size 10-90% ... note: it's possible to create "dumb" ToeIn rules, esp in combo with BgnV &/or EndV
Bbb= Fuzzy-base-avg #bars 40-200,
Pp= Fuzz-Pct of base 10-90%


Comments:

Although at first, written out like that, it looks pretty complex, I believe that most of it will be quite "intuitive", since the user *sees* the Entry, Add, PXit and FullX signals as dots on the PricePane, and since the sliders move in a fairly logical progresssion. The negative-Fuzzy rule re ToeIn's is sort of intuitive, since it calls for "fuzziness" regarding the initial Entry size.

The Cstm-version manual-typed overrides are extremely flexible, allowing the slider-rules to be widely varied ... and can create unwise or silly models, but that's true of nearly all the Cstm manual-typed overrides ... the Cstm user is essentially saying that their desired method is much different than what the Stradicator was "envisioned" to be used for ... or is saying that they consider the canned rules to be inadequately constructed ... or is just playing around to see how things work.

This is extremely "elegant" in that just three sliders "logically" control a huge spectrum of decisions re how to implement the "indicator-values" to define the extent of a Wave, and to manage Trading based on those factors. By including this in the Strad, the ability to "optimize" all the param's in the pattern is greatly enhanced.

Currently OT's TradePlans don't allow for dynamic Add/PXit patterns, but a solution for this is well in the works for later. However, the Add/PXit rules *can* be implemented on a "mechanical" basis if the user places the broker-orders manually. The "Signal" Return-value option, plotted in the FL column, makes this very easy to do ... it will be T.Ppp. T=1-9= type of order: 1-4=Short NAPF, 9-6= Long NAPF, and 5= not in trade ... sorting ascending/descending will bubble the initial Entries to the top. Ppp will be the percent-size for the Order (I will resurrect the SmartSize indicator, to calculate the #Shares that represent 100%, based on user-spec'd Equity-Commitment and ATR-Risk, and maybe also on MarketState) ... SmartSize in the adjacent column, multiplied by Ppp from this output, defines #shares for the order.

As mentioned earlier, my intent is for these three Experts (and their Guru) to be highly "portable" ... ideally operating in exactly the same way for other Stradicators such as a new version of MTV called PVS (Price Volatility State), and polished versions of HAT (Heiken-Ashi Trend), ADB (Adx-Dmi-BolBand), and MMD (Mighty MacD) that are already in the pipeline.
Top of the page Bottom of the page
JimDean
Posted 3/23/2019 10:52 AM (#9460 - in reply to #9459)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Need your comments about this ...

Currently, the TimeGuru and VoteGuru sliders sort of "work against" one another. That is, the TimeGuruFst2Slo =1 setting is intended to help model brief-duration trades that rapidly react to changes in the CumV values (small lag, large chop).
In contrast, the VoteGuruAgrs2Cnsrv =1 setting spec's entry vote rules that are "easy" to satisfy, and exit vote rules that are "hard" to meet ... thus minimizing blue-band zones, making it easy to form red/green waves for "filter" or "market state" types of uses ... however those settings can allow waves to begin during transitional/volatile periods, and to extend well past the putative visual end of the "main trend".
So, when both Gurus =1, the net result can be a lot of brief trades, many of which can occur during consolidation or wild-transition periods. Ungood.

When TimeGuru=5, it uses long MA periods and gently-changing MA calc methods, with 4-bar slopes (vs 2-bar for prior example). This means that stack and slope relationships don't change very fast, resulting in long series' of bars in red/green Waves. There's more lag, but a lot less chop than the TimeGuru=1 model.
In contrast, the VoteGuruAgrs2Cnsrv=5 setting defines entry vote-rules that are "hard" to satisfy, and exit vote-rules that are "easy" to meet ... which usually means fewer trades, entering later once the trend is fully rolling, and ending when just a little opposition appears ... ie a "conservative" approach for the "timid Timothy" trader.
So, when both Gurus =5, the net result can be a medium-duration trades with significant entry and intermediate exit lag, that tend to miss the earlier most-profitable portion of trends. Ungood.

It seems to me that the two Guru's should, when sliding from min to max, work more or less in concert regarding the net effect on the Wave-creation. So, that means either the TimeGuru would need to be reversed to be "Slo2Fst" ... or the VoteGuru would need to be reversed to be "Cnsrv2Agrs" ... and the three Experts related to the reversed Guru would also need their directions reversed.

QUESTION: which should I reverse? Or, should I leave them as-is?
Top of the page Bottom of the page
JimDean
Posted 3/23/2019 11:01 AM (#9461 - in reply to #9460)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Regardless of which (if either) Guru is "reversed" (prior post) ... there is an issue with how the Fuzzy slider interacts with the BgnV and EndV sliders ...

The Fuzzy slider goes from Small to Large (mapped to VoteGuru 1-5). Small fuzzy means + & - votes are created more easily (rather than being "read" as "equivalent to zero"). This means the likelihood of getting "high #'s" of votes of either type is increased.
When Guru= 1, Fuzzy=1 and BgnV=1 (4 votes) and EndV=1 (4 votes) ... which votes are "easy" to get due to the small fuzzy. The small fuzzy "agrees with" the (low) BgnV to make it very easy to Begin a wave, but the small fuzzy "disagrees with" the (high) EndV that's supposed to make it hard to End a wave.
When Guru= 5, Fuzzy=5 (hard to create votes) and BgnV=5 (6 votes) and EndV=5 (2 votes). That vote-pattern is "intended" to make it hard to start a wave and easy to end it. But, again, the Fuzzy effect agrees with BgnV, and disagrees with the intent of EndV.

Ideally, if we want the VoteGuru Agrs2Cnsrv "idea" to be consistent for all three of its Expert sliders, then *maybe*, WHEN the Guru 1-5 is controlling the Fuzz slider, it should use 1-5 small-large fuzz for BgnV's, and 5-1 large-small fuzz for EndV's. However, implementing that simple-to-understand change in the code requires some hoop-jumping so I can't easily do a quick fix and test it and maybe then undo it. Furthermore, if the Fuzz Expert slider is used (overriding the Guru map to it), then it would logically need to provide similarly-opposite fuzz-impacts on Bgn & End.
This means that the Fuzz slider would no longer aptly be labelled "small to large" ... rather, its label would be "aggressive to conservative" or maybe some abbreviation meaning "enhance to attenuate" (the effect of the Bgn/End votes). Revising the Fuzzy slider this way would mean the Guru 1-5 map would automatically be "fixed" as described, along the way.

This change would make the combo of VoteGuru sliders work more logically and consistently ... BUT it would affect the results ... accentuating the EndV effects, while keeping the BgnV votes the same as they are now (since Fuzzy "disagrees" with the EndV, per above). This *should* result in more timely exits, to some degree or another. It also means I need to tweak the Fuzzy percentage range ... which I plan to do anyways. Keep in mind that the fuzzy effect engages with during-the-wave Add and PXit rules too, which are based on +/-votes that appear more readily with small fuzz.

OR ...

Maybe you might *like* the idea that the Fuzzy slider "attenuates" the EndV effect ... but *dislike* the idea that the Fuzzy slider "augments" the BgnV effect. If so, the internal-coding change to apply fuzzy in opposing ways for Bgn & End would be nearly the same, but just flip-flopped. OR ... maybe you have reason to believe that the current way it operates, reinforcing BgnV variations and ameliorating EndV variations ... is the best approach (I had not intended this originally btw).

QUESTION: should I modify the way Fuzzy works, as described ... and if so, should it "augment" the effect that the BgnV & EndV settings are "driving at", or should it "attenuate" the effect?
Top of the page Bottom of the page
JimDean
Posted 3/23/2019 11:26 AM (#9462 - in reply to #9461)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Changing gears a moment ... addressing a Q that Salim emailed me about ... how do the previously-posted changes, plus several others I'll be posting about next ... affect my schedule?

1. It will take longer to get CumV done, since tweaks are needed and since Equity is (very likely) to be added and since I want the code for a lot of it to be "easily portable" to other stradicators later on.

2. Ken's said that he's just fine with my deferring the resumption of the "DynamicTradePlan" project until after I get at least 2-3 of the "normalized" stradicators (CVW, HAT, ADB, PVS, MMD) completed and listed for sale ... since he will be buying them :~) Thanks, Ken!

3. I need income soon, so I *want* to get CVW done quickly.

4. After CVW is released, I will immediately create an "OT2019 updated" release of MTV version B2 that has license code repaired (for Salim), but likely no other changes ... it will be free for all current owners. I don't plan on releasing any further updates for B2 in later years, but this version will continue to work *on* OT2019 and VT11 platforms "forever".

5. Probably I will then create an upgraded C1 version of MTV that supports the new Zacks groups, and adds a Market State composite plot & return from previously-developed Add/PXit XLS logic, which will make it straighforward to create a "Signals" Return showing Entry/Add/PXit/Exit. With that, I'll also create Entry/Exit shells based on Signals Return so MTV can create Entry &/or Exits in a Strategy. This will be an optional upgrade probably for $295 or $395, depending on how much work this requires. C1 will likely be the last upgrade to MTV, with ongoing free updates to future OT/VT annual releases, since the new PVS stradicator will likely supplant it in many ways. But MTV will always have some features that PVS won't ... notably the availability of parallel-OScripts for OVest use, and PVS likely won't have the "symbol-slider", nor use the fancy text-file driven Help engine, nor use the same kind of user-editable Master-slider text file. PVS will incorporate all the new Stradicator paradigms being formalized in CVW. Since MTV upgrade will be released fairly soon, I'll likely wait till after HAT and ADB and MMD strad's are done, before releasing PVS. The names of all the new Stradicators will employ the Easy / Xprt / Cstm suffixes, and the Edge/Flex/Powr nomenclature used for MTV will be retired.

I can't provide specific dates, but this at least updates the planned sequence.
Top of the page Bottom of the page
SalimHira
Posted 3/23/2019 1:30 PM (#9465 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
1. QUESTION: which should I reverse? Or, should I leave them as-is? So, that means either the TimeGuru would need to be reversed to be "Slo2Fst" ... or the VoteGuru would need to be reversed to be "Cnsrv2Agrs"

This is a toughy question to respond too... If you leave as-is, that does not do any justice, unless we are aware of it (as we been informed). If you should reverse, that is also subjective, imho, as both have pros & cons v.s. fast-moving markets v.s. slow-moving time periods... and I have been debating internally. I really do not have a conclusive answer to it as a preference ... but do agree to your statement that it should "work more or less in concert regarding the net effect on the Wave-creation".

So, if I were to choose - it'd probablly be Time Guru, as can fiddle with Vote Guru... or should it be other way around, confusing myself.

---------------
2. QUESTION: should I modify the way Fuzzy works, as described ... and if so, should it "augment" the effect that the BgnV & EndV settings are "driving at", or should it "attenuate" the effect?

First, I prefer this - abbreviation meaning "enhance to attenuate" (the effect of the Bgn/End votes). And, yes, it should, imho, "should it "augment" the effect that the BgnV & EndV settings are "driving at", BUT ALSO - should it "attenuate" the effect."

Can it have both - or something to in-between care of both situation, that would also take care of the 1st question.

So yes, at minimum, the fuzzy should be modified and be effective in its usefulness, imho. It is one under-rated feature that needs to be exploited - as you have recognized nicely.
Top of the page Bottom of the page
KenWilsdon
Posted 3/23/2019 2:40 PM (#9466 - in reply to #9461)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
Hi Jim,

My motto is the infamous words of NY Yankee catcher Yogi Berra: "If you come to a fork in the road, take it!" That must be why I chose C.

I agree with Salim that I can not choose on the first Question which way the sliders should go. So I vote to leave as is.

On the second question, your statements:

"Ideally, if we want the VoteGuru Agrs2Cnsrv "idea" to be consistent for all three of its Expert sliders, then *maybe*, WHEN the Guru 1-5 is controlling the Fuzz slider, it should use 1-5 small-large fuzz for BgnV's, and 5-1 large-small fuzz for EndV's. However, implementing that simple-to-understand change in the code requires some hoop-jumping so I can't easily do a quick fix and test it and maybe then undo it. Furthermore, if the Fuzz Expert slider is used (overriding the Guru map to it), then it would logically need to provide similarly-opposite fuzz-impacts on Bgn & End.
This means that the Fuzz slider would no longer aptly be labelled "small to large" ... rather, its label would be "aggressive to conservative" or maybe some abbreviation meaning "enhance to attenuate" (the effect of the Bgn/End votes). Revising the Fuzzy slider this way would mean the Guru 1-5 map would automatically be "fixed" as described, along the way.

This change would make the combo of VoteGuru sliders work more logically and consistently ... BUT it would affect the results ... accentuating the EndV effects, while keeping the BgnV votes the same as they are now (since Fuzzy "disagrees" with the EndV, per above). This *should* result in more timely exits, to some degree or another. It also means I need to tweak the Fuzzy percentage range ... which I plan to do anyways."

Make me lean to changing it as above, as it should work better with the Gurus with the proposed change. I understand it cannot be undone easily.



Top of the page Bottom of the page
JimDean
Posted 3/25/2019 10:21 AM (#9467 - in reply to #9459)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Thanks for your responses. I realize that the questions were difficult. Here's what I've concluded - please read twice before responding ... snapshot shows one example but please vote on choices ...

1. Keep the TimeGuru and its experts "sliding" in the current "Fst2Slo" order (ie bias to short-duration trades leftmost).

2. Reverse the VoteGuru and relabel it to one of these:
a. GURU_Nervous2Confid
b. GURU_Careful2Hopeful
c. GURU_VoteBrief2Wide
d. GURU_TradeBrief2Xtnd
e. GURU_WavesTyt2Wide

... these are all hopefully *quite* self-explanatory, and all will "fit" in the Param label area. Other mixes of the halves can work as well, such as "WaveBrief2Xtnd" ... those examples should be enough to vote on. No matter which is chosen, this reversal will "parallel/reinforce" the direction and idea of the GURE_TymFrmFst2Slo" slider. I decided not to use the term "filter" in the label, since it's ambiguous. Which options do you prefer, most to least?

3. BgnVote slider will reverse to become "BgnVotCmbTotSix2Four", and EndVote slider will become 'EndVotOpposTwo2Four", I think the labels are pretty clear. These correspond to the conceptual labels of the reversed Guru, above.

... it's important to understand the thrust and playing field of the comments above, which is firmly decided now, before considering the next one

4. Fuzzy Slider's current internal logic is a problem, as noted earlier. I need to "reassign" those fuzzy-calc results, so BgnV=6 *tougher* and EndV=2 is *easier* to satisfy for the Guru=1 (cautious-trade, brief-wave) case, and reverse the effect ... BgnV=4 *easier* and EndV=4 *tougher* for the Guru=5 (optimistic-trade, wide-wave) case. Keep in mind that the fuzzy-zones are independently calculated internally for eight different categories that go into the vote-generation process.
After much internal debate about this, I think that the fuzzy-slider should allow the user to strengthen<>weaken the fuzzy-influence on the votes, as described in the prior paragraph, or maybe even *reverse* it. That is, one end of the fuzzy slider would do what the paragraph says, and the other end would do the opposite (make BgnV=6 easier, and EndV=4 tougher). The middle of the fuzzy slider would be "neutral" in its impact.
However, the fuzzy-slider also should control how "big" the fuzzy-zone should be, in addition to how it impacts the Bgn & End votes. So, if slider=1 means BgnV=6 tough and EndV=4 easy, then slider=2 would mean the same, but not AS tough/easy ... that is, the fuzzy-zone for BgnV would be a bit thinner for BgnV and a bit wider for EndV, for fuzzy-slider=2 vs fuzzy slider=1.
On the other end, fuzzy-slider=5 means BgnV=4 is easy (thin fuzz zone) and EndV=4 is tough (wide fuzz zone) ... so fuzzy-slider=4 attenuates that a bit ... BgnV fuzz is a bit bigger, and EndV fuzz is a bit smaller. Fuzzy-slider=3 (default, middle) would presumably use the same-size fuzzy zone for both Bgn & End vote.
Thus, as fuzzy-slider moves from 1-5, the fuzz for BgnV eval would change from big-small, and the fuzz for EndV eval would change from small-big.
The Cstm version manual override would become PppBbEe, where Ppp=periods for fuzzy-basis average, Bb=fuzz-percent for BgnV, and Ee=fuzz-percent for EndV ... Xprt & Cstm both use negative to toggle "ToeIn", as described previously.

... All of the above is "decided", so please don't suggest an alternative ...

What I still need to decide is how to *label* the Fuzzy slider, and how to "map" it to the Guru, given that the BgnV is now 6>4 and EndV is now 2>4.
The current label of "FuzzyBandNone2Large", does not match the description above, *at all*. If you don't understand that, please re-read the description until you do.
Alternatives that "fit" in the Param pane might be:
a. FuzzyIncrs2SoftnVotEff
b. FuzzyAmp2AttenBEdiff
c. FuzVotBtufEez2BezEtuf
d. FuzzyBstrEwk2BwkEstr
... please indicate which you prefer, from best to worst


snapshot shows one example but please vote on choices ...

(CVW Guru#2 params.png)



Attachments
Attachments CVW Guru#2 params.png (179KB - 0 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 3/25/2019 10:55 AM (#9468 - in reply to #9467)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
JimDean - 3/25/2019 8:21 AM

2. Reverse the VoteGuru and relabel it to one of these:

Which options do you prefer, most to least?


My choices in order:

d. GURU_TradeBrief2Xtnd
e. GURU_WavsThin2Wide
c. GURU_VoteBrief2Wide
b. GURU_Careful2Hopeful
a. GURU_Nervous2Confid


... these are all hopefully *quite* self-explanatory, and all will "fit" in the Param label area. Other mixes of the halves can work as well, such as "WaveBrief2Xtnd" ... those examples should be enough to vote on.

Thus, as fuzzy-slider moves from 1-5, the fuzz for BgnV eval would change from big-small, and the fuzz for EndV eval would change from small-big.

Alternatives that "fit" in the Param pane might be:


... please indicate which you prefer, from best to worst:

c. FuzVotBtufEez2BezEtuf
d. FuzzyBstrEwk2BwkEstr
b. FuzzyAmp2AttenBEdiff
a. FuzzyIncrs2SoftnVotEff


Those are my choices.

Edited by KenWilsdon 3/25/2019 11:03 AM
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 11:14 AM (#9470 - in reply to #9468)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

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

I'm thinking "FuzVotBtufEez2BezEtuf" that you picked is very explanatory, but I wonder if most people will "get" the abbreviations "tuf" and "ez". If you think they will ... great. The alternative FuzzyBstrEwk2BwkEstr does not have "Vot" in it, but maaybe "wk" & "str" are clearer? Or not? I'm 50/50 on this one. Maybe also consider "VotFuzBtufEez2BezEtuf".

Re "GURU_TradeBrief2Xtnd" vs the "GURU_WavesTyt2Wide" shown on the sample ... I'm sort of skittish about two nuances. One is that "Brief" is sort of like "Fst" in the other guru, thus mushing the distinction. The other is that "Trade" implies that this isn't a "filter" ... actually, the Guru#2=5 setting is sort of intended to be filter-ish or at least market-state-ish. So I'm not pushing one or the other but rather seeking your thoughts re those nuances. Another possibility is "GURU_WavsBrief2Xtnd".

I'll likely move the Fuzz expert below the Bgn and End experts, since it "modifies" them.

This may seem like beating a dead horse, but due to the complex nature of what's going on with these inputs, I really want the labels to be as descriptive as possible, so people don't have to continually refer to Help PDF ... and so they don't get the wrong idea.

Remember too ... CVWeasy only has the Guru's with no "hints" from the Expert sliders as to how the Gurus work.
Top of the page Bottom of the page
SalimHira
Posted 3/25/2019 11:14 AM (#9469 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

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

My preferences for both questions are inversely related to Ken's... it's primarily based on my way of thinking.

a. GURU_Nervous2Confid
b. GURU_Careful2Hopeful
c. GURU_VoteBrief2Wide
d. GURU_TradeBrief2Xtnd
e. GURU_WavesTyt2Wide

and,

a. FuzzyIncrs2SoftnVotEff
b. FuzzyAmp2AttenBEdiff
c. FuzVotBtufEez2BezEtuf
d. FuzzyBstrEwk2BwkEstr

Irrespective of the above order I have chosen, it's fine with me the final order chosen... as I am still chewing on the Fuzzy (with myself), nothing of importance to post. Thanks.
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 11:18 AM (#9471 - in reply to #9469)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Thanks Salim ... interesting that you're taking the other approach ... which I'm obviously also considering, since I provided those choices too ;~)

My main concern here is what I said at the end of my response to Ken ... that is, for the CVWeasy version, the Guru's have to "stand alone" in their "apparent meaning" without hints from Expert labels.

So ... if your choices prevail, then how might you rename the Guru#1 to follow the same "flavor" ... ie conceptual-application rather than descriptive-of-calcs?
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 11:57 AM (#9472 - in reply to #9459)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Regarding the BgnV and EndV labels ...

BgnVotCmbTotSix2Four & EndVotOpposTwo2Four clearly remind the user of the votes required at each end of the sliders, and of how they are calc'd differently (Cmb vs Oppos). However, they don't remind the user of the inclusion of "Add" alternatives with BgnV, and PXit" alternatives with EndV.

So, maybe:
BgnVotNetTot6to4wAdd & EndVotOppos2to4wPXit

Here is an updated sample snapshot to consider, with sequences for gurus modified (and new slope param name too) ... (note that WarnConvert slider is scheduled for destruction)

(CVW Guru#2 params.png)



Attachments
Attachments CVW Guru#2 params.png (177KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 12:06 PM (#9473 - in reply to #9472)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Ooorrrrrr ... even more explanatory BgnV and EndV labels ...

BgnCmbVotAddMny2Fu & EndOppVotPxitFu2Mny

see snapshot ...

(CVW Guru#2 params.png)



Attachments
Attachments CVW Guru#2 params.png (163KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 12:18 PM (#9474 - in reply to #9473)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Another snap ... with Salim's FuzzyAmp2AttenBEdiff choice for Fuzzy ...



(3-25-2019 12-16-44 PM.png)



Attachments
Attachments 3-25-2019 12-16-44 PM.png (168KB - 0 downloads)
Top of the page Bottom of the page
SalimHira
Posted 3/25/2019 12:27 PM (#9475 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
I am not too sure how the "AddMny" will be reflected as ...

I know it may be as Add Money v.s. Many ... and Few / Fu or Fw ?

Edited by SalimHira 3/25/2019 12:29 PM
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 12:48 PM (#9476 - in reply to #9475)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Mny=Many. Fu=Few. Imho the abbreviations are goofy but the pair of them create a "singular" sensible interpretation. The benefit is to change the focus from specific votes (6,4,2) to the relationships and direction of change ... and to make room in the labels for "Add" and "Pxit"

Here is an alternate snap with Fw instead of Fu ... had to change Cmb to Net, to let the label fit ...

(3-25-2019 12-46-11 PM.png)



Attachments
Attachments 3-25-2019 12-46-11 PM.png (165KB - 0 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 3/25/2019 12:48 PM (#9477 - in reply to #9472)
Subject: Cumulative Volume Indicator DISCUSSION



Friend

Posts: 46
25
Location:
: ,
I'm thinking "FuzVotBtufEez2BezEtuf" that you picked is very explanatory, but I wonder if most people will "get" the abbreviations "tuf" and "ez". If you think they will ... great. The alternative FuzzyBstrEwk2BwkEstr does not have "Vot" in it, but maaybe "wk" & "str" are clearer? Or not? I'm 50/50 on this one. Maybe also consider "VotFuzBtufEez2BezEtuf".


It took me almost an hour of looking at FuzzyBstrEwk2BwkEstr on and off before I finally "got it" (which is why I put it at the bottom of my original unedited response in that post), where the other one jumped out at me almost instantly with its meaning.

One is that "Brief" is sort of like "Fst" in the other guru, thus mushing the distinction.


Since it has the word Trade in it, I think differently about its meaning rather than having slope or time frame in the name. A brief trade is conceptually clear, as is an extended trade. It is because of the word trade that it makes it easier to understand, even if other gurus also have a part in it. Yes, it can be used for filters, but that's true about a lot of things that can also be used as a stand alone system, like RSI, Stochastics, etc.

Another possibility is "GURU_WavsBrief2Xtnd".


That works well too, in my mind. It would be at the top or near the top of my list. Wave is a good alternative to trade, if that still bothers you.

This may seem like beating a dead horse, but due to the complex nature of what's going on with these inputs, I really want the labels to be as descriptive as possible, so people don't have to continually refer to Help PDF ... and so they don't get the wrong idea.


I agree. The names need to be conceptually clear for the Easy (EZ?) user.

New slope name looks good too.

Adding the Add and Pxit is fine, as it reminds people of this capability.

BgnCmbVotAddMny2Fu & EndOppVotPxitFu2Mny are both clear too.

Salim makes a good point when he says:

I know it may be as Add Money v.s. Many ...


I know you have limited room, but sometimes abbreviations can be so "cutesy" that they become difficult to read. Money could be a reading instead of many, but the concept of Adding Money still is in line with the slider, in one way.
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 1:12 PM (#9478 - in reply to #9477)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

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

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

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

snap attached ... further comments welcome!

(CVW Guru#2 params.png)



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



Friend

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

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


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

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

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


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

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


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



Owner/Admin

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

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

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

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

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



Veteran

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

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



Friend

Posts: 46
25
Location:
: ,
From Jim:

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


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

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

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


I like 2. FuzVotIncrs2DcrsBEdif

From Salim:

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

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


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



Owner/Admin

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

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

(CVW Guru#2 params.png)



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



Friend

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


Your plan seems sound, from my perspective.

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

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


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



Veteran

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

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

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

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



Owner/Admin

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


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

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

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

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

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

======

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

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

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

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

======

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

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

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

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

======

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

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



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Rearranged, Revised and Expanded ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Simple Question for y'all ...

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

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

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

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

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


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



Veteran

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

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



Friend

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

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



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Thanks for the quick responses.

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

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

HOWEVER ...

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

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



Owner/Admin

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

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

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

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

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

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

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

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

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

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

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

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

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


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



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



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



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



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



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



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



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



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



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



Friend

Posts: 46
25
Location:
: ,
Hi Jim,

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

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



Veteran

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

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

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

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

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

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

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

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



Friend

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

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

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


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


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

Yes, that is fine.

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

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

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

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



Owner/Admin

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

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

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

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

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

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



Owner/Admin

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

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

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

===========

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

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

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

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

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

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

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

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

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

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

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

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

(Vote Guru+Xprts.png)



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



Owner/Admin

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

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

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

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

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

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

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

(BgnV PopUp Help.png)



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



Owner/Admin

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


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

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

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

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

(EndV PopUp Help.png)



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



Owner/Admin

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

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

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

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

(VFuz PopUp Help.png)



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



Owner/Admin

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

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

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

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

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

(GuruV PopUp Help.png)



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



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Fixes and Cleanups done!

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

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

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

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


(CVWeval V2 Parameters.png)



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



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



Friend

Posts: 46
25
Location:
: ,
Hi Jim,

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

BgnVotNetAddMny2Fw.

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

EndVotOppPxtFw2Mny

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

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

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

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

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

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

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

VFuzzBtufEez2BezEtuf

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

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

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

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

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

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

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

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

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

1=SmlFuz for EndV seems clear.

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

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

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

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

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

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

I have 2 questions.

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

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

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



Owner/Admin

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

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

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

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

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

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

======

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

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

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

(CVWeval V2 HelpPanel-1.png)



(CVWeval V2 HelpPanel-2.png)



(CVWeval V2 HelpPanel-3.png)



(CVWeval V2 HelpPanel-4.png)



(CVWeval V2 HelpPanel-5.png)



(CVWeval V2 HelpPanel-6.png)



(CVWeval V2 HelpPanel-7.png)



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



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
Here is one suggestion as starters:

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

Thanks!

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



Owner/Admin

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


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

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

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

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

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

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



Owner/Admin

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

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

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

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

(CVWeval V2 Parameters.png)



(GuruV PopUp Help.png)



(BgnV PopUp Help.png)



(EndV PopUp Help.png)



(VFuz PopUp Help.png)



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



Friend

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

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


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

===========

Now to post 9540:

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

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

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

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

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


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

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


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

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


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


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



Owner/Admin

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

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

• Eqty calc if PltRtn req’s; pointer-chain calc
• Normalize/Share: ((XitC$-NtrC$)/NtrC$) / (NtrWTR$/NtrC$) = (XitC$-NtrC$) / NtrWTR$
• Tracking = running sum w/variable shares: %NomShrs * (Cls$-PrvCls$) / BarWTR$
... ... any time Shrs Add|Xit, adjust Eqty sum: +|- Delta%NomShrs * Cls$ / BarWTR$
• Lrs(E,X), Wma(3,Y) w/ Lrs(2,3) => 2stk+3slp, where X=8-12, Y=4-6 = f(SlowCumMA)
• Use=5-3net, f(Bgn); Kill=2-4opp, f(End)
• PltRtn Cstm override: XYUKss (ss=slider)

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



Owner/Admin

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

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

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

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

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



Friend

Posts: 46
25
Location:
: ,
Hi Jim,

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

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

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

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

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

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

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



Veteran

Posts: 175
100252525
Location:
USA: MD, Columbia
RAFT, ATQ, and RUFF in that order.

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

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



Owner/Admin

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

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

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

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

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

Summary of rearrangements from those two prior posts:

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

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



Owner/Admin

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

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

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

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

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

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


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



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



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



Owner/Admin

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

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

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

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

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

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

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

The code will assume that feed is end of day, executing after the close ... unless I can find an easy way to "read" OT's exchange-time table to get the Start and End time for that day, versus the current clock time. Gianluca suggested using AfterSessionOpen and BeforeSessionClose to derive exchange times vs System clock - not sure if that works for daily-bar feed

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

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

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

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

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

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



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Addendums to the Cut&Grab description post

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

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

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

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

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

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

Later: expanded slider to 1-6, with 5&6= 8xFG,4xPG,3.2xPC and -20%/bar

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

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

For FullCut, the Initial multiples for Slider=1,3,5 will be 80% of the FullGrab multiples ... ie a nominal 1.25 Reward/Risk. Since the timing adjustment is not as "smart" as used for the FG, PG and PC, the slider-variance is linear: 1=3.2, 2=4.0, 3=4.8, 4=5.6, 5=6.4 ... these will be locked-in by the ATR-multiplier in the TP Orders panel, for each condition. The FC model will therefore require five Conditions per Step in the TradePlan.

In each new TP Add-section (Adds drop by 20% each time), those FC Conditions will tighten, since the trade has obviously matured more, and it's smart to become more protective of the progress. There are a maximum of four Adds (if InitAdd is 80%) ... so, for each new Add, the FullCut ATR-multiples will tighten by: 1=-0.4, 2=-0.5, 3=-0.6, 4=-0.7, 5=-0.8 ... thus for the fourth Add section (which will rarely be reached), the final FullCut gap-spacing ATR-multiples will HALF of what they started: 1=1.6, 2=2.0, 3=2.4, 4=2.8, 5=3.2

Later: expanded slider to 1-6, with 1-6= 2.4x to 6.4x, @AddCut= -0.2 to -0.8

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

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

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

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



Owner/Admin

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

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

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

Only sensible input for that is BarWndo, since it isn't normally fiddled-with, and doesn't change the wave-creation logic. The input slider goes from 0-256 (def=128) ... but allow typed input:

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

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

When Long-only or Short-only used, the "Buffer" eval uses trades in both directions to find a legit, stable starting point. It's (rare but) possible that when a white-center-line shows up on left edge of Band, that some of the opposite-direction trades might appear, but they should be ignored anyways.

The slider name should reflect the additional distinction:

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



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
UPDATED version ... old post deleted ...

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

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

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

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

The "main" changes to earlier descriptions are for the BgnV (#*20% size limits & X-limit), EndV (#*10% size limits and A=req'd prev PX% req'd), and especially CutGrab, which is all-new and very powerful, using all seven possible digits. Note that the 4-line CutGrab feature is part of the "stradicator paradigm" ... that is, its logic will be echoed for all stradicators (esp since the TP is hard-coded to match it). Also part of the paradigm: GuruV, BgnV, EndV, VFuz, BarWndo, PltRtn
Top of the page Bottom of the page
JimDean
Posted 4/16/2019 11:01 AM (#9569 - in reply to #9568)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

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

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

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

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

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

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

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

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

(CVWeval V2 Parameters.png)



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



Owner/Admin

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

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

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

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

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



Friend

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

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

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


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

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

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


Sounds like a good idea.

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



Friend

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

It might be better. That is clear.

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

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


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

But I would say the danger is there, even if it is under the GuruVote slider, if people are not consciously thinking about the vote slider and the Cut Grab being related. This could happen because there are lots of moving parts to the stradicator for people to consider.
Top of the page Bottom of the page
JimDean
Posted 5/2/2019 10:15 AM (#9576 - in reply to #9575)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
see following two posts for revision & simplification (only white line; smaller buffer)

I finally figured out how to plot the thin line through the middle of the top band, to indicate when the color-state *might* be unreliable/unstable. I described this several posts ago. The core issue is that the *end* of a trade is sometimes determined by *counts* of medium and dark (warn) bars ... so, if the *beginning* of the trade is uncertain (due to output range starting in the "middle" of what would have been an already-active trade), then it follows in some situations, the *end* will not be counted correctly ... that is, the trade might appear to drag on longer than it would have, if a wider output zone had been requested.

That part, I've fixed, by adding a buffer zone to the warmup, before the formally requested output window is hit. All the calc's necessary to determine "legit" output are in place at the beginning of that buffer, but it might "start" in the middle of a wave. So, *during* the buffer zone, the code first searches for a navy-blue bar ... that is, a neutral bar not (apparently) in a wave. Once it's found that navy bar, then it continues to search, waiting for a full begin-to-end-wave to *complete* ... at which point, a "fully legit and stable" output can be expected.

If that entire search process completes successfully *within* the buffer zone, then the top fat output band has a normal appearance, from left to right.

However, if that search process is INcomplete even after the buffer zone, then a thin horizontal line is plotted in the middle of the top band, UNTIL the stabiliy-validation requirements are met:
The thin line is white until a navy bar is found
The thin line is black after the navy, until the end of a subsequent complete trade is found.

So ... if you don't see any thin center line, then all output is *definitely* stable.
If you see a black center line, then output is fully stable *after* that line disappears.
(note that it's much more likely to be stable with a black line than with a white one)

In some cases, even though there is a thin center line, it doesn't *necessarily* mean that the output is incorrect. It's sort of like a "take this with a grain of salt" situation.

The first snapshot below illustrates the appearance of this ... NOTE that to create this, I reduced the hard-coded "buffer zone" to just one bar, so that *both* the white and black lines would appear.

The second snapshot shows the same 3-mo window, but with the hard-coded buffer set to 10 bars ... enough so that the navy was found before the requested output window, but not enough for a full trade to complete within the buffer zone (so the black line extends into the output window).

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

The final snapshot shows the 6-mo view (w/40-bar buffer) ... this helps clarify what was going on during the 1/10/40-bar buffer zone in the prior examples.

QUESTION - is this explanation, and the output-formatting understandable?

(ThinCenter,buf1.png)



(ThinCenter,buf10.png)



(ThinCenter,buf40.png)



(ThinCenter,buf40,6mo.png)



Attachments
Attachments ThinCenter,buf1.png (17KB - 0 downloads)
Attachments ThinCenter,buf10.png (17KB - 0 downloads)
Attachments ThinCenter,buf40.png (17KB - 0 downloads)
Attachments ThinCenter,buf40,6mo.png (18KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/2/2019 11:10 AM (#9577 - in reply to #9576)
Subject: Cumulative Volume Indicator DISCUSSION



Owner/Admin

Posts: 3798
20001000500100100252525
Location:
USA: GA, Lawrenceville
Followup to prior post ... please read it first, or this one won't make sense ...

Reasons why doing this is important:

1. Entry/exit signals might not be stable otherwise (as time moves forward)
2. Cut/Grab bands (not yet programmed) might be unstable due to shifting entry & counts
3. Equity calc's and equity filtering (OScans and trade-toggle) similarly might be unstable

Therefore, Equity calcs, will *only* evaluate complete, stable, no-centerline wave-trades. The Cut/Grab bands will *only* show up for those trades ... not for waves with centerlines.

Why I picked 60 bars (example=40 in prev post) as the default buffer:

1. gut feel ... approx three months worth ~max extra warmup penalty I could stomach
2. it made the black lines disappear in a series of test cases (though I didn't do a zillion)
3. no matter what I pick, there will be *some* cases that create a centerline

Note that this extra buffer-warmup will somewhat penalize the speed of calcs for backtesting and FL output, which really only "needs" one bar at a time. But the history leading up to that bar is a big part of what determines that bar's state.

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

Top of the page Bottom of the page
SalimHira
Posted 5/2/2019 2:45 PM (#9578 - in reply to #9178)
Subject: Cumulative Volume Indicator DISCUSSION



Veteran

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

You said:

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

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

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

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

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

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

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

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

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



Owner/Admin

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

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

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

Thus far, I have two ways of finding that:

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

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

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

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

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

What ends a wave?

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

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

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

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

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

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

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

Later note ...

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



Owner/Admin

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

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

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

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

========

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

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

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

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

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

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

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

------

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

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

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

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

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

==========

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

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

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

==========

OK ... I think that solves it.

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

Benefits:

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

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

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

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

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

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

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


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



Owner/Admin

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

The attached snap shows the updated parameter pane:

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

Notes:

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

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

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

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

Comments?

(Params renamed & rearranged.png)



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



Owner/Admin

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

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

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

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

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

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

=======

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

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

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

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

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

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


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

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

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



Owner/Admin

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

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

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

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

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

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

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


(Comments Snapshot from 5P.png)



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



Owner/Admin

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

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

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

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

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

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

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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


(CVWeval V2 Parameters.png)



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



Owner/Admin

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

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

=========

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

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

So, the question that remains is:

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

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

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

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

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

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

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

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

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

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

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

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

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



Veteran

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

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

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

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


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

(New Toe & Confirm Colors, annotated.png)



(New Toe & Confirm Colors.png)



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



Veteran

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

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

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

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

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

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



Owner/Admin

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

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



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



Owner/Admin

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

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

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

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

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

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

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


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

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

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

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

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



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



Owner/Admin

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

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

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

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

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

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

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

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

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

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

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

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

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

I'm modifying the prior crib sheet post accordingly.

The BgnVot override for the Cstm user had been "TFV" (Toe size, Full size, and reqd BgnVote), so there are 4 more characters available. These will specify the order type, AND, for MOC (aka BOC), will specify how much time before the end of the bar needs to be reserved for calculations: "TFVMm", where "Mm" specifies the number of minutes before the Close of the bar that MOC orders need for calculation and submission. Note that