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. 

2 Cor 9:8 (NET) ... And God is able to make all grace overflow to you so that because you have enough of everything in every way at all times, you will overflow in every good work.


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



Owner/Admin

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

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

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

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

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

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

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

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

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

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



Friend

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

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

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

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

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


Hi Jim,

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

Top of the page Bottom of the page
SalimHira
Posted 3/19/2019 2:02 PM (#9449 - in reply to #9178)
Subject: CVW Archived Devel Discussion



Veteran

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

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

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



Owner/Admin

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

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

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

Top of the page Bottom of the page
JimDean
Posted 3/19/2019 3:00 PM (#9451 - in reply to #9450)
Subject: CVW Archived Devel Discussion



Owner/Admin

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

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

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

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

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

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

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

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

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

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


(CVW A2 Alerts Example.png)



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



Friend

Posts: 47
25
Location:
: ,
Hi Jim

This is great news!

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

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

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



Owner/Admin

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

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

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

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

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

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

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



Owner/Admin

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

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

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



Owner/Admin

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

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

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



Owner/Admin

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

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

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

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


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


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


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


Comments:

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

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

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

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

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



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Need your comments about this ...

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

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

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

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



Owner/Admin

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

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

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

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

OR ...

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

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



Owner/Admin

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

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

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

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

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

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

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



Veteran

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

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

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

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

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

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

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



Friend

Posts: 47
25
Location:
: ,
Hi Jim,

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

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

On the second question, your statements:

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

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

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



Top of the page Bottom of the page
JimDean
Posted 3/25/2019 10:21 AM (#9467 - in reply to #9459)
Subject: CVW Archived Devel Discussion



Owner/Admin

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

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

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

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

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

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

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

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

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


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

(CVW Guru#2 params.png)



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



Friend

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

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

Which options do you prefer, most to least?


My choices in order:

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


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

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

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


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

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


Those are my choices.

Edited by KenWilsdon 3/25/2019 11:03 AM
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 11:14 AM (#9470 - in reply to #9468)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Thanks, Ken

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

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

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

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

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



Veteran

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

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

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

and,

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

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



Owner/Admin

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

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

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



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Regarding the BgnV and EndV labels ...

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

So, maybe:
BgnVotNetTot6to4wAdd & EndVotOppos2to4wPXit

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

(CVW Guru#2 params.png)



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



Owner/Admin

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

BgnCmbVotAddMny2Fu & EndOppVotPxitFu2Mny

see snapshot ...

(CVW Guru#2 params.png)



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



Owner/Admin

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



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



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



Veteran

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

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

Edited by SalimHira 3/25/2019 12:29 PM
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 12:48 PM (#9476 - in reply to #9475)
Subject: CVW Archived Devel Discussion



Owner/Admin

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

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

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



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



Friend

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


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

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


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

Another possibility is "GURU_WavsBrief2Xtnd".


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

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


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

New slope name looks good too.

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

BgnCmbVotAddMny2Fu & EndOppVotPxitFu2Mny are both clear too.

Salim makes a good point when he says:

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


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



Owner/Admin

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

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

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

snap attached ... further comments welcome!

(CVW Guru#2 params.png)



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



Friend

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

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


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

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

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


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

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


I like GURU_WavesSml2Larg. Conceptually clear.
Top of the page Bottom of the page
JimDean
Posted 3/25/2019 1:55 PM (#9480 - in reply to #9479)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Ken:

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

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

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

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



Veteran

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

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



Friend

Posts: 47
25
Location:
: ,
From Jim:

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


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

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

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


I like 2. FuzVotIncrs2DcrsBEdif

From Salim:

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

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


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



Owner/Admin

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

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

(CVW Guru#2 params.png)



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



Friend

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


Your plan seems sound, from my perspective.

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

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


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



Veteran

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

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

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

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



Owner/Admin

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


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

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

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

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

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

======

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

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

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

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

======

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

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

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

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

======

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

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



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Rearranged, Revised and Expanded ...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Simple Question for y'all ...

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

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

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

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

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


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



Veteran

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

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



Friend

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

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



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Thanks for the quick responses.

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

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

HOWEVER ...

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

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



Owner/Admin

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

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

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

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

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

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

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

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

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

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

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

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

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


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



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



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



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



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



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



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



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



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



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



Friend

Posts: 47
25
Location:
: ,
Hi Jim,

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

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



Veteran

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

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

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

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

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

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

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

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



Friend

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

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

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


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


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

Yes, that is fine.

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

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

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

Yes, This is fine.
Top of the page Bottom of the page
JimDean
Posted 3/29/2019 12:30 PM (#9502 - in reply to #9501)
Subject: CVW Archived Devel Discussion



Owner/Admin

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

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

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

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

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

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



Owner/Admin

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

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

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

===========

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

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

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

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

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

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

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

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

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

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

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

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

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



Owner/Admin

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

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

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

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

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

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

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

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

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

(Vote Guru+Xprts.png)



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



Owner/Admin

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

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

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

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

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

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

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

(BgnV PopUp Help.png)



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



Owner/Admin

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


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

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

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

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

(EndV PopUp Help.png)



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



Owner/Admin

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

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

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

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

(VFuz PopUp Help.png)



Attachments
Attachments VFuz PopUp Help.png (81KB - 0 downloads)
Top of the page Bottom of the page
Jump to page : 1 2 3 4 5
Now viewing page 3 [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.