Search | User Listing Vidsite | Calendars | Quotes
Home Page ->  Custom TradeTight Routines -> Tools In Team Development -> View ThreadLogon (or Register, or Join TradeTight)

You are logged in as a limited-access Guest.To join TradeTight, first read the info in the Organization & Content room, then click the link above. 

Psalm 127:1 (NKJV) ... Unless the Lord builds the house, they labor in vain who build it; Unless the Lord guards the city, the watchman stays awake in vain.


CVW Archived Devel Discussion
Frozen
Jump to page : 1 2 3 4 5
Now viewing page 2 [50 msgs/pg]
Jump to room :
JimDean
Posted 2/19/2019 1:40 PM (#9361 - in reply to #9356)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Friend

Posts: 45
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel 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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel 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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Friend

Posts: 45
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: CVW Archived Devel Discussion



Friend

Posts: 45
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: CVW Archived Devel Discussion



Friend

Posts: 45
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Friend

Posts: 45
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Friend

Posts: 45
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Friend

Posts: 45
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Friend

Posts: 45
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel 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: CVW Archived Devel Discussion



Friend

Posts: 45
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Friend

Posts: 45
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: CVW Archived Devel 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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Friend

Posts: 45
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel 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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Friend

Posts: 45
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel 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: CVW Archived Devel Discussion



Friend

Posts: 45
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: CVW Archived Devel Discussion



Owner/Admin

Posts: 3835
2000100050010010010025
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: CVW Archived Devel Discussion



Friend

Posts: 45
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
Jump to page : 1 2 3 4 5
Now viewing page 2 [50 msgs/pg]
( E-mail a Link | Printer Version | Search Room )
Frozen

Owner of site: Jim Dean -- Forum content is confidential, and may not be distributed without written permission.