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. 

1 Tim 6:18-19 (ESV) … (the rich) are to do good, to be rich in good works, to be generous and ready to share, thus storing up treasure for themselves as a good foundation for the future, so that they may take hold of that which is truly life.


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



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Alll-riiiight! I completed my planned tasks for the day (an uncommon situation for me). This is the last of the four Help descriptions. Please be sure to review each of the other three in separate posts.

This GuruV param controls the prior three Expert param's in the Easy version ... but the popup Help explains the Experts anyways, since even though the user doesn't have access to them, their impacts are complex and deserve explanation. Also, the "Actual Inputs & Derivatives" popup section will show their defaulted values and related internal values, just as it does for Xprt|Cstm.

As you read this, remember that the specifics are given in the three Expert explanations ... the purpose here is a general guide as to how to use the GuruV, and how it impacts the output. Snapshot attached.

GuruV_WavesSml2Lrg -5>+5: maps directly to -5>+5 of BgnV, EndV & VFuz
... inputs (Xprt+Cstm)- see below. +1>+5 uses Add&PXit Siz%'s to scale
... in/out, maybe forcing FullX when net%=0; also uses Toe+Cnfrm Entries,
.. -1>-5 uses simple FullEntry & FullExit w/o Add/PXit Size-adj's. General:
... +/- 1>5 creates Timid-to-Aggressive 'Trade-Waves' (filters: use +/-4,5).

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

(GuruV PopUp Help.png)



Attachments
Attachments GuruV PopUp Help.png (74KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 3/31/2019 2:51 AM (#9523 - in reply to #9521)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Fixes and Cleanups done!

In addition to the fixes, I also modified some other things. The BgnV +5 changes from 40 to 60%. Several tweaks to the EndV mapping, for reasons to complex to write out (compare snap to blue for diff’s, until I update snaps). Generally, using the Timid>Confident concept from 1>5, following the (unchanged) EndV’s of 2,2,3,3,4 - I prioritized the “sequence” of MW’s higher than the Pcts, since when VFuz|GuruV is neg, the Pcts have no effect but the MW’s do. Also I used the idea that neg EndV range should be “faster” to exit than the pos-range counterparts (re MW’s). Finally, I made sure that when the EndV vote-spec didn’t change (2,2 or 3,3) - the MW’s did, to create a functional distinction.

The neg side of GuruV is supposed to be for “simpler trades” (since neg VFuz turns off Sz% calcs and neg BgnV turns off Toe) - so it seems that when -2 EndV is GuruV-paired with -2 BgnV, the PXit should “quickly” kill the Add … while the paired -4 settings (20% & “44” PX w/ 40% Add) should kill it off more slowly.

The Easy version has full -5>+5 range for both Gurus, and full -6>+6 range for CumMeth … ie 1200 permutations. This will be simpler to code and explain than limiting the Easy sliders to pos values … also I’m guessing that negative slider values might work a bit better as filters than the positives do (we’ll see).

Finally ... I updated the Band colors used for the "same-vote-as-prior-bar" case ... much clearer distinctions now, making it easier to quickly see the bright and medium cases. Also, I got all the inputs and section headers rearranged, with several name-changes ... snapshots attached:


(CVWeval V2 Parameters.png)



(Sample Using Defaults - ALXN - new SameVote colors.png)



Attachments
Attachments CVWeval V2 Parameters.png (174KB - 0 downloads)
Attachments Sample Using Defaults - ALXN - new SameVote colors.png (22KB - 0 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 3/31/2019 9:50 AM (#9521 - in reply to #9178)
Subject: CVW Archived Devel Discussion



Friend

Posts: 47
25
Location:
: ,
Hi Jim,

You asked if the CSTM section is clear, to take a second look. I will go over them one by one. I will answer as you initially suggested, after about a month or so after a new user has "supposedly" viewed the video and read the pdf.

BgnVotNetAddMny2Fw.

To me, this is clear, and after having viewed a video (and perhaps taken notes), I would remember what these values and shorthand represent.

EndVotOppPxtFw2Mny

The only thing that "might" be confusing here is this line:

... CnvrtThrsh M=Med2Wrn, W=Wrn2FullX (Bright:Cnt=-1,Wrn:MedCnt/2).

I have worked with you a "lot" and I still get confuse with the last part of this, the section with (Bright:Cnt=-1,Wrn:MedCnt/2).

The reason I get confused is (1) I have not written this code; and (2) the whole concept is difficult to explain, even in one paragraph. To me, this is one of the more difficult sections/parameters to get my head around conceptually, because this is doing a "lot", and I think I am fairly good at concepts. This is something the video should focus on, looking at charts and the slider, especially for CSTM users.

If I look at it like someone who saw a video a month ago, I might think that I can put a -1 for M or W, since that is what comes before, in order to get a full exit. Then I see Wrn:MedCnt/2, and that would say to me, take the MedCnt ("M"), divide by 2, and that would be a Warn. So that is what I would input. That's how "I" would interpret it after a month.

You're right that this is sort of messy ... normally I'd not include the latter half of that line in Help, since it's internal logic. But I think some users will want to "check" it ... and if they are providing a Cstm override of M &/or W, they probably should understand this. But writing it out fully would take up too much space.
The intent was to convey that for either "count" (Med or Wrn), when a Bright bar appears, it *reduces the count by 1* (never less than 0). And, when a Warn bar appears, the Med count is reset (up or down) to Med2Wrn/2 ... that is, a Warn "primes the pump" so that fewer subsequent Med's are needed to create another Warn.
Upon checking the code, I decided to tweak it a bit. For the MedCnt reset to half, I'm rounding-down ... ie if Med2Wrn input=3, the reset goes to 1, not 2 ... this assures there will be at least one Med between successive Warns, unless the Med2Wrn input spec=2 (not true for any defaults).
Re the WrnCnt decrement by 1, it already is limited to never be less than Wrn2FX/2 (rounded down).
I'm adding another restriction ... the decrement does not happen unless that Bright bar has a strong enough vote to pass the BgnVote threshold ... reason: I don't want to allow lots of Warns without creating FullX's, unless the Wave has a strong recovery from the Warn-pullback.
Here's my revised help-text for that (adds another line):

... *CSTMver* TypedIn VPMW: V=EndV; P=PXitSize as #10%s if VFuz>0;
... Cnvrt: M=Med2Wrn, W=Wrn2FullX. Bright decrem's MedCnt; Dark sets=
... Med2Wrn/2. WrnCnt decrem's if NetVot>=BgnVot, but not < Wrn2FX/2.

VFuzzBtufEez2BezEtuf

The first line is great. No problems with +/- 1 to 5

Not sure if I commented on this before. May have been out. Will comment now.

... neg=NoFXfrom%SzCalc. Vote=0 if ChkVal<FuzLim: 1=BigFuz for BgnV,

The first half, with the neg=, clearly reminds me that this slider controls full exits. That should be sufficient.

The part, Vote=0 if ChkVal<FuzLim is not clear to me; I don't remember what ChkVal is, nor FuzLim. Don't remember seeing it in prior help screens. Must be internal parameters in the code to this section. If you are going to put it in the help panel, should go over it in the video and/or pdf.

I tried to generalize what's going on in the code. There are 8 different baseline averages calc'd, specific to each "ChkVal" (ie 3 slopes, 3 Stacks, and 2 for CurBar) ... the FuzPct is applied sep to each baseline, to create a "FuzLim" for each baseline. If the ChkVal (ie a slope or a stack-diff, etc) is within that FuzLim band, then the Vote for that category is zero for that bar.
The simple "Vote=0 if ChkVal<FuzLim" correctly states that, but presumes the reader can figure out what ChkVal and FuzLim are.
Here's my revised help-text for that (adds another line):

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

The last part, 1=BigFuz for BgnV seems clear to me, and should be after seeing a video a month before.

... 1=SmlFuz for EndV. 1-5 Fuz%/10 for BgnV/EndV= 5/2,4/3,none,3/4,2/5;

1=SmlFuz for EndV seems clear.

as does 1-5 Fuz%/10 for BgnV/EndV.

It is after that when we have the divide sign that things start to get confusing (appropriate for "Fuzz", as it may affect the brain too). If I saw a video a month ago, I would not necessarily remember that BgnV/EndV= 5/2,4/3,none,3/4,2/5; means 5 BgnV and 2 EndV, etc. (although that is logical from the BgnV/EndV before it, and should be clear from the descriptions of BigFuz and SmlFuz for BgnV and EndV), and "none" in the middle would confuse me to think no BgnV and no EndV (i.e, no fuzz at all). I "MAY' think this is a division process (like Wrn:MedCnt/2 above). Then 5/2, 4/3, 3/4, and 2/5 would be confusing if I went this route. Not sure how to make it clearer to the user, other than a video and pdf that clarifies this. Again, this Fuz does a lot, and it inversely affects BgnV and EndV, so it is not conceptually easy, until you understand it better. This is a section of the video that users may have to repeat until they "get it".

... '3'=30%. @Vote-metric uses a dif historical avg to which Fuz% is applied.

This seems clear. It actually might help some to understand the preceding, a bit. They still may have to chew over the preceding for a while to "get it".

The '3'=30% should have cleared this up ... the long writeup you did re 5/2 etc format was totally offbase. Hopefully the revised format above, which expands it to "50/20, 40/30, ..." clarifies it ... note that I *very commonly* use a convention where I'll say something like "Long/Short = X/Y", which is (usually) shorthand for "Long=X and Short=Y". That's what I did here with BgnV/EndV, to avoid repetition of the BgnV= and EndV= pair, five times. I hope the revision is sufficiently clear.

... *CSTMver* TypedIn BbEeHhh: Bb=Bgn%, Ee=End%, Hhh=HistAvgPds

I have 2 questions.

(1) Why here, is the entry 2 digits, when you say above ... 1=SmlFuz for EndV. 1-5 Fuz%/10? Is this so the user can input the actual %, instead of the %/10? The actual values they are to input for BbEe are not confusing, just seems a little inconsistent with what was said earlier. You may not need to change it, but I noticed it and thought I should point it out.
Hopefully the revision cleared this up, by removing the Fuz%/10 that had been intended to apply only to that one sentence.

(2) Hhh=HistAvgPds. Does this mean the user could (theoretically) enter "999", if that "fills their boots" as an experiment, if they load that much data for a security? And that they can use over 100%? (It's OK if that capability is here, just asking).
All overrides for all inputs are "range-checked" to block spec's that are either utterly absurd, or that the code can't handle. In this case, the Hhh periods override allows a range of 20-200. If input is outside that range, it substitutes the "edge" value and drives on. You can see the value that is actually used in the popup panel.

OK. That's my review of the Cstm and Fuz sections.
Top of the page Bottom of the page
JimDean
Posted 3/31/2019 12:07 PM (#9530 - in reply to #9178)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Re Help Panels in general ... re-posted, with lots of snaps - please respond to Q at end

After doing that expansion for the GuruV section, I think that I'm going to take a different path than I've discussed earlier.

In my opinion, that set of four writeups is about as comprehensive as I want to be in writing - although I could create an expanded PDF version of that, it would take a *long* time and I doubt many would read it all - or refer back to it.

Instead, I will go back to my earlier plan of providing all *written* explanations in Help panels ... I'll expand each of the other input param's similarly to how I handled these four ... probably one Popup panel for each of the four "sections" ... the first 2-line section's panel will list and briefly explain all the CumV methods, and will provide an appropriate "table" related to the canned Master selections. The final output section will include concise explanations of the various plots and colors, plus a table that lays out what all the Return options are ... this will likely require two panels.

I'll update and expand the "Actual Inputs and Derivatives" panel ... it will become Panel #1 ... and it will include a few sentences to "outline" the rest of the Help Panels. The Copy-OScript-String panel will be #2, and the ~5 explanation-panels will complete the set.

I will simply copy/paste those panels (zoomed for readability) into a PDF *without adding more detail*, other than a snap of the Input Params and sample snaps of the various plot options.

======

In addition to that PDF-reprint of the HelpPanels, I'll create a few training videos. And of course in addition to that, there will be a few threads dedicated to Q/A, etc for CVW. I think that should do it ... it's arguably more than Nirvana provides.

The snaps below come from a quick restructuring of the code ... obviously many of them need to be fleshed out. But the *idea* should be clear ...

Is this plan a good one, or is more needed? NOW is the last chance to opine about this!

(CVWeval V2 HelpPanel-1.png)



(CVWeval V2 HelpPanel-2.png)



(CVWeval V2 HelpPanel-3.png)



(CVWeval V2 HelpPanel-4.png)



(CVWeval V2 HelpPanel-5.png)



(CVWeval V2 HelpPanel-6.png)



(CVWeval V2 HelpPanel-7.png)



Attachments
Attachments CVWeval V2 HelpPanel-1.png (266KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-2.png (294KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-3.png (138KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-4.png (98KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-5.png (407KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-6.png (71KB - 0 downloads)
Attachments CVWeval V2 HelpPanel-7.png (48KB - 0 downloads)
Top of the page Bottom of the page
SalimHira
Posted 3/31/2019 3:04 PM (#9534 - in reply to #9178)
Subject: CVW Archived Devel Discussion



Veteran

Posts: 176
100252525
Location:
USA: MD, Columbia
Here is one suggestion as starters:

1). CVW Help panels - includes all the relative information needed based of the parameters on need basis, and other important information

2). PDFs - includes all the technical stuff, and detailed reference points - primarily copy/paste content of what you have from the T.T. forum posts to date.

3). Video(s) - a general overview, usage, etc.

4). TT forum - Q/A, examples, user-feedback, etc.

5). etc...
Top of the page Bottom of the page
JimDean
Posted 3/31/2019 3:39 PM (#9536 - in reply to #9534)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Thanks, Salim ... that's very helpful!

It appears that what I described initially is what you are saying, BUT you are suggesting in #2 that the PDF should be continually updated as more posts are added to the forum which might have broadly-useful info.

That is, when I take the time to answer a Q in the forum, if it's a useful Q, then you're suggesting that *when* I answer the Q, I *add* that answer (incl graphics if any) to the PDF (which is attached to a "locked" post in the Distribution thread).

Presumably whenever I did that, I'd include a note in the Answer post re the update, with a link to the standard place where the PDF is.

Since I don't want to rewrite/restructure the PDF each time, I'd probably just add the new info to the next PDF page ... maybe I could add a one-liner to a Table of Contents for each new entry.

That's a very practical idea! And, it's a meaningful "selling point".
I could employ this method for all Stradicators ... and the amount of extra effort it would take to add to the PDF "on the run" would probably avg at about 15 min / entry ... of course answering the original Q might take anywhere from 15 min to an hour or more ;-)

Thanks!

Top of the page Bottom of the page
JimDean
Posted 4/1/2019 7:46 AM (#9539 - in reply to #9530)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Ken ... please note that HP#1 needs a LOT of "cleanup", as stated on its final line in all-caps ;~)
Salim ... if you're volunteering to help manage the PDF updates, thanks! I'll discuss later w/you.


Now ... "Back to the Fuzzy" ...

I discovered a huge issue yesterday with the proposed "BtufEez2BezEtuf" fuzzy-change ... it messes up virtually *all* of the outputs, and requires a *lot* of new calc's. So, I scrapped it ... Ken & I discussed on phone and came up with a good alternative that utilizes the original Fuzzy "Small2Large" slider approach ... but it had some weaknesses. Further thinking last night and this morning solved all that. The notes below retain the planned Easy/Xprt/Cstm input-combo's, but redefine the meanings of neg vs pos for GuruV & Fuzz, and "empower" the dots/nodots PltRtn variants. I'm pretty happy with it ... but maybe I'm missing something. Please read carefully, and comment.

1. Keep -5 > +5 Vote Guru … neg Guru= noTAP (Toe,Add,PX all off, using pos BgnV+EndV maps) ... Guru uses locked-in Fuzz (Fuz only variable via Xprt slider), and has no access to -BgnV or -EndV options. So, Easy version can't access any (arbitrary) fuzz-tweaking, and some (secondary) Add/PX/MW variants. (Easy has -6>+6 and 2*(-5>+5) = 1200 patterns.)

2. Fuzzy expert Slider = small to large, but label to imply slide-left + choppy vs slide-right + continuous ... mirror neg & pos 1-5 fuzz %'s. Neg fuzz input turns off Adds & PXits, but retains MW cnts & Toe|Full, and small diff's for +/-PX MW.

3. Toggle Size% calc's that impact final-exit as well as equity calcs, via the PltRtn slider ... pairs of Plots: A) FullXit w/no Adds/PXits shows just (Toe/)Ntr/FXit dots (allows Toe+Cnfm since easy for TP) ... VERSUS ... B) those 3 dot-types plus Add/PXit dots *with* extra FX-rule related to NetSize calc's. Total of nine plot options (no dots w/internals chart) ... and about 2-4 of the Return options will have to double-up.

4. Easy-version GuruV neg with PlotA toggles Toe off, and GuruV neg makes PlotB the *same* as with PlotA. Xprt-version GuruV neg BUT with Fuzz-slider positive *allows* Add+PXit, since Xprts override Gurus ... similarly, neg GuruV with BgnV-slider positive *allows* Toe (indep of fuzz slider re Add/PXit). SO: versatile permutations ... but popup help probably should provide a simple lookup table showing which combos of GuruV, BgnV, VFuz, PltRtn make each of the Toe|Add|PXit|Size% features active, and which don't. (note that BgnV= -1,-3,-5 turn off Adds w/o affecting PX's).
Top of the page Bottom of the page
JimDean
Posted 4/1/2019 9:41 AM (#9540 - in reply to #9539)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
I've modified the Help for the four Vote param's ... major changes for GuruV and VFuz (also note NAME CHANGE for VFuz). Minor tweaks for BgnV & EndV ... so far. I need to re-think EndV's neg Pct's and neg MW's in light of the various "toggle" effects of the revised VFuz and GuruV logic.

PLEASE chew this over, in light of the prior post's changes (see updated Help, below):
There *may seem to be* a logical conflict if GuruV is negative, which defaults to *no* Toe|Add|PX ... but also the BgnV slider is >0 (meaning Adds are active) ... and EndV slider=0 ... that would leave PXits turned off (default state from neg GuruV), with Adds & Toe+Cnfrm active (due to BgnV override of GuruV). The "Add rule" requires a PXit to have occured before any Add can be done ... so in actuality, the "potential" Adds that this situation "seems" to allow will *never* take place, since PXits are turned off. Thats *good* ... but it's a nuance that the user might be confused by at first.
Similarly, if neg GuruV defaulting plus EndV slider <> 0, then the EndV slider overrides the Guru and PXits *are* allowed (though Adds & Toe+Cnfrm still aren't, as long as the BgnV slider=0). Again, that's *just fine* ... no worries about using PXits with no Adds ... but user needs to understand.
Furthermore, if the PltRtn (final param) setting is in the "no Adds|PXits" setting, then *it* has the *final veto* ... regardless of GuruV or its experts, if PltRtn *dis*allows Adds&PXits, then they will *not* be implemented (although of course the MW counts that influence the final exit still are in play).

>> I mentioned in the prior post that Help would include a "Scaling Table" which shows, for various "states" of GuruV+/-, BgnV+/0/-, EndV+/0/-, VFuz+/0/-, PltRtn on/off (13 table-rows) ... whether T&C, Adds, PXits, &/or Size%FullX are "active" (ie four columns). I think (hope) that table will totally clarify the interactions, AND illustrate just how *powerful & versatile* the input-combinations are.<<

I'm attaching the four updated Help snapshots, along with the renamed Param's snap ... PLEASE REVIEW these with a fine-toothed comb. Thanks!

(CVWeval V2 Parameters.png)



(GuruV PopUp Help.png)



(BgnV PopUp Help.png)



(EndV PopUp Help.png)



(VFuz PopUp Help.png)



Attachments
Attachments CVWeval V2 Parameters.png (174KB - 0 downloads)
Attachments GuruV PopUp Help.png (153KB - 0 downloads)
Attachments BgnV PopUp Help.png (251KB - 0 downloads)
Attachments EndV PopUp Help.png (285KB - 0 downloads)
Attachments VFuz PopUp Help.png (125KB - 0 downloads)
Top of the page Bottom of the page
KenWilsdon
Posted 4/1/2019 12:50 PM (#9542 - in reply to #9540)
Subject: CVW Archived Devel Discussion



Friend

Posts: 47
25
Location:
: ,
From Jim's post 9539:

4. Easy-version GuruV neg with PlotA toggles Toe off, and GuruV neg makes PlotB the *same* as with PlotA. Xprt-version GuruV neg BUT with Fuzz-slider positive *allows* Add+PXit, since Xprts override Gurus ... similarly, neg GuruV with BgnV-slider positive *allows* Toe (indep of fuzz slider re Add/PXit). SO: versatile permutations ... but popup help probably should provide a simple lookup table showing which combos of GuruV, BgnV, VFuz, PltRtn make each of the Toe|Add|PXit|Size% features active, and which don't. (note that BgnV= -1,-3,-5 turn off Adds w/o affecting PX's).


Jim: It would be helpful to have that lookup table (Perhaps created in a Word table so everything lines up properly and evenly for those with OCD ;-) on a separate page in the pdf, so that people would be able to print that out.

===========

Now to post 9540:

I've modified the Help for the four Vote param's ... major changes for GuruV and VFuz (also note NAME CHANGE for VFuz).

VFuzzNgNoAPXoff2Big Name is good, once you figure out what it is saying.

Here is an idea. Perhaps also in the pdf, put a glossary at the back, translating things like VFuzzNgNoAPXoff2Big into "real English", something like "VFuzzNgNoAPXoff2Big is the Fuzzy vote slider [Vfuzz] that if negative [Ng] provides for no [No] Adds [A] or Partial Exits [PX] by turning them [off]. Values go from small to [2] big in size." This glossary should not use abbreviations to explain abbreviations, but would be most helpful in the plain English format, similar to the above. The documentation in Nirvana products is minimal (less than above often), with many times no idea what effects moving sliders on Nirvana products actually does.

This would also preempt those who would complain about the abbreviations, as there would be a glossary (which they also could print out, if needed), which explains in simple English what it does and what it means. Also, with a plain English glossary, they will find it easier to understand other abbreviations used that may not make it into the glossary. Then if on the TT forum, people have questions about what something means, it could be added to the Glossary fairly easily, and updated. Those not asked about would be assumed to be understood.

PLEASE chew this over, in light of the prior post's changes (see updated Help, below):
There's a logical conflict if GuruV is negative, which defaults to *no* Toe|Add|PX ... but also the BgnV slider is >0 (meaning Adds are active) ... and EndV slider=0 ... that would leave PXits turned off (default state from neg GuruV), with Adds & Toe+Cnfrm active (due to BgnV override of GuruV). The "Add rule" requires a PXit to have occured before any Add can be done ... so in actuality, the "potential" Adds that this situation "seems" to allow will *never* take place, since PXits are turned off. Thats *good* ... but it's a nuance that the user might be confused by at first.
Similarly, if neg GuruV defaulting plus EndV slider <> 0, then the EndV slider overrides the Guru and PXits *are* allowed (though Adds & Toe+Cnfrm still aren't, as long as the BgnV slider=0). Again, that's *just fine* ... no worries about using PXits with no Adds ... but user needs to understand.
Furthermore, if the PltRtn (final param) setting is in the "no Adds|PXits" setting, then *it* has the *final say* ... regardless of GuruV or its experts, if PltRtn disallows Adds&PXits, then they will *not* be implemented (although of course the MW counts that influence the final exit still are in play).


The table (discussed below) is a great way to show what ACTUALLY happens, maybe with a footnote or two below the table explaining why (even your explanations above could be used).

>> I mentioned in the prior post that Help would include a "Scaling Table" which shows, for various "states" of GuruV+/-, BgnV+/0/-, EndV+/0/-, VFuz+/0/-, PltRtn on/off (13 table-rows) ... whether T&C, Adds, PXits, &/or Size%FullX are "active" (ie four columns). I think (hope) that table will totally clarify the interactions, AND illustrate just how *powerful & versatile* the input-combinations are.<<


This table will indeed show how powerful and versatile the combinations are. Again, this should have a separate page in the pdf, so people can print it out if they want to.

b]I'm attaching the four updated Help snapshots, along with the renamed Param's snap ... PLEASE REVIEW these with a fine-toothed comb. Thanks!


I reviewed them (twice). I think this is a good set of Help panels, as is. I did not see anything way too confusing or contradictory.


Edited by KenWilsdon 4/1/2019 12:51 PM
Top of the page Bottom of the page
JimDean
Posted 4/1/2019 1:09 PM (#9543 - in reply to #9542)
Subject: CVW Archived Devel Discussion



Owner/Admin

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

I agree 100% re the importance of a clearly-understandable Table w/footnotes and a few examples to boot.
I can see that a glossary would be nice too ... but of secondary priority.

Re: VFuzzNgNoAPXoff2Big ... you copied it incorrectly ... should be VFuzzNgNoAPxOff2Big ... parses as: VFuzz: Neg=No-Add|Px; Off2Big. That is, Off2Big is what 1-5 choose between, and if the input is negative, then no Adds or PXits are allowed (regardless of what BgnV or EndV might imply).

You understood it properly ... just got lower & upper case flipped.

I could change it to: VFuzzNgNoAPxSml2Big, but since input 1= 0% fuzz, "off" is more descriptive.

Top of the page Bottom of the page
JimDean
Posted 4/1/2019 4:50 PM (#9544 - in reply to #9543)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Updated collection of thoughts, mostly re Equity analysis calc's/output, but other stuff also ...

• SBAS Master 1-33= best of 12*10*10=1200; 11/11/11 = Filter/Trend/Swing (Slow>Fst)
• CumMeth: -6>+6 for all versions
• for SBAS tests, skip -6,-3,+3,+6 CumMeth; skip +/-1,5 on Guru’s => 8*6*6=288 tests
• if GuruX 2 ~better than GuruX 4, and if GuruY 4 ~better than GuruY 2, need more tests
• Second set of (same-procedure) tests = 8*(10+10)=160 more
• => Max= 448 total SBAS tests (all the same re columns and test-types)

• neg MAspd: use wider spread = slower, just as neg MAtyp is slower and neg MAslp is slower
... ... so, maybe that neg MAspd (and negGuruT) range will be good for filters or long term trades

• GuruV= negative disallows any Toe|PXits|Adds in calc's and outputs, regardless of its experts
... this *replaces* the doubled-up PltRtn options ... and is part of the "portable algorithm"
... it gives "Easy" ver user a simple way to control this major impact: Neg= "traditional TP's"
• GuruV= positive, in Xprt|Cstm: BgnV<0=NoAdds; EndV<0=NoPXits; VFuz<0=NoToe
... allows *any combo* of Toe|PXits|Adds, in memorable places (fancy TP if BgnV | EndV > 0)
... it also means that all three experts' neg ranges s/b *identical* to pos ranges in other respects
... it also means that the Easy GuruV when negative is "logically" the same as the 3 in Xprt ver

• Need Toggles for: Short/Both/Long & EqtyFltr-Sigs & FwdWtd-Eqty-Stats
... ... Fore/Bkgrnd only applies if person paid extra for that high-level "recursive" filtering ability
... ... F/B, S/B/L, FwdWE settings would normally be "locked in", then experiment w/other settings
... ... S/B/L: B is likely the default; L-only also very common; S-only is very specialized
... BarWndoToCalculate is in portable paradigm ... slider is 0-999 (0-299=S,300-599=B,600-899=L)
... ... for Plotting, ###=output window width; for Return, ###=#barsB4hre (both= auto-warmup)
... ... current override: BbbWww, so both metrics can be spec'd (for targeted historical backtesting)
... ... allows 999 bar (~4yr) test-window, ending any time in the past 999 bars => 8yr coverage
... SOLUTION: add one extra digit to BarWndoToCalculate override, for the Toggles:
... ... New typed override: BbbTWww, where T controls S/B/L and Fwd-Wtd-Eqty-Stats(vs not Wtd)
... ... ... Bbb and Www can each be 0-999 (not in 300-segments as for slider S/B/L)
... ... ... T: 2=BothLS & NoFWE, 3=Long& NoFWE, 1=Short& NoFWE; 4/5/6=S/B/L & UseFwdWE
... ... ... 4-6 only needed when test-window is wide; also, FWE calcs are messy and maybe N/A
... ... ... Positive = No EqutyFltr on Trades; Negative= Use Equty-Flr (if licensed)
... ... Examples: 426= BothLS,NoFWE,NoEFltr, -426=same,w/EFltr; 6126=Long,UseFWE,NoEFltr,126b
... ... ... Very easy to type in or delete a neg sign, or a digit, or both ... and readily visible
... ... ... Very likely to want slider's ### setting locked, when playing with these other features
... ... ... +T's 1-3 are "base" features; +4-6 are specialty; neg has license-fee, => easier to code
... Clean, versatile, portable, memorable solution ... and, MORE control with NO new sliders!

• various flags => don’t need *dual* curves or wallpaper on Eplot for w&w/o Pcts or A+PX
• instead, show E+2ma’s, and use Wallpaper color to show Use/Maybe/Off from E voting
• Maybe = change Use<>Off *during* a trade - could mean start late or end early
• Maybe Starts/Ends when E vote changes; goes to Off/Use when current trade Ends
• show “actual” trade-equity as histo = using the E toggle effects (sep Return values too)

• Eqty calc if PltRtn req’s; pointer-chain calc
• Normalize/Share: ((XitC$-NtrC$)/NtrC$) / (NtrWTR$/NtrC$) = (XitC$-NtrC$) / NtrWTR$
• Tracking = running sum w/variable shares: %NomShrs * (Cls$-PrvCls$) / BarWTR$
... ... any time Shrs Add|Xit, adjust Eqty sum: +|- Delta%NomShrs * Cls$ / BarWTR$
• Lrs(E,X), Wma(3,Y) w/ Lrs(2,3) => 2stk+3slp, where X=8-12, Y=4-6 = f(SlowCumMA)
• Use=5-3net, f(Bgn); Kill=2-4opp, f(End)
• PltRtn Cstm override: XYUKss (ss=slider)

• All versions provide Signal and "basic" Scan outputs = **RAFT, or ATQ, or RUFF** (see below)
... *don't* need SlopStak EqtyVote to calc these (all could be avail, as Cstm Return options):
... ... NT = number of trades in test window
... ... HR = percent of trades that were profitable
... ... TPL = NetTrdPL ... w/Scaling Adj's, normalized for ClosePrc & WTR
... ... PF = profit factor = [HR * sum(TPL,winners)] / [(1-HR)*abs(sum(TPL,losers))]
... ... *TDD = MDD during a Trade = (Peak b4 largest drop - Lowest b4 new high) / Peak b4 drop
... ... TQ(TradeQuality~Rwd/Rsk) = TPL*[ 1/(bgnWTR*3) + 1/TDD ] /2
... ... TE(TradeEngagement) = Tot#BarsInTrds / #BarsInTestWindow
... ... STQ(SumTradeQuality) = Sum(TQ / BarsInTrd, NT)
... ... ATQ(AvgTradeQuality) = STQ^TE
... ... ... ... STRR=2^ : .8=1.74, .6=1.52, .4=1.32, .2=1.15 ... 51% (frc=4.93x)
... ... ... ... STRR=1.5^: .8=1.38, .6=1.28, .4=1.18, .2=1.08 ... 28% (frc=4.75x)
... ... ... ... Avg of TRR=2 / TRR=1.5: ( 1.26 + 1.19 + 1.12 + 1.06 ) / 4 = 1.18
... ... *MDD = test-window: (Peak b4 largest drop - Lowest b4 new high) / Peak b4 drop
... ... ... *TDD & MDD are considerably trickier to calc than the others in this list
... ... SPL = Sum(TPL,NT) = takes scaling into account
... ... CAGR = test-window: (End$/Bgn$)^(1/#yrs)-1 = SPL^(260/bars)-1
... ... APR = test-window: CAGR/Bgn$ -1
... ... Calmar = CAGR / MDD, using $normalized by share-price and ATR-risk
... ... ADD = test-window: Sum(TDD,NT)/NT ... TDD defined above
... ... APD = profit/trade vs avgDD/trade = SPL /NT /ADD
... ... RUFF= ReturnUpsideFreqFear = CAGR*sqrt(HR*TE)/ADD ... broader Calmar
... ... RAFT = ATQ*RUFF ... combo of "trade-focus" with "overview"
... ... ... ... depending on typical ranges of ATQ & RUFF, may need multiplier for scale
Top of the page Bottom of the page
JimDean
Posted 4/2/2019 7:58 AM (#9546 - in reply to #9544)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
I've revised the final red section of the prior post, renaming some things but mainly to define another overall metric "RUFF" that I think would be a more useful alternative to Calmar. The newly-renamed "ATQ" (previously ATRR) is another general-metric that I think would be better than Calmar.

ATQ focuses a bit more closely than RUFF on what's going on in each trade, evaluating small-wiggles as well as swings within the trade, and uses TE via exponentiation to factor in how frequently that symbol is "engaged" during the test period. RUFF starts with the net gain during the period, normalized annually, and adjusts it by sqrt-attenuated HR*TE ... incorporating TE in a different way, and also flavoring the result by the likelihood of success for a given trade ... finally, tempering it with ADD to represent the "fear factor".

I'm not sure which of the two (ATQ or RUFF) would be "better". So, I combined them into a single number ... RAFT = ATQ*RUFF ... (conceivably if by serendipitous chance ATQ and RUFF have similar value-ranges, they could be averaged instead of multiplied) ... but however it's done, a higher value is better.

Please chew over the revised and expanded formulae, and let me know what you think would be most useful as a SINGLE metric for OmniScan selection of good candidate symbols that would populate the FL.

Salim, since this has nothing to do with the parameters or other workings of the Stradicator ... it's just ways of measuring trading success potential ... please don't just skim past it ... give it some careful thought, and *choose* one - thanks
Top of the page Bottom of the page
KenWilsdon
Posted 4/2/2019 11:15 AM (#9549 - in reply to #9178)
Subject: CVW Archived Devel Discussion



Friend

Posts: 47
25
Location:
: ,
Hi Jim,

Upon further reflection, I have a question how these metrics would be used in, say, Omniscan to sort for the best candidates. I know we talked generally about it, and I am in agreement with it, but need more details to make a decision on the 2 alternatives.
3 alternatives: RAFT, RUFF, or ATQ

My questions relates to how we would determine which sets to scan for. I am conceptually trying to understand the process. Also I am trying to understand how this process could be automated (you know this is a big focus for me). Then I may have a better idea which of the two metrics I personally prefer.

1. Would not these metrics be Guru and Xprt sliders derived (as I understand the values)?
All input param's would affect the output metric, of course. You'd use SBAS or other means to determine what input-pattern you want to use ... most likely, use the same for the Scan that you use for trading those symbols ... that's the core idea anyhow.

2. If so, are we finding the best general set(s) of settings, and scanning for them to put in our Focus List? A good start would be the Master sets, of course. I understand from prior posts that there will be 8 Masters for filters, which I assume could be used, then symbols sorted in the FL by how strong they are, by the metric chosen, or by Ind. FL Columns for each of the 8.
What Master options will be is still very fluid ... need to see the SBAS results for that.

3. Do we do that by running on something like the Russell or SP500, etc. (user defined) to find those which pass some threshold (also user defined) in the Omniscan (using other variables like min volume or price to filter as well) on at least one of the 8 Master Sets?
I'd use maybe Optionable (~3k symbols, presumably fairly liquid), then put in other Scan filters for Price and Liquidity limits and other Personality things to cull the list down. Then use this output CVW equity-stat to SORT the list, to peel of the top X symbols (50 maybe?). Once you get a feel for what the typical range is for the equity-stat you want to use, you could also optionally call CVW as a part of the Scan filters, requiring some minimum value for the equity-stat (as well as sorting on it). Or, you could use one EStat for filtering, and another for Ranking.

4. How do we then determine which slider positions we want for a particular symbol on a particular day? The 8 Masters would get us close, but if we use just this to buy/sell, then in some ways the other sliders will be unused. So how do we get to the next step? I am sure the metrics here will be used, but unsure of the process.
The Scan I described would be looking at recent-history ... depending on how tight that sampling is, the Symbols chosen for the FL would vary at different rates. My guess is that redoing the scan once a week, using the same param's, would be sufficient (as long as you also keep the params of the strategy the same). Occasionally, maybe once a quarter, you might decide to re-optimize the param-pattern, and update the OScan filter|sort as well as the strategy with the new values. I wouldn't expect the quarterly tweaking to result in radically different patterns, but ya never know ...

I hate to slow down your work to answer this question, but we have not (to my knowledge) really dealt with this in the forum to date (I may be wrong) in print, so we have a record of the process. Doing this may clarify some things unknown to us presently that need to be addressed, and may also make clear which metric we should use. This is like taking a step back to look at the big picture goal of this whole process. As this will be used in all upcoming Stradicators, I think it is important to clarify the process at the start, so we get things right the first time.
very good question ... hopefully my explanation helps
Top of the page Bottom of the page
SalimHira
Posted 4/2/2019 2:31 PM (#9550 - in reply to #9178)
Subject: CVW Archived Devel Discussion



Veteran

Posts: 176
100252525
Location:
USA: MD, Columbia
RAFT, ATQ, and RUFF in that order.

The way I am currently thinking, unless proven otherwise, since it does not seem to matter if either ATQ or RUFF, as the value best that goes higher - than, I'd select RAFT the combo of both... but, if I need to know in particular which may be leading or lagging in the race btwn ATQ and RUFF - than it becomes a coin toss - and in that case, I continue to select ATQ in every instance of the toss for the simple reason of the "fear factor" embedded in the equation.

THANKS!
Top of the page Bottom of the page
JimDean
Posted 4/2/2019 2:33 PM (#9551 - in reply to #9178)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
When Ken asked about Long/Short/Both control on the phone call yesterday, I was bothered that I could not find the definition of the "DCZSVOO" PltRtn override that was in the code-comments ... turns out that it was in a post back on 3/28 (actually earlier, before repost with updates) ...
http://tradetight.org/forums/thread-view.asp?tid=1432#M9490

That post specified "DCZSV" as Cstm-ver manual for the PltRtn OutputReturnHelpPlot input:
... D= trade-Dir's allowed SBL; affects are interactive (B <> S+L sometimes)
... C= EqtyVote impact on trades: Block Entry/FIlter &/or Force PX/FX &/or LateEntry
... Z= SmartSizing as func of atrRisk &/or pctPrc for initial-base 100% value
... S= tweaks to Equity-MA speed/slope (~TimeGuru for Eqty filtering)
... V= tweaks to Equity-Voting rules (~VoteGuru for Eqty slope & stack)
(actually it would have been DCZSV##, where ## is the normal PltRtn slider value)

However, since I more recently defined a way to handle the Long/Short/Both via the "T" digit override of the BarWndoToCalculate param, I don't need the "D" digit as part of the PltRtn override group. "T" was defined in this post:
http://tradetight.org/forums/thread-view.asp?tid=1432#M9544

Also, since the EqtyFltr-Sigs toggle (ie use EqtyFltr logic or not) is part of BarWndoToCalculate's override as a *very easy to manually flip* "+/-" feature, it can *remain* there, even though the "C" override for PltRtn specifies a granular control of how the EqtyFltr might be applied. If "C" is manually input in PltRtn, then the "-" in BarWnd simply toggles it off/on (handy for quick comparisons).

Most of the PltRtn features above are related to the extra-cost Equity-Filter option ... except for D which is being handled by T in the BarWnd override. Since most of the other features of the CZSV group require the optional Equity-filter license purchase, it makes sense for them to stay together, while the "standard" Long/Both/Short s/b in the BarWndo "T" digit.
The "Z" digit provides a bias-adjustment to the SmartSizing formula, which was enhanced by "AutoGenTP" research last year (italics, below). Z specifies a representative "stop-loss" gap related to ATR: Z=1-9= 1.0-5.0x in 0.5 increments ... default= 3.0 is used if Z not specified. This (renamed to "R") becomes the basis for what follows.
SmartSize balances the Risk$ vs Capital$, in light of what's "typical" for that stock's price-range. Normally you use something like 10% of Account to limit Cap$ (Elder), and something like 2% of Account to limit Risk$ (VanTharp). SmartSize (in its simplest form) calc's the shares for both limits, and uses the smaller of the two.
Here, we don't "know" the Equity since all the $ are normalized, so we only need to know the ratio of those two percentages ... ie 5.0 would represent 10%Cap/2%Risk. So, our override "B"(balance) for this spec will be a single digit 1-9, which represents a SSratio of 2-10, where 0=default would use 6.0 ... ie 1.67% Risk$ for 10% Cap$.
Therefore, the two digits BR define SmartSizing. This does not require EquityVote licensing, but can't fit into the
BarWndoToCalculate override, so it has to be in the OutputReturnHelpPlot override, since the GuruV+3experts already have overrides for other things (GuruV override is for Filter).
Optionable Stocks were sorted into 200-sym bins, then a median share-price and ATR for each bin was found. The result, when parsed into 9 normalized bins, showed that sTR/5%C was 4.25 for $86 stock, and 1.44 for $5 stock (where sTR = sma(ATR(1)) ... thus, knowing the price of the stock, the "typical" sTR can be calculated: Typical sTR= Close/20 * [1.44+Close*(4.25-1.44)/(86-5)]. If the actual sTR is >/< the Typical, then there is currently more/less wiggle-Risk$ than typical for that share price, and the Size should be adjusted by TypSTR/ActSTR. HOWEVER, the actual code will not use that approximate linear $86-$5 formula ... it will use a curve-fit to the 18-bin nonlinear table that came directly from the research to determine the appropriate "balance point" TypSTR for a given Symbol's Close$.

Summary of rearrangements from those two prior posts:

Manual override for BarWndoToCalculate (all versions, no special license):
... BbbTWww, where T controls L/S/B and Fwd-Wtd-Eqty-Stats-Calc(vs not Wtd)
... ... Bbb and Www can each be 0-999 (not in 300-segments as for slider S/B/L)
... ... T: 2=BothLS & NoFWE, 3=Long& NoFWE, 1=Short& NoFWE; 5/6/4=B/L/S & UseFwdWE
... ... 4-6 only needed when test-window is wide; also, FWE calcs are messy and maybe N/A
... ... Bbb *not required* unless historical test window should end sometime before the Hre
... If this input is NEGATIVE, it toggles EquityFiltering ON (if it's been licensed)

Manual override for OutputReturnHelpPlot (only avail with Cstm & special EquityFiltering license):
... SVCBR##, where +/- ## is standard PltRtn settings for output control, and:
... ... S= tweaks to Equity-MA speed/slope (~TimeGuru for Eqty filtering)
... ... V= tweaks to Equity-Voting rules (~VoteGuru for Eqty slope & stack)
... ... C= EqtyVote impact on trades: Block Entry/FIlter &/or Force PX/FX &/or LateEntry
... ... BR= SmartSizing as func of atrRisk &/or pctPrc for initial-base 100% value (see above)
Top of the page Bottom of the page
JimDean
Posted 4/3/2019 10:28 AM (#9552 - in reply to #9551)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
(Fairly) Easy "Visual" Q for Salim & Ken ...

I'm working with Ken on possibly implementing bands around price for trailing-stop-like partial & full exits both on the downside ("Curbs") and upside ("Grabs"). They would appear on the price pane as two or four lines, spaced above and below the candles based on Strad-set ATR-mults. This would be a part of the "standardized portable paradigm" that I'd implement in all Strad's. There are *a whole bunch* of pros and cons ... but THIS POST ONLY FOCUSES ON ONE THING ... how it would affect the appearance and usability of the Parameter pane. Please limit your comments to that, here.

In the snap, I "faked" moving the last two lines to just below the first two, and adding in a new slider at the bottom which would be a fourth "expert" under the VoteGuru (new slider would not appear in Easy version, but rearrangement of last two lines would). Reason 1: if I add any more lines to the pane, it becomes ugly two-column. Reason 2: I'm thinking maybe it's more useful to keep the two section-divider gray areas to identify the two Guru-sections, rather than having to remove the one in the middle, scrunching two Guru sections together, and keeping the two output control lines at the bottom with a section-divider between them and the Gurus.

Note that the section labels change and also the Guru param names change ... when the two Guru sections have no intermediate divider, I capitalize GURU to help clarify the boundaries.

Two snapshots provided. Which do you prefer (visually and functionally)? (please keep in mind that this might affect a lot of stradicators).

Result: Ken liked #1 for reasons I agree with; Salim liked #2 ... going with #1


(Params with GC-gap slider & same Output.png)



(Params with GC-gap slider & move Output.png)



Attachments
Attachments Params with GC-gap slider & same Output.png (179KB - 0 downloads)
Attachments Params with GC-gap slider & move Output.png (172KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 4/3/2019 4:17 PM (#9644 - in reply to #9178)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
The standard-paradigm Stradicator Add logic will be modified to *prevent* an Add from occurring when it is triggered by the "normal" rules, if the Close price is not a good one (ie too high, for Long) - the internal code will emulate this. The "acceptable range" will be the lowest of: highest prior Close since trade began, or halfway from the price to the PartialGrab line at the time of the prior Close. Adds will use next-bar StopMkt-Orders with level set to the Close of the prior bar that signaled the Add ... which usually will prevent a poor price-fill, but definitely prevents a partial-fill (since SM becomes Mkt when triggered).

The code will assume that feed is end of day, executing after the close ... unless I can find an easy way to "read" OT's exchange-time table to get the Start and End time for that day, versus the current clock time. Gianluca suggested using AfterSessionOpen and BeforeSessionClose to derive exchange times vs System clock - not sure if that works for daily-bar feed

Add-overrides will have a min limit of 20% and max limit of 80% (4*20) ... this assures that no more than four Adds can occur in a trade (ie during Elliot Wave 2 & 5 "A"&"C" legs, ideally). Each successive Add is 20% smaller than the prior one.

Partial G|C virtual orders use the PXit pct defined by the EndV slider, unless it's overridden. That is, the PG|PC exit size can be: default PX size, overridden PX size, or a different size from a CutGrab slider override. Regardless of the source, the size *must* be one of the 10%-multiples supported by the PXit orders in the TP ... likely range will be 50%-10%. The default PX assignments from the EndV slider are 20|30 ... maybe I'll change that to 20|40 ... unsure at this time. Note that if the user wants PXits to be bigger than 50% in order to end the trade quicker, they can reduce M &/or W so that the PXits fire more easily.

A new EndV override option will permit the user to modify the PXit-size required to allow a subsequent Add. Default is 3/8 of Add for first add, and 2/3 of next-add, for following Adds. New override can require prior PXit to be at least: 1=1/6, 2=1/4, 3=1/3, 4=3/8, 5=1/2, 6=2/3, 7=3/4, 8=1/1,9=anyPX ... that represents all the combo's of 80%-20% Adds, with 30% & 20% PX's.

The new CutGrab slider will permit separate overrides for Partial Grab & Cut sizes (ie instead of the size of the normal PXit defined by EndV) ... but these must be in tens-increments from 50%-0%, so that the Robust TP can support them with its standard Conditions (0% permits Cstm uset to turn off either/both PC|PG, while leaving FG active). Also, separate PC|PG overrides can spec non-standard ATR-mult gaps: 1=1.0, 2=1.5, 3=2.0, 4=2.5, 5=3.0, 6=3.5, 7=4.0, 8=4.5, 9=5.0.

BgnV overrides for Toe allows 20%-60%, and allows 20%-180% for Cnfrm or Full (but prevents any combination of them from exceeding 200%). Both TP's will support a version of "SmartSizing" that potentially adjusts the Toe+Cnfrm or Full Entry sizes to balance wiggle-Risk exposure vs $Capital tied-up in trade, using rules that can be tweaked via Cstm overrides. The "nominal" Toe,Cnfrm,Full entry-sizes are multiples of 20 ... SmartSizing can tweak the nominal values up (if Risk relatively low vs Price) or down (if Risk high vs Price), such that the actual Size used is in multiples of 10%. I'll probably build in a limit so the adjusted size is always within +/- 10% of the nominal one chosen by the user. This adjustment will not affect the Add or Partial exit sizing ... Adds will always be multiples of 20, and PX|PG|PC exits will be user-specified multiples of 10 (this restriction is related to the "Robust TP" structure.
Top of the page Bottom of the page
JimDean
Posted 4/4/2019 3:23 PM (#9558 - in reply to #9552)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Addendums to the Cut&Grab description post

It seems to me that the Partial Cut gap options should be a bit tighter than the Partial Grab options, since the "default" (recommended) Reward:Risk should be a bit better than 1:1 ... like maybe 1.25:1. Using that, the PC's list is: 1=0.8, 2=1.2, 3=1.6, 4=2.0, 5=2.4, 6=2.8, 7=3.2, 8=3.6, 9=4.0 ... so, middle PC override is 2.4xATR.

The FullGrab override options (virtual orders, based on Close price just as PG&PC's are), which logically must *always* be wider than the PG spacing. So, FG override options use the *same* list as PG's, but they ADD to whatever the PG gap is ... additional FG gap override options: 1=1, 2=1.5, 3=2.0, 4=2.5, 5=3.0, 6=3.5, 7=4.0, 8=4.5, 9=5.0 ... so, minimum override-based FG is 2xATR (1+1), max FG is 10xATR (5+5), and "5=middle" setting is 6xATR (3+3).

The new Cut&Grab SLIDER will provide 5 options for gaps and tightening-time ... neg uses same values but toggles off the FG, PG, and PC, leaving only the FC broker stops. Since the slider controls more than one thing (sort of like BgnV & EndV), the gap-options will be in pairs, with differing tightening-rates distinguishing each pair. That is, Slider 1-5 "Sml2Lrg" gap settings:
1 & 2 will both use 4x for FG, 2x for PG, 1.6x for PC
3 & 4 will both use 6x for FG, 3x for PG, 2.4x for PC
Slider=5=Lrg uses 8x for FG, 4x for PG, 3.2x for PC

The time-tightening settings will distinguish the components of each pair ... 1 & 3 will use fast tightening, 2 & 4 will use slow tightening, and 5 will use medium tightening. Tightening is "smart" ... that is, *no* tightening while profits are accruing at a reasonable rate, faster tightening when meaningful iterative losses are accruing, and medium tightening between those categories. Since the starting-points for FG, PG, and PC are significantly different, the tightening needs to be a fractional multipler of the starting-gap value, rather than a simple per-bar subtraction. Here's what I've tentatively decided on (see attached spreadsheet for various combo's analyzed):
1 & 3: gap tightening per "meaningful-additional-loss" bar = - 24% of InitGap /bar
2 & 4: gap tightening per "meaningful-additional-loss" bar = - 20% of InitGap /bar
slider5: gap tightening per "meaningful-additional-loss" bar = - 22% of InitGap /bar
... the "medium" tightening would therefore be -12%, -10%, and -11% respectively

A simple example might be a case where the second bar of a Long trade "pops up" a lot but not enough to trigger a Full Grab, then is followed by a consolidation where price doesn't really go anywhere. We'd want the Cut bands to tighten up and take out the trade (keeping in mind that the Stradicator logic probably will be "helping out" some, too). The default slider setting=3 assigns a "meaningful loss situation" tighening of -24%/bar, but since the example has the price staying pretty much flat, the "medium" alternative= -24/2= -12% would be used. This means that the Cut threshold would become *zero* after ~8 bars ... but since each bar has a bit of wiggle to it, the close probably would likely swing half an ATR lower than mean. The slider=3 setting puts the initial PC gap at 2.4x ... if we reduce that by ATR/2, then we need to tighten the band down to 1.9x to get a hit for a "flat" consolidation ... -12% of 2.4x =0.288x ... so reduction of 1.9x would only take 6.6 bars.

That example is illustraded in the bolded-box A17:G29 in the xls). Row 16 shows the associated Partial Grab multiplier (for a PG/PC Reward/Risk of 1.25). Row 30 shows the associated Full Grab multiplier (twice as wide as Partial Grab). The pink cells in col G shows Max/Min variancefor the #bars it takes to hit. Hopefully the meaning of the other fields is clear from the labels.

Later: expanded slider to 1-6, with 5&6= 8xFG,4xPG,3.2xPC and -20%/bar

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

Finally, the FullCut options need to be established ... but since they are broker orders, they are locked in by the TP to fixed options. I mentioned earlier that all of the cuts and grabs will tighten as time passes ... for the locked-in FC's, that is done by making the gaps tighter after each successive Add (ie different "sections" of the Robust TP). The TP *can* provide multiple choices for FC's, but each choice adds another Condition row to *every one* of the (potentially hundreds) of Steps, so prudence is called for ;~).

For FullCut, the Initial multiples for Slider=1,3,5 will be 80% of the FullGrab multiples ... ie a nominal 1.25 Reward/Risk. Since the timing adjustment is not as "smart" as used for the FG, PG and PC, the slider-variance is linear: 1=3.2, 2=4.0, 3=4.8, 4=5.6, 5=6.4 ... these will be locked-in by the ATR-multiplier in the TP Orders panel, for each condition. The FC model will therefore require five Conditions per Step in the TradePlan.

In each new TP Add-section (Adds drop by 20% each time), those FC Conditions will tighten, since the trade has obviously matured more, and it's smart to become more protective of the progress. There are a maximum of four Adds (if InitAdd is 80%) ... so, for each new Add, the FullCut ATR-multiples will tighten by: 1=-0.4, 2=-0.5, 3=-0.6, 4=-0.7, 5=-0.8 ... thus for the fourth Add section (which will rarely be reached), the final FullCut gap-spacing ATR-multiples will HALF of what they started: 1=1.6, 2=2.0, 3=2.4, 4=2.8, 5=3.2

Later: expanded slider to 1-6, with 1-6= 2.4x to 6.4x, @AddCut= -0.2 to -0.8

Overrides will be available for FullCut, but they ONLY will be able to specify Initial FullCut gaps amongst the five slider values. That is, if Slider=3 (for the FG,PG,PC settings), a manual override could force the FC to use the slider=5 setting.

Of course the PC's will be much tighter by that time too, so working together, they will help assure a "tidy" exit from the trade, hopefully avoiding being hit by big reversals or wild volatility that is common after the end of an Elliott Wave-5. Even if the full exit is not before that point, the Partial-exit rules (Grabs and Cuts) along with the tightening, will usually have reduced the position size significantly ... thereby minimizing the impact of a final big bar opposing the trade.

Another change since prior post: when Cut&Grab slider is neg, the FC and FG lines remain functional. The FC multiples won't vary (if the BgnV-Add slider or GuruV slider is negative), so in this case ... ie using the "Simple TP", the FC gap multiples will be halfway between the InitialAdd and FinalAdd lists, above.

Attachments
Attachments Cut&Grab Gap&Tighten.xlsx (18KB - 2 downloads)
Top of the page Bottom of the page
JimDean
Posted 4/16/2019 8:35 AM (#9567 - in reply to #9558)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
... recap of cleaned-up posts, w/modified approach to BarWndo input ...

Result of discussion re output spec for Both/Longs/Shorts ...

Too messy to fold into overrides, and also needs to be universal for Easy & Xprt not just Cstm. Distinctions between S & L patterns to use for trading, if any are desired, are handled by creating two sep Strategies, one for Long-Only and the other for Short-Only. We need one of the existing input parameters to clearly distinguish between B/L/S to support this as a part of the portable Stradicator paradigm.

Only sensible input for that is BarWndo, since it isn't normally fiddled-with, and doesn't change the wave-creation logic. The input slider goes from 0-256 (def=128) ... but allow typed input:

0-299 means Both Long&Short trades with output window spec 0-299 where 0= all possible
300-599 means Long-Only trades with output window spec 0-299 where 300= all possible
600-899 means Short-Only trades with output window spec 0-299 where 600= all possible
... the default is "Both" with ~6 months => 128 default

I've decided to limit the slider itself to the 0-256 "Both" range ... thus the user needs to type in (any version) other values that limit limit the output to one trade-direction or the other. In the great majority of cases, this will simply "turn off" one color (green or red) without affecting the other ... "pure" reversals are the only exception that I can think of ... if the "reversal direction" is the only one allowed, that bar will start a new wave ... but if "both" are allowed, that bar ends the prior wave without starting a new one.

When Long-only or Short-only used, the "Buffer" eval uses trades in both directions to find a legit, stable starting point. It's (rare but) possible that when a white-center-line shows up on left edge of Band, that some of the opposite-direction trades might appear, but they should be ignored anyways.

The slider name should reflect the additional distinction:

BarWndoToCalculate becomes BarWndoOutTrdDirBLS
Top of the page Bottom of the page
JimDean
Posted 4/16/2019 9:31 AM (#9568 - in reply to #9567)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
UPDATED version ... old post deleted ...

I added ONE NEW override feature that is not mentioned in prior posts ... the "X" override digit for BgnV. X specifies the max# Adds allowed. Routine *typically* applies a 20%-reduction-in-Add-size for each new Add-section in the TP (and internal stradicator logic), and since the max possible Add is 80% (via override or slider), there are up to four possible Adds. However, the user might want to limit that to just *one* add of only 80%, or maybe just *two* of 60%,40% (etc) ... this X input specifies how *many* are allowed. 0=no limit (can spec A=0, or make input neg, to kill Adds), X=1-3 causes the reduction-algorithm to work normally, but prevents more than that #of Adds from occurring, regardless of what the initial Add% is.

Furthermore (and this is the further-revised expansion-part ;~) ... the X input can also be 4, which says to use the reduction-method with no explicit Add limit, but reduction is 40% for each new Add, rather than 20% reduction ... thus X=4 with A=4=80% initial allows a second Add of 40%, but no further Adds since the next would be 0%. Similarly, with X=4 and A=3=60%, the second (and final) Add would be 20%. X=4 and A<=2 is the same as X=1 with A<=2 (ie only one Add). Finally, to complete the menagerie, X=5 means the second-Add-reduction is 60% - thus X=5 & A=4 means the first Add is 80%, and the second (final) Add is 20%. All other A-options with X=5 really mean the same thing as that A-option, paired with X=1.
Note that since the TP is hard-coded only to support a max of four Adds (first Add max = 80%, down to 20%), and the Adds are all 20%-multiples, and the successive Adds always get smaller (if active), these two new X=4,5 options complete all possible permutations, without requiring the TP to be expanded.

Also, I allowed the BgnV overrides to turn off Adds (A=0), turn off Toe-In (T=0), or even turn off Confirm (F=0, or F=T with T>0). That latter case - a Toe-In *without* Confirm - allows 20-100% size "toe-in" Entry when an Alert fires OR when an initial BgnV-Bright fires, *without* allowing a followup Confirm-trigger to augment the size prior to a PXit. No additional Steps will be needed in either the simple or robust TP's to fulfill this ... and it seemed to be a useful option. Note that there is an alternative approach which does not ever enter when an Alert fires ... set F>0 and T=0.

I realize this may seem pretty confusing, but the idea of the Cstm version (and the entire paradigm) is to support the max possible flexibility with min# input-sliders, while sticking to a generic TP structure. The flexibility described above is imho a welcome addition.

The "main" changes to earlier descriptions are for the BgnV (#*20% size limits & X-limit), EndV (#*10% size limits and A=req'd prev PX% req'd), and especially CutGrab, which is all-new and very powerful, using all seven possible digits. Note that the 4-line CutGrab feature is part of the "stradicator paradigm" ... that is, its logic will be echoed for all stradicators (esp since the TP is hard-coded to match it). Also part of the paradigm: GuruV, BgnV, EndV, VFuz, BarWndo, PltRtn
Top of the page Bottom of the page
JimDean
Posted 4/16/2019 11:01 AM (#9569 - in reply to #9568)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Here is an updated snap of the Param's pane ... names in yellow have been modified ...

Most important need seemed to be to change the second-guru's name ... it used to be GURU_WaveSm2Lrg, but since this is part of the stradicator paradigm, I thought I need to move away from "Wave". I've been referring to this as the VoteGuru or GuruV (vs TimeGuru or GuruT), so that's where I started. Recently we added the CutGrab slider, which really has nothing to do with Votes at all, but is under the control of this guru. So, "VotBnds" was born ... "Bnds" can be thought of as either Bands or Bounds (Boundaries) ... either way, it refers not only to begin and end of waves / tradezones, but also to the Full and Partial Cut and Grab lines. I used Tyt2Lax since Tyt2Wyd and Tyt2Loose wouldn't fit.

The FuzVote modification removed the reference to the negative range (turn off Toe), since no other slider ref's neg ranges (again, this is part of the standard strad paradigm). I also tweaked the MAvgCalc and MASlope names a bit.

I changed the final two params to be a bit more helpful. BarWndoTrdDirL3cS6c reminds the user that even though the slider range only goes from 0-299, they can type in 300+ for Long-Only and 600+ for Short-Only ("c"=hundred). ReturnNgHelp0PlotPos seemed a little more helpful than just "OutputReturnHelpPlot".

Other alternatives for the 2nd to last: BarWndoLimDirL3cS6c or BarWndoOneDirL3cS6c or BarWndoSngDirL3cS6c

Are any of these changes objectionable ... that is, are the new names meaningfully worse than before?

Another thing I am considering would be to move the new CutGrab slider out from under the GuruVote section, into the final section ... that is, make it an independent expert from the three that actually do have to do with Voting. Rationale, besides it not being a vote thing, is that folks with Easy might like to have that control ... and since it's simple to understand (very graphically obvious) ... and also since it's a "TradeTight innovation" (the idea of "grabs" is unique to TT, imho), it might help to "promote" it to being more obvious. I'd change the section-header to "BandsAndOutputSpecs", if I did this.
I'm undecided, so please tell me your thinking ...

Should the CutGrab slider be extracted from the VoteGuru section and made visible for Easy?

(CVWeval V2 Parameters.png)



Attachments
Attachments CVWeval V2 Parameters.png (171KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 4/16/2019 11:51 AM (#9572 - in reply to #9178)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Please answer *both* bold questions from the prior post. Thanks.

Re the BarWndo name ...
I provided three other options. Are any of them better?

Keep in mind that the param labels are reminders, not full definitions. Once you "know" that L3cS6c means LongOnly starts at 300 and ShortOnly starts at 600 ... would the label be memorable, and would it be helpful?

The earlier version gave no clue as to the ranges ... ie 0-299, 300-599, 600-899 had to be "guessed at" from slider fiddling, or from looking up something in a PDF.

Another approach (sort of clunky imho) would be to longhand the numbers ...
"BarWndoOnlyL300S600" or "BarWndoLonly300S600"
Top of the page Bottom of the page
KenWilsdon
Posted 4/16/2019 12:07 PM (#9573 - in reply to #9569)
Subject: CVW Archived Devel Discussion



Friend

Posts: 47
25
Location:
: ,
I changed the final two params to be a bit more helpful. BarWndoTrdDirL3cS6c reminds the user that even though the slider range only goes from 0-299, they can type in 300+ for Long-Only and 600+ for Short-Only ("c"=hundred). ReturnNgHelp0PlotPos seemed a little more helpful than just "OutputReturnHelpPlot".

Other alternatives for the 2nd to last: BarWndoLimDirL3cS6c or BarWndoOneDirL3cS6c or BarWndoSngDirL3cS6c

Are any of these changes objectionable ... that is, are the new names meaningfully worse than before?


I prefer BarWndoTrdDirL3cS6c, with BarWndoSngDirL3cS6c being second. The other 2 are a bit more vague.

Another thing I am considering would be to move the new CutGrab slider out from under the GuruVote section, into the final section ... that is, make it an independent expert from the three that actually do have to do with Voting. Rationale, besides it not being a vote thing, is that folks with Easy might like to have that control ... and since it's simple to understand (very graphically obvious) ... and also since it's a "TradeTight innovation" (the idea of "grabs" is unique to TT, imho), it might help to "promote" it to being more obvious. I'd change the section-header to "BandsAndOutputSpecs", if I did this.
I'm undecided, so please tell me your thinking ...

Should the CutGrab slider be extracted from the VoteGuru section and made visible for Easy?


Sounds like a good idea.

I think your ReturnNgHelp0PlotPos is a little difficult. But not sure what would replace it if you want both +ive and -ive in the title.
Top of the page Bottom of the page
KenWilsdon
Posted 4/17/2019 12:34 AM (#9575 - in reply to #9573)
Subject: CVW Archived Devel Discussion



Friend

Posts: 47
25
Location:
: ,
Would it be better to return to the more generic "OutputReturnHelpPlot" for the final param?

It might be better. That is clear.

Re moving Cut Grab ... I forgot to mention the "downside". If it's not linked to the GuruVote slider, then it will be easier for the user to "inadvertently" create tight restrictions re the Vote rules, while leaving the borders loose (or vice versa) ... without an obvious visual prompt pointing out the disparity.

Can you think of a significant number of situations where the user might want the vote rules to be "tight", but the Bands to be "loose" ... or vice versa?


Not offhand. But someone else may be able to come up with situations during testing.

But I would say the danger is there, even if it is under the GuruVote slider, if people are not consciously thinking about the vote slider and the Cut Grab being related. This could happen because there are lots of moving parts to the stradicator for people to consider.
Top of the page Bottom of the page
JimDean
Posted 5/2/2019 10:15 AM (#9576 - in reply to #9575)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
see following two posts for revision & simplification (only white line; smaller buffer)

I finally figured out how to plot the thin line through the middle of the top band, to indicate when the color-state *might* be unreliable/unstable. I described this several posts ago. The core issue is that the *end* of a trade is sometimes determined by *counts* of medium and dark (warn) bars ... so, if the *beginning* of the trade is uncertain (due to output range starting in the "middle" of what would have been an already-active trade), then it follows in some situations, the *end* will not be counted correctly ... that is, the trade might appear to drag on longer than it would have, if a wider output zone had been requested.

That part, I've fixed, by adding a buffer zone to the warmup, before the formally requested output window is hit. All the calc's necessary to determine "legit" output are in place at the beginning of that buffer, but it might "start" in the middle of a wave. So, *during* the buffer zone, the code first searches for a navy-blue bar ... that is, a neutral bar not (apparently) in a wave. Once it's found that navy bar, then it continues to search, waiting for a full begin-to-end-wave to *complete* ... at which point, a "fully legit and stable" output can be expected.

If that entire search process completes successfully *within* the buffer zone, then the top fat output band has a normal appearance, from left to right.

However, if that search process is INcomplete even after the buffer zone, then a thin horizontal line is plotted in the middle of the top band, UNTIL the stabiliy-validation requirements are met:
The thin line is white until a navy bar is found
The thin line is black after the navy, until the end of a subsequent complete trade is found.

So ... if you don't see any thin center line, then all output is *definitely* stable.
If you see a black center line, then output is fully stable *after* that line disappears.
(note that it's much more likely to be stable with a black line than with a white one)

In some cases, even though there is a thin center line, it doesn't *necessarily* mean that the output is incorrect. It's sort of like a "take this with a grain of salt" situation.

The first snapshot below illustrates the appearance of this ... NOTE that to create this, I reduced the hard-coded "buffer zone" to just one bar, so that *both* the white and black lines would appear.

The second snapshot shows the same 3-mo window, but with the hard-coded buffer set to 10 bars ... enough so that the navy was found before the requested output window, but not enough for a full trade to complete within the buffer zone (so the black line extends into the output window).

The third snapshot shows the same 3-mo window, but with the buffer hard-coded to its *normal* value of 40 bars ... this allowed enough pre-output warmup to assure stability throughout the entire requested window, so no black or white centerline appears.

The final snapshot shows the 6-mo view (w/40-bar buffer) ... this helps clarify what was going on during the 1/10/40-bar buffer zone in the prior examples.

QUESTION - is this explanation, and the output-formatting understandable?

(ThinCenter,buf1.png)



(ThinCenter,buf10.png)



(ThinCenter,buf40.png)



(ThinCenter,buf40,6mo.png)



Attachments
Attachments ThinCenter,buf1.png (17KB - 0 downloads)
Attachments ThinCenter,buf10.png (17KB - 0 downloads)
Attachments ThinCenter,buf40.png (17KB - 0 downloads)
Attachments ThinCenter,buf40,6mo.png (18KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/2/2019 11:10 AM (#9577 - in reply to #9576)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Followup to prior post ... please read it first, or this one won't make sense ...

Reasons why doing this is important:

1. Entry/exit signals might not be stable otherwise (as time moves forward)
2. Cut/Grab bands (not yet programmed) might be unstable due to shifting entry & counts
3. Equity calc's and equity filtering (OScans and trade-toggle) similarly might be unstable

Therefore, Equity calcs, will *only* evaluate complete, stable, no-centerline wave-trades. The Cut/Grab bands will *only* show up for those trades ... not for waves with centerlines.

Why I picked 60 bars (example=40 in prev post) as the default buffer:

1. gut feel ... approx three months worth ~max extra warmup penalty I could stomach
2. it made the black lines disappear in a series of test cases (though I didn't do a zillion)
3. no matter what I pick, there will be *some* cases that create a centerline

Note that this extra buffer-warmup will somewhat penalize the speed of calcs for backtesting and FL output, which really only "needs" one bar at a time. But the history leading up to that bar is a big part of what determines that bar's state.

QUESTION: does this sound like a sensible approach? Do you understand its importance?

Top of the page Bottom of the page
SalimHira
Posted 5/2/2019 2:45 PM (#9578 - in reply to #9178)
Subject: CVW Archived Devel Discussion



Veteran

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

You said:

"So, *during* the buffer zone, the code first searches for a navy-blue bar ... that is, a neutral bar not (apparently) in a wave. Once it's found that navy bar, then it continues to search, waiting for a full begin-to-end-wave to *complete* ... at which point, a "fully legit and stable" output can be expected."

<<So, basically, this is a hold placement of some sort of "erratic" behavior of Volume while it is playing it out within itself, until it becomes ruly. >>

The thin line is white until a navy bar is found. The thin line is black after the navy, until the end of a subsequent complete trade is found.

<<When these lines appear, I assume it be noted that no trades are to be taken under these circumstances. Buyer/Seller caution placement "at your own risk".>

The third snapshot shows the same 3-mo window, but with the buffer hard-coded to its *normal* value of 40 bars ... this allowed enough pre-output warmup to assure stability throughout the entire requested window, so no black or white centerline appears.

<< Here, I am confused as to why a shorter #of bars shows up with the thin lines, while larger #of bars assures stability, well-noted keeping in mind the warm-up periods.>>

QUESTION: does this sound like a sensible approach? Do you understand its importance?

<<Yes, but kind of concerned with the "speed of calcs". Meaning, if you minimize the #of bars, the thin lines begin to appear, maximize the bars, and speed slows it down. Otherwise, yes, the importance is duly noted, and the appearances of thin lines surely helps understand what may be happening behind the scenes (Bars). >>

Top of the page Bottom of the page
JimDean
Posted 5/2/2019 2:47 PM (#9579 - in reply to #9577)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
further thinking about buffer evaluations ...

I think I missed a bet in my earlier posts - the buffer can be smaller, since the "instability" situation is not as bad as I originally described.

What I need to search for in the pre-output buffer is a bar that is *surely* not part of any existing trade ... ie a navy bar that will be navy regardless of how much historical running-start is evaluated. Once that is hit, then any subsequent wave-inceptions will be certain ones.

Thus far, I have two ways of finding that:

1. a bar where all three strips are zero ... this works, without searching for anything else, since that condition ALWAYS ENDS any trade, regardless of what direction it's headed

2. one full previous "apparent" trade ... starting after a maybe-navy, and ending with any of the rules that can end a trade ... which can be count-related, vote-related, or due to cut/grab bands

I've got both of those functioning just fine. However, it seems to require about 60 bars of buffer-warmup, mainly due to occasional very long trend-trades that start before the buffer does. That not only eats up extra calc time, but sometimes may toss out the next historically-valid trade after the long one ends. So ... cogitating some more about it ...

Say that a bull=green Wave is in progress when the buffer begins ... that is, no initial navy bar ... the first bar of the buffer window meets the BgnVot requirement and away it goes. That bright green bar *could* be the actual first one of the wave (if infinite history used) ... or it *could* be a bar somewhere in the midst of a wave that started earlier (ie buffer starts mid-wave). If it is in fact a midwave bright-green that's "pretending" to be a wave-begin, then DOES THAT MEAN the apparent end of that partial-wave is a "legit" end?

I'm thinking now, maybe so ... and if so, then the buffer can be smaller.

What ends a wave?

a. if all three Slope/Stack/BarV strips each =0 (case 1 above) ... valid even with midwave begin
b. if OppositeVotes count hits threshold ... and that would be valid even with midwave begin
c. if Warn-count hits FullX threshold ... midwave begin might make that later, but not earlier
d. if Reversal bar hits ... ie net Vote >= BgnVot in opposite dir'n ... valid even if midwave bgn
e. if Close crosses outside full Grab | Cut outer lines ... maybe later if midwave, but not earlier

... so far so good ... but ...

f. if sum of Entry+Adds-PXits-PCuts-PGrabs drops to zero (ie no more shares in trade), trade is over

THIS is a potential gotcha. If the buffer-window partial-wave begins *after* the "real, full" wave would have (if there was more data analyzed), then some ADDS might not be accounted for. Also, the size of the initial Entry is a function of the net Votes that start the wave ... or related to ToeIn rules. The combos of the Entry size with possible Adds are unpredictable. So, we don't know in the case of the mid-wave-start during the buffer, whether the PX+PC+PG share-reductions are enough to kill off the total shares.

THEREFORE ... it would seem that all of the rules a-e above which end a mid-wave-begin buffer case would be *reliable* flags to indicate that subsequent trades are "legit" and "stable" for output and scan and equity eval purposes.

So ... I'm going to simply turn off that "f" method of ending a wave, UNTIL one of the other a-e methods have ended the wave. This means that the buffer-window can be smaller - I'm changing it to 40 bars ... prelim tests indicate that will be adequate in nearly all cases (30 is so-so).

It also means that the center-line color will work a bit differently. If none of the a-e rules are satisfied during the buffer (unlikely), a white centerline will appear in the output-window Band. If any of those rules have been hit, then any subsequent trade is legit ... and from that point on, all rules, including f, will be active. So, no need for a "black" line.

QUESTION: Can you think of any logical cases that I've missed?
Top of the page Bottom of the page
JimDean
Posted 5/2/2019 3:03 PM (#9580 - in reply to #9578)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Hi, Salim

Here are answers to your prior post, which I didn't see till after my last one:

So, basically, this is a hold placement of some sort of "erratic" behavior of Volume while it is playing it out within itself, until it becomes ruly.

Not really, if I understand you. It's not that the volume is erratic or unruly, nor that the price is. Navy indicates that the three subtotals of the votes are each zero ... or one of the other "end-wave" rules has previously hit, without adequate netVotes to begin a new wave yet.

When these lines appear, I assume it be noted that no trades are to be taken under these circumstances. Buyer/Seller caution placement "at your own risk".

Well ... first, the lines will not appear very often. With the expanded rules that I just posted, that will only happen if the first bars in the output zone are green or red (ie in a wave). If that's the case, AND if the initial bar is bright, then you *could* start the trade if you wanted to. Maybe it would be a late start, maybe not. However, if you're looking at a recent chart (just last 3mo's), then it's very likely that the bright center line will NOT make it all the way to the HRE ... any wave on the left will have almost certainly have ended before the HRE. So ... this is imho a NON-problem, for a trader working from the HRE bar.

Here, I am confused as to why a shorter #of bars shows up with the thin lines, while larger #of bars assures stability, well-noted keeping in mind the warm-up periods.

You've drawn the wrong conclusions. The number of bars visible on the output has NOTHING to do with stability. What matters is what happened BEFORE the FIRST (leftmost) output bar. I showed the final chart just to "reveal" what happened before the first bar of the prior three charts.

Yes, but kind of concerned with the "speed of calcs". Meaning, if you minimize the #of bars, the thin lines begin to appear, maximize the bars, and speed slows it down. Otherwise, yes, the importance is duly noted, and the appearances of thin lines surely helps understand what may be happening behind the scenes (Bars).

IMPORTANT! DO NOT conclude from this that "more bars is better" in terms of the desired output range that you set with the slider. That input should be set for whatever historical window you consider useful and relevant ... in the rare case where a white line appears, an automated strategy will skip that wave ... if you're doing discretionary chart-based trades, as long as the white line doesn't extend all the way to the HRE, you're OK. The "more bars" thing is all happening AUTOMATICALLY, internally, INDEPENDENTLY of your input value. I'd set it at 60 initially ... now I'm using 40 ... and only about 3-5% of the cases have a white line showing up at all ... and in those, it only lasts a few bars then all following ones are "legit".

And, don't fret so much about speed. I'm much more "sensitized" to that than a typical trader might be. I won't distribute a program if it's un-useably slow, at least for "reasonable uses". Most of the robust N strategies will bog down if you create a FL with 3000 symbols, using RT data with 1-min bars. My goal is to assure that TT routines are better than that "typical Nirvana standard".
Top of the page Bottom of the page
JimDean
Posted 5/3/2019 11:38 AM (#9581 - in reply to #9579)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
... mulling-over & consolidating prior ideas into an updated plan ...

The biggest thing is the potential addition of yet another "version" to the pile:
Easy = two Gurus, no expert inputs, no negative slider ranges, no manual-typed overrides
Xprt = Easy + expert inputs with positive sliders only + extra plot option + extra return options
Powr = Xprt + negative slider ranges for guru & expert & CumV inputs + extra plot + extra return
Cstm = Powr + option to manually type overrides for *very* detailed spec's in every area

Main reason for fourth level is that the negative-slider CumV & TymFrm group aren't really "crucial" ... and the negative-slider CutGrab Vote group require the "Robust" TradePlan (supporting Adds & Partial Exits of various types) ... that TP won't be available till much later (this year?). This means that all previous posts that describe the "negative" CutGrab and Vote-group sliders to be "turning off" Partials and Adds and Toe+Cnfrm *now* are *flipped* ... that is, *positive* slider ranges will be the simple non-Add, non-Partial, non-Toe alternates ... Easy and Xprt versions will *only* need to support the simple (standard TP) approach.

This allows me to phase in the features ... I can release Easy and Xprt initially, and later allow people to upgrade to Powr or Cstm once the code and TP's are ready. I'll need to decide whether to move to other routines such as HAT and ADX etc before Powr & Cstm CVW ... since the Robust TP will take a lot of time, it seems likely that the other routines will come first. The biggest downside to this is that once I go to Powr & Cstm for CVW, "porting" those changes over to be echoed in HAT, etc will be messier than if I did the full set of four CVW versions first. Sigh. Need to cogitate on that.

QUESTION: do you think that the insertion of the fourth "Powr" version is unwise. If you do, please explain why in light of the various considerations above.

Also, I need to decide where the "equity filter toggle" feature fits into the set of four versions. That is, the ability for the routine to override entry/exit signals based on how well it's been performing "recently" with those param settings for that particular symbol. This is a big deal since N code *cannot* do it for *any* of their strat's in OT/VT ... and the OV platform calc's are flawed enough to be unusable for this on a strat-by-strat basis. Thus, a unique TT feature that will very likely improve performance. BUT ... there is a lot of code involved to implement this. My leaning at this point is to include it in all four versions of CVW (and in HAT, etc). But I need to do it quickly and cleanly.

The "OScan" feature, which has return-outputs for the various summed-stat's ... used to select symbols for the FL with "decent price-volume-action personalities" in the recent past ... is also a unique TradeTight stradicator feature ... and particularly applicable for Dynamic Scans as well. This is not as complex to code as the equity filter toggling, so I'll get it in right away.

Ideally, most if not all of the internal coding for Powr (and maybe Cstm) can be done during the initial release work ... this makes the code efficiently portable to other HAT, etc routines ... and, as long as one of the outputs specifies the position-size-pct for each scaling-related order (visible in the FL), it could be traded "manually-mechanically" ... that is, the signals etc would be implemented by manual orders to the broker rather than using a Trade Plan. This would *allow* Powr & Cstm to be released early, but I'm not sure if it's wise to do that, since the Robust TP will be delayed a while. The biggest reason to do the coding now is so that the "portable code" for HAT, etc doesn't need to be added (inefficiently) later as a second phase.

So ... I guess that I'll move forward with trying to quickly implement the full scope of Powr & Cstm features now, unless I get bogged down ... fallback to Easy + Xprt only, in that case.

Whatever route I take, I'm still planning for the "version paradigm" to extend to other routines as well ... maybe some routines will not "need" all four, but the conceptual boundaries will be similar re the names.
Top of the page Bottom of the page
JimDean
Posted 5/3/2019 11:50 AM (#9582 - in reply to #9581)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
... updated at the end, since initial emailed post ...

Relative to the prior "big picture" post, I have one thing I need to sort out, for the Easy &/or Xprt versions: Toe + Confirm entry, versus Full entry.

T+C requires a non-standard but not-hairy TradePlan, which I can create (with some effort) in the fairly near term. If I do that, it also will incorporate SmartSizing (see prior posts). It would not support Adds or Partial Exits.

The *biggest deal* re T+C is that it allows blue/purple-band Alerts to initiate a trade, rather than waiting for bright green/red. The Alert fires the "Toe" entry ... significantly smaller than a "full" entry ... and if no green/red appears before a navy, then trade exits on navy without ever being very big.

Another aspect to T+C is that when the first bar is green/red (ie not an alert), then the entry on that bar is the Toe portion ... and the Confirm shares are only ordered if the following bar is also a bright green/red, within reasonable price-limits. So, T+C can minimize losses from "nuisance" trades where a brief move does not follow through ... or when a big gap occurs, it can delay adding in extra shares, until a pullback occurs. This is with the "Simple TP" ... fancier than a standard one, but way less complex than the Robust version.

IMPORTANT NOTE: if T+C is not active, then my plan is to NOT show Alerts on the plot-band or provide Alert-return signal outputs. That is, Alerts are a useless feature (for mechanical trading) unless the TP can *do* something with them. When T+C is not active, trade-entries follow the classical pattern of "all in" on the first bright green/red bar.

SO ... with that background ... the big question is HOW to TOGGLE the T+C vs All-In feature, in the Easy and Xprt versions. Currently, T+C is toggled on when the Fuzzy Xprt slider is Negative (it's N/A in Easy, and only Positive in Xprt). When the GuruVote slider is negative, it defaults the Fuzzy slider to negative ... but the Guru slider is only Positive in Easy & Xprt. The options are:

1. Don't allow T+C at all in Easy & Xprt ... just use the standard TP fill All-In and no Alerts
2. Standardize T+C for Easy & Xprt ... *always* using Toe for initial entry (no All-In option)
3. Somehow toggle All-In vs T+C for Easy & Xprt - if so, using what input?

QUESTION: do you advise 1, 2, or 3? If 3, then how would it be toggled?

Later note ...

This T+C vs All-In option will be part of the "standard portable paradigm", therefore it must be tied to one of the standardized inputs that will be echoed in other programs. Those are the Vote + Fuzzy + CutGrab set (Guru + Experts), as well as the final two that spec bar-window and output type. Specifically, it *cannot* be toggled by any of the TymFrm Guru+Expert sliders, nor by the CumV method slider, since those are specific to CVW.
Top of the page Bottom of the page
JimDean
Posted 5/3/2019 2:25 PM (#9583 - in reply to #9582)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
... read prior post first ... this suggests a possible solution ... updated since emailed ...

Currently, the BgnVot expert controls the way that Adds work, in addition to the BgnVote (and alert) threshold and ALSO the T+C vs All-In entry share-sizing percentages ... that's a *lot* in one input.
Its positive/negative range (Powr+Cstm only), toggles Adds off/on, but *doesn't* toggle T+C.

Currently, the Fuzz expert slider controls how big the fuzz band is ... essentially shifting the waves to the right and filtering out some nuisance trades, for higher slider-fuzz inputs. Its pos/neg range (in Powr+Cstm) toggles T+C vs All-In ... somewhat arbitrary (not really a "fuzz" kind of thing).

Maybe, if I switch the toggling and control of Adds to the Fuzzy slider, and limit the effect of the BgnVot slider to just control Votes and T+C toggle, that would solve this problem:

========

The TradePlan for positive-slider-only Easy+Xprt versions will support a *choice* of All-In or T+C (Easy has no BgnVot slider, but the +1>+6 GuruVot slider maps directly to it, internally). The TP for this will need fewer conditions and steps than the full-smartsizing approach would require, since there are fewer permutations of percentages.
When I get round to releasing TP's for the Powr+Cstm versions, the additional conditions and steps for the negative-slider "smartsizing" would be included.
For Cstm, the current "VFTAX" override (earlier post) will be simplified to "TFV", such that if T=0, All-In is used ... if the override is negative, then smartsizing would be implemented, as some kind of dynamic variant on the specified V,F,T.

BgnVot mapping from +1 to +6 for Xprt, retains the paired many-to-few vote-spec for 1+2=6V and 3+4=5V and 5+6=4V ... with 1,3,5 using T+C and 2,4,6 using All-In ... but *removing* any relationship to Adds-spec or use. Since the VoteGuru "maps" directly to BgnVot expert, this would mean that both Easy & Xprt would be able to toggle T+C off or on, without needing negative slider inputs or manual typed custom inputs.

The *positive* BgnVot slider range would use *fixed* entry sizes: BgnVot slider = 1,3,5 (req's 6,5,4 NetVotes) = All-In at 100,80,60 pct (ie more shares for greater vote-certainty); BgnVot = slider = 2,4,6 (req's 6,5,4 NetVotes) = Toe+Cnfrm at 40+60, 20+60, 20+40 pct.

For Powr & Cstm, the *negative* BgnVot slider range makes the entry size "smart", related to the magnitude of the actual NetVote of the bar: when the NetVote is >= the 6,5,4V (slider=-2,-4,-6) threshold, then the bar's actual NetVote (7-4) will spec "All-In" cases to use 120,100,80,60 pct.
If the Powr slider specifies T+C (-1,-3,-5), then smartsizing maps a Toe-Alert (or first-bright-Toe) to: 40,20,20 percent based on the *BgnVot* thresh (6,5,4V) ... and the followup Confirm bright (if any) would *increase* the position by 80,60,40,20 pct based on the confirm-bar's *NetVote*=7,6,5,4 ... thus the T+C overall entry size could be anywhere from 40T+80C=120% to 20T+noC=20%, depending on how each trade unfolds.

Note that the number of Steps and Conditions in the "Robust TP" increases *significantly* as the maximum-possible total-Entry (ie sum of Toe+Confirm) gets bigger. Dynamic sizing (above) permits a max of 120% ... if more shares are desired, then the "OT base size" (ie shares equiv to 100%) should be increased. Also note that to keep the number of TP steps manageable, all Entry and Add options are in increments of 20%. Although theoretically the Cstm-override for the BgnVot input (below) could spec a total of >120%, the override-spec and rules keep it within that 120% limit.

The Cstm BgnVot-input override supports pos=fixed and neg=dynamic as well: type in TFV where V=the BgnVot threshold = 7-4V (Toe-Alert is one less=6-3, if T>0); T= fixed ToeIn size 0-3, where T=0 turns off ToeIn, and 1-3=20,40,60% ToeIn. For *positive* TFV overrides, F= maximum Final size 1-6 (*20%) ... if T=0 (=> All-In), then F=1-6 means Entry=20-120% ... if T>0 (=> Toe+Confirm), then Cnfrm= (F-T)*20 ... i.e. anywhere from 100%(if F=6,T=1) to 0%(if F<=T).

For Cstm BgnVot *negative* (dynamic-sizing) TFV overrides, T=1-3 ToeIn's work the same (20-60% fixed-size) as described above. If T=0 (All-in, noToe), or when F=Full(2-6) is > T(1-3) (Confirm after a Toe), then the Confirm (or All-In) size is Dynamic, based on the actual NetVote of the Entry|Confirm bar. However, the *Total* (T+C|All-In) entry must be <= 120% (see italics above). Since the highest Confirm size occurs when the bar's NetVote=7, the F-T size is "mapped" to NetVote=7 ... any fewer NetVotes that are >= BgnVote threshold reduce that F-T confirm-size by 20%/vote. Examples:
When dynamic(negative input) with T=0 (All-in) and F=6, then NetV=7-4 creates All-In sizes= 120, 100, 80, 60; if F=3, then NetV=7-4 All-In sizes= 60, 40, 20, 20 (minimum=20). Note that since T=0, Alerts are *not* active ... this All-In entry occurs on the first bright green/red bar.
When dynamic(negative input) with T>0 (Toe+Confirm): if T=1 & F=6, then ToeIn is always 20%, and Confirm-size for bar-NetV=7-4 =100, 80, 60,40; if T=1 & F=3, then NetV=7-4 Confirm sizes= 20, 0, 0, 0 (=> Confirm starts the official green/red wave logic, but shares remain at the Toe size without increasing); if T=2 & F=5, then ToeIn is always 40%, and NetV=7-4 Confirm sizes = 60, 40, 20, 0. Yes, this is sort of confusing, but it's logical and very flexible ... note that only the *Cstm* user needs to understand it, and Help Popup will verify what's going on for any given override input.

------

That BgnVot change will result in moving the Adds-control options to the Fuzz slider ... this *sort of* makes sense, since larger Fuzz settings *shift the wave left* and makes it "more dangerous" to allow many Adds, since it's more likely some would come too late in the trend.

The new Fuzz slider *positive* range would be the same as it is now, with NO Adds active (which fits Easy+Xprt limitations ... the Simple TP doesn't support Adds or PXits. For Easy, the VoteGuru would drive Fuzzy settings as it does now, with no Adds.

The new Fuzz slider *negative* range (Powr+Cstm using Robust TP) would activate Adds. Currently, BgnVot varies Adds sizing, alternating between 60% and 80%, which was fairly arbitrary and occasioned a lot of back and forth discussion (should it be 40/60 instead?). The new approach would use a fixed 60% for the initial Add when the Fuzz slider is negative ... making the max #Adds using Powr-version alternatives be 3 instead of 4 (reduces by 20% each time) ... I feel better about that anyways. This shortens the Robust-TP needed for Powr significantly (steps and conditions).

The Cstm version for the Fuzz input would "inherit" the "AX" override that used to be part of the BgnVot override. "A" explicitly defines the initial Add% to be 0,20,40,60 or 80%; "X" specifies max# adds either explicitly or indirectly by varying the per-Add reduction (20,40 or 60%). The existing PpHhh override would likely change to HhhPpAX. Note that the Cstm version will therefore require a much longer TP, to support all possible Add permutations.

Possibly ... the Cstm Fuzz spec could "lose" the Hhh periods spec, since it's pretty arbitrary ... it defaults to the CumPds which can be overridden via the MAslope input anyways. If I do that, then it would allow the "F" to be moved from the EndVot Cstm override spec "VPMWF", to join the other Add-related specs in the Fuzz field: PpAXF ... F specifies the size of the PXit required before an Add can be triggered, as a fraction of the Add size. This simplifies the EndV override and groups things more sensibly.

==========

Finally, since this calls for BgnVot to go from +1 to +6 (instead of +5), then in order to make the mapping from the Guru simple, I'll expand the VoteGuru range to +6 also.

That in turn calls for the other Vote experts to expand to +6 (and -6): EndVot +6 will spec 4V, and the #M,#W pattern used for 1-4 will be extended into 5-6, rather than using an intermediate value. Negative EndV still will activate partial-exits based on Warns.

The Fuzz input similarly would expand to +6 (and -6) ... re-map the fuzz percentages to allow more refinement and a slightly-tighter percent-range: 0,10,20,30,40,50 (prev was 0-60%)

==========

OK ... I think that solves it.

Yes ... it's messy to describe but, hey, it was messy before, just in a different way ;~)

Benefits:

1. Main thing: allows Easy+Xprt to offer All-In vs T+C, within the scope of positive-only sliders.

2. Distinction between All-In vs T+C(w/Alerts) is more valuable than Add=60% vs Add=80%.

3. Smartsizing distinction for Entries is a nifty feature, deserving of it's own (neg BgnVot) toggle.

4. Big-Fuzz impact on waves semi-logically calls for fewer Adds, ~moreso than #BgnVotes.

5. Adds are "spec'd" by Fuzz, *after* EndVot => more logical since Adds require PXits.

6. Fuzz-input Cstm-override PpAXF groups all Add-related stuff into one entry.

7. I haven't yet implemented the earlier approach, so changing this won't waste time.


QUESTION: do you follow the logic? Is this better or worse?
Top of the page Bottom of the page
JimDean
Posted 5/3/2019 5:37 PM (#9584 - in reply to #9583)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
The attached snap shows the updated parameter pane:

Yellow highlight shows all places that param/label names changed.
Blue highlight shows param's that use -6 to +6 ranges (0 to +6 for Easy|Xprt)
Green highlight shows param's that use -5 to +5 ranges (0 to +5 for Easy|Xprt)

Notes:

1. Biggest change is that I moved CutGrab out of the VoteGuru section (per prior posts). I changed the final section label accordingly. Note that this entire section is part of the portable paradigm.

2. BgnVotNetNatcMny2Fw ... "Natc" is a reminder that besides setting the begin-vote threshold, this also spec's eNtry type as either "All" or "ToeCnfrm". See description in prior post ... Neg inputs activate smartsizing rules.

3. EndVotOpXmwFw2Mny ... "Xmw" is a reminder that besides setting the end-vote threshold, this also counts M's & W's to create eXits. PXits only active with neg inputs

4. FuzBandAddCutSm2Lrg ... since "Sm2Lrg" applies to how the slider affects the Fuzzy Band width, I described how the slider affects Adds by "cutting" their use a small to large amount ... that is, a "large" slider input spec's a wide fuzzy band and a limited number of small Adds (ie Adds are "cut" a lot). This is not ideal but it's the best I could come up with. Adds only active with neg inputs.

Comments?

(Params renamed & rearranged.png)



Attachments
Attachments Params renamed & rearranged.png (193KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/4/2019 11:17 AM (#9587 - in reply to #9584)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
I've meaningfully updated the prior post with the "crib sheet" definitions for the inputs, adding the Cstm section (*lots* of detail), expanding info for Cuts & Grabs, and extending def's for BgnV, EndV, Fuzz inputs to represent the full -6 > +6 range.

Also, I updated the prior post (4/4/2019 3:23 PM #9558) that explains how the Cuts & Grabs lines are spec'd and managed (blue). Crib sheet summarizes that, but it's an important post ... as are the two posts that immediately follow it.

Plot Options: 1=Band, 2=Band+3Strips, 3=Equity, 4=Band+2Hists, 5=MA+Hist Detail ... Easy=1-3, Xprt=1-4, Powr&Cstm=1-5. Pricepane plots: dots on all but 1=Band-Only; C&G lines always if C&G active (input=0 turns them off). So, plot=1 is handy for "filter-only" cases.

Add rule was modified in (4/3/2019 10:28 AM #9552) post - see RED paragraph: Adds (allowed if Fuz slider negative) use next-bar SM orders in RobustTP to assure decent fills, fired from prior-bar signal, as long its C (for Longs) was less than lowest of: highC since bgnTrd, or (C1-PartGrabLine)/2 ... that is, only if the signal-bar C was not exceptionally high. Adds will use next-bar StopMkt-Orders with level set to the Close of the prior bar that signaled the Add ... which usually will prevent a poor price-fill, but definitely prevents a partial-fill (since SM becomes Mkt when triggered).

Mentioned earlier but worthy of repeat: now that the BgnV 1-6 slider alternates between All-In vs Toe+Confirm pairs, note that Alert (blue/purple Band) bars will ONLY be shown (or return-signalled) when that slider spec's Toe+Confirm.

After some further eyeball testing, I tweaked the sequence of MAcalcTypes a bit:
pos1-5= WH, WH&E, WH&EH, EH&W, EH; neg1-5= Wma, W&E, Ema, W&E&S, W&S
... after trying some other combos -6 to +6, it became clear that the extra two were of no use.

=======

Re Equity-Plot option#3 (all versions):

Previously described in posts on 3/28/2019 10:32 AM #9490 and 4/1/2019 4:50 PM #9544 ... here is updated recap ...

Always shown, even if Equity-Vote-Filtering is turned off:

Wide-Band green-to-red ATR-P/L increments = progress of each trade, incl any Add/PX impacts
... Band will be at Zero-line: y-axis will be forced to always extend down (or up) to zero
... Thin vertical lime/forestgrn/dkorng/magenta lines identify Entry/Add/Pxit/FullX bars
Cumulative-Equity line (unbounded y-axis, based on normalized-Equity)
... Normalized/Share: ((XitC$-NtrC$)/NtrC$) / (NtrWTR$/NtrC$) = (XitC$-NtrC$) / NtrWTR$
... Tracking = running sum w/variable shares: %NomShrs * (Cls$-PrvCls$) / BarWTR$
... ... any time Shrs Add|Xit, adjust Eqty sum: +|- Delta%NomShrs * Cls$ / BarWTR$

ALSO shown, when Equity-Voted Signal-toggle mode is active:

When this is active, then prev-described "voting" of slope&stack from Equity-curve MA's will either allow or block "unfiltered" Trades from appearing on price-pane or as return-signals. The equity calc's will continue in the background for *all* trades for that symbol, but the trades will not be "triggered" (via return), nor will they show up on the PricePane, *unless* the filter-voting indicates that the strat+sym performance has recently been *improving* in profitability.

The "fat" trade-progress Zero-Band and Equity-curves will appear as described above, but:
... Only the "triggered" trades will have thin vertical lines (echoed on PricePane by dots+bands)
... Any trades (full or partial) *excluded* by the filter have a thin white line thru the Zero-Band
Two additional Equity-MA lines will appear (based on all "background" trades)
... Equity Wma calcs *ignore* non-trade gaps (via pointer-chain)
... Fast=Wma(X), Slow=Wma(Y), where X=2,3,4 & Y=4,5,6 as func(SlowCumMA pds)
... Eqty & MA slope-colors: Eqty= Lrs(Y+2); FastMA Wma(Lrs(2),2); SlowMA Lrs(3)
... ... implies that max of current + 5 prev E's must be pointer-accessible for Wma & Lrs calcs
"Triggered-Trade" net-Equity Histogram:
... Histo colors: green/red= rising/falling NetE; blue= flat NetE (typically means not in trade)
Background full-height wallpaper (histo):
... Colors re trades: darkgreen=allowed, darkred=blocked, darkgray= late-start/early-end
... mid-trade start/end based on the "C" control override parameter setting
Top of the page Bottom of the page
JimDean
Posted 5/6/2019 5:30 PM (#9588 - in reply to #9584)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Lots of progress over the last couple of days ...

First: significant changes (refinements) to the "crib sheet" a couple of posts ago (5/3/2019 5:37 PM #9584) ... not just syntax ... the actual rules have been enhanced as well as the descriptions.

I've done the busywork to get all the negative-range Powr variants and all the manual-typed Cstm-overrides properly "parsed" from the input, with appropriate checking for validity, along with a bunch of pop-up error messages that inform a user if they've entered a value that is invalid for a given Version ... negatives only for Power, typed overrides only for Custom, etc.

I found a BUG (!) that apparently crept in a couple months ago, regarding how the Stacking votes were being handled (your beta VOLeval was correct). It was a typo that involved a grand total of six characters ... but once fixed, it made a *major* change to the output (for the better) ... in general, both entries and exits skootched left a bit. Hooray!

Once I got that fixed, I double-checked the CumMethods, and it became VERY clear that the "raw volume" (CumMeth input +6) was pretty much useless. Since CumMeth -6 was also pretty silly (average of 8 other methods), I cut that slider down to -5 > +5.

I fiddled with expanding the range of the TymFrm Guru & its Experts to -6 to +6, but decided to keep them as is. I feel very confident about those sliders now.

The Warmup Buffer took considerable effort, but it's working well now, with a "minimal" (typically 40) number of extra pre-output bars ... the white line shows up rarely, and even then, only for a few bars on the far left of the chart. When used with the Both / LongOnly / ShortOnly distinctions (BarWndo slider), I allow "both" during the buffer to get earliest possible stability, then switch to LO|SO if requested by BarWndo. Nifty.

Full day spent on refining the rules related to BgnVot, EndVot, and FuzBnd ... with their associated , Dynamic-Entry-Sizing, Partial-Exit and Add-On negative-slider toggles. And their extensive+flexible manual overrides. The parsing process forced me to think the entire paradigm through very thoroughly, yet again. Several tweaks, all for the good. Shifting the Add-spec over to the Fuzz slider
turned out very nicely ... the Bgn slider now spec's All-In vs Toe+Confirm, and Dynamic Sizing.

I reviewed the conversions from Med-to-Warn and Warn-to-FullX very carefully, and found a case I'd overlooked before: an "Alert reversal". It had been possible for a blue/purple Alert to be active, and immediately switch to the opposite Alert color, or to the opposite Wave color. If Toe+Confirm was active, the TP could not handle the "pure reversal" ... so the code now forces a black bar between the two, allowing one trade to exit and the next to start.


The only input that I've just got rudimentary support for so far is the new CutGrab slider and its manual overrides. I've fully defined the override spec (which is the heart of the CG algorithm). I plan to finish that tomorrow AND hopefully get the code written to draw the four lines on the pricepane. Fingers crossed!

REQUEST: please carefully review the updated "crib sheet" and tell me what is hardest to understand.

Top of the page Bottom of the page
JimDean
Posted 5/7/2019 8:06 PM (#9590 - in reply to #9588)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
I think that last night I came up with a good approach for the Master slider, which if I don't use any pre-testing, will provide a handy one-slider "journey" through the full spectrum of Easy-version input-permutations ... at *most*, there are 5 CumMeth * 5 TimeGuru * 6 VoteGuru * 6 CutGrab = 900 permutations. Since these inputs are in ALL the versions, the same (hardcoded) Master arrangement could be used for all of them.

If it turns out from testing that a large portion of those 900 have relatively little effective difference, then *hopefully* I'll shrink the Master-spectrum (in an orderly way). That is, maybe I'd leave out the Time=2 & 5, &/or Vote=1 & 6, &/or CutGrab 1 & 6 (refer to crib-sheet comments above, to see why those would be the ones I'd initially target). Eliminating all of those would reduce the canned Master-set to 5 * 3 * 4 * 4 = 240 cases (much more manageable).

Later on, if time permits and user-interest warrants, I could do extensive studies starting from those 900, then applying Expert-input fine-tuning, on literally hundreds of thousands of other permutations, to come up with some "recommended" patterns for various scenarios. Those would be sold to users optionally via a licensed Text file ... they'd be accessed via a typed negative Master-param input. I described in detail how those tests would be automated, in a post some time back. Selah.

The *arrangement* of the canned Master-slider options likely would be "tiered", with the "default" being in the center: Master# = 120 would represent CumMeth=3 (average), TimeGuru=3, VoteGuru=3, and CutGap=3 (ie if all Guru and Expert inputs are zero).

With that as a starting point, I will likely expand outwards to the right (ie Master=121+) by increasing Time, and to the left by decreasing Time (at the top level of permutation-tiers), using Time inputs of of 1,3,5 (or maybe 2,3,4 if 1 & 5 are too extreme).

Within each Time-Tier, I'd likely vary the VoteGuru next (values of 2,3,4,5). Within each Vote-Tier, I'd vary the CutGrab values (2,3,4,5). And within each CutGrab-Tier, I'd vary the CumMeth values (1,2,3,4,5).

Another approach might be to use the CumMeth's as the Top tier ... hard to say ... when I asked about this a long while back in a post about more SBAS testing, I seem to recall that Ken(?) thought it would be better on the bottom.

If I want to cut the Master-Set permutations further, from 240 to 192, then I'd reduce the CutGrab tests to 2,3,4 ... note (from the crib sheet) that those inputs are "in pairs", so 1~2, 2~3, 3~4 ... where 1,3,5 "time-tighten" quicker than 2,4,6. If I cut out anything else, it would mean either that the Master set didn't contain the "basic default pattern" at all ... or it would mean that some key "logical" distinction would have an unbalanced representation (such as All-In vs Toe+Confirm, or Fosback vs Granville).

Final option ... I could vary CutGrab WITH VoteGuru ... that is, when VoteGuru=3, CutGrab also would =3. I'd model all six in that case ... all logical distinctions within a given param would be represented, but NOT all the permutations. That way, the MasterSet would have either 5 CumMeth * 5 TimeGuru * 6 VoteGuru+CutGrab = 150 permutations, our would have 5 CumMeth * 3 TimeGuru * 6 VoteGuru+CutGrab = 75 permutations.

QUESTION (please answer asap): do you think I should set up Master for 900, 240, 192, 150, or 75 options, per the description above?

Note: I don't have time to do a bunch of testing first. So, please thoughtfully study the crib sheet and logic it out. Please spend at least 20 min thinking about it before responding. Thanks!
Top of the page Bottom of the page
JimDean
Posted 5/8/2019 10:16 AM (#9591 - in reply to #9590)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
... Salim preferred the 240 or 75 options, re the question in the prior post ...

While creating the Master-Set lookup table, I realized that my earlier decision to expand the BgnVot from +1 > +5 to +1 > +6 so that "Toe+Cnfrm" and "All-In" each had three options (which domino'd to increasing EndVot to +1 > +6 and increasing FuzAdds to +1 > +6) has ended up creating a "conceptual problem" (at least from my pov).

The concept that I typically use is to set up the sliders so that the "center" value (ie 3 in range of 1-5) represents the "recommended generic default". With the TymFrm group and the CumMeth slider all going from 1 > 5, that works fine. But with the VoteSpec group and the CutGrab slider going from 1-6, it becomes "awkward" since there is no clear "center".

This really showed up as an "issue" when I used Excel to map out the Master-set variants. No matter which of the options (900, 240, 192, or 75) that I used, the "center" of the Master range was NOT the "recommended generic default" setting of 3,3,3,3.

So ... I went back to the original post (5/3/2019 2:25 PM #9583) where I discussed the change from BgnVot 1-5 to BgnVot 1-6 ... as mentioned above, the "logical trigger" for that change was the presumption that, by using the slider-range to not only choose BgnVot thresholds but also to toggle between Toe+Cnfrm & All-In Entries, that I should EQUALLY represent both of those Entry methods ... thus three pairs of two.

From that decision, all the other changes flowed (see prior post for details). HOWEVER, upon rethinking it today, I am coming to the opinion that there is *no need* to equally emphasize the two Entry methods in the slider-range ... especially since I need to pick ONE of them as the "recommended generic default". And, if I'm using one as the "recommended" case, then it follows that if either of the two methods should have a bit of "extra" emphasis in the slider range, it should be that default.

So ... my own (conservative) bias, especially since it can be handled by a relatively simple initial-release TP, is that the Toe+Cnfrm approach is better, for two reasons:
1. since it activates "Alerts", that means a decent # of trades actually start a bit earlier
2. it emphasizes the "money management" bias that I want TradeTight to champion

Based on that, and since I want the "center" value = 3 to be the "recommended" one, and since I want the Master slider's center value to be the 3,3,3,3 case ... I'm going to change the BgnVot, EndVot, FuzAdd, and CutGrab sliders "back" to a 1-5 range. Specifically:
1. BgnVot 6 gone ... BgnVot 1-5 remain as-is w/ 3:2 bias for Toe+Cnfrm, and 2:1 bias for 6,5V vs 4V
2. EndVot 6 gone ... EndVot 1-5 remain as-is (EndVot 5 uses 4V,4m,4w,30% ... reasonable endpoint)
3. FuzAdd revised "back" to 1-5 ... FuzPct=0,15,30,45,60 (was 0-50); Initial-Add%=80,60,60,40,40 (removed final 20); PX% req B4 next Add #8ths = 2,3,4,5,6 (removed final 7).

The *overrides* for these three *remain the same* re rules and range, so in the big picture (Cstm version), there is no loss in flexibility.

Finally, the new CutGrab slider also needs the 1-5 range (for similar center=3 reasons). It has not yet been coded (so it's "easy" to change) ... its **current** 1-6 definition is:
=== CutGrabGapSzSm2Lrg- positive 0-6 Full CutGrab incrsg InitGap & decrsg Tytn (0=off)
... ATRgaps: 1&2= 4xFG,2xPG,1.6xPC; 3&4= 6xFG,3xPG,2.4xPC; 5&6= 8xFG,4xPG,3.2xPC
... PC,PG,FG FastTytn%InitGap/bar: 1,3,5=-24%; 2,4,6=-20%; Med=half if abs(G-G1)<ATR/2
... FC BrokerInitSMgap 1-6= 2.4x to 6.4x; @addTytns -0.3 to -0.8 (no FC Tytn/bar)

Again, this slider offered "pairs" where 1,3,5 tightened faster than 2,4,6 ... and each pair had a "thin and wide" gap-option which in retrospect was sort of a knee-jerk reaction to how BgnVot and EndVot were set up. Since the CutGrab "Bands" slider is really independent of the rest of the program's logic, there's no need for this. So, I'll modify the CutGrab definition to be "smooth" from 1-5, which remains in line with the spreadsheet-study that I did:
=== CutGrabGapSzSm2Lrg- positive 0-5 Full CutGrab incrsg InitGap & decrsg Tytn (0=off)
... ATRgaps 1-5: FG=4x,5x,6x,7x,8x; PG=2x,2.5x,3x,3.5x,4x; PC=1.6x,2x,2.4x,2.8x,3.2x
... PC,PG,FG Fast Tytn%InitGap/bar: -24%,-23%,-22%,-21%,-20%; Med=half if abs(G-G1)<ATR/2
... FC BrokerInitSMgap 1-5= 3.2x to 6.4x; @addTytns -0.4 to -0.8 (no FC Tytn/bar broker orders)

========= New Master-param Name: MasterTymVotGapMeth ============

The new Master param-name reminds the user of the "sort tiers" that are the basis of the sequence.
The Master slider center will have "center=3" values that are the recommended ones. The updated Master-slider layout options are:

Full: 5 Time * 5 Vote * 5 Band * 5 Method = 625 in all, with center=313
... a bit large, but no corners cut, so handy for optimization-studies

SML: 1,3,5 Time * 1,3,5 Vote * 1,3,5 Band * 5 Method = 135 in all, with center=68
... nice intermediate number, but 1,3,5 Vote *only* uses T+C entry (not sure if that's OK or not)

Balanced: 1,3,5 Time * 5 Vote * 1,3,5 Band * 5 Method = 225 in all, with center=113
... this includes the "All-In"; since Time & Band use "smooth" logic, 2 & 4 skip is OK

ALSO, if I use the balanced approach, it's very easy for me to expand the Master-set slider to negative values (-1 to -225) for the Powr & Cstm versions (which model Adds & PXits and PCuts+BGrabs) ... having a Master set for those variants offers optimization-run benefits.

Comments? Do you concur with the decisions to return to 1-5 range for Vote and Band sliders, and to use the 225-option "Balanced" Master?

... attached spreadsheet maps out the various Master sets that I considered ...

Attachments
Attachments CVW Master Tables.xlsx (255KB - 0 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/9/2019 2:16 PM (#9593 - in reply to #9591)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Two new things ... one simple, one pretty cool ...

When Toe+Confirm is on, current definition says that the first bright green/red after a navy, which starts a wave, will be the Toe size ... and if another bright immediately follows that, it will be the Confirm (otherwise size remains Toe). I'm changing the Band color to represent that:
If Toe is on, the first bright grn/red bar of a new Wave will be lightblue/violet ... ie a brighter version of the related "Alert-Toe" color. Also, the Return signal will identify that bar as a Toe.

=========

I've been studying these CumV charts and formulae soooo long now, that I've realized I think I can create my own "Dean" formula for CumV that will blend the best features of all the others, and incorporate a bit of extra smarts along the way. Here are the considerations for how I'll create a hybrid price- direction & magnitude multiplier:

1. OBV and VPT are "purely" inter-bar. AD & III are "purely" intra-bar. The Dean variant should incorporate *both* inter (current vs previous) and intra (OHLC of current) smarts.

2. I've long believed, and have proven, that the Guts price is more representative of the bar as a whole than the Close is ... the core of that thinking is that what happens during the Body of the bar is more significant than what happens in the tails. The Dean variant should incorporate a bias from what the Body is doing (open to close), moreso than what the H & L or gap are contributing.

3. Aside from the time of the Close, on most days, the second most liquid time is at the Open, as prices adjust for overnight changes. Therefore, the opening gap (prior-close to current open) magnitude and direction should influence the CumV, not just the price action on the current day.

Those three considerations were the basis for my initial formula, which weighted the Body effect twice as much as the opening Gap effect. The resulting formula is fairly simple:

denominator = H-L + abs(C-O) + abs(O-C1) ... "doubles up" the body portion of the H-L range, and adds the absolute value of the overnight gap
... previously I'd used TruRng+abs(C-O) ... this new version is sometimes a bit smaller, when O is not at the extreme C1-side of the current bar's range. All the positive-slider options are nominally based on H-L rather than True Range, so I tweaked this to make that clearer.

numerator = Body*2 + opening-gap ... idea is that most of the action occurs during the day, within the body prices, but a meaningful amount also occurs at the open. The numerator is directional (denominator uses abs to remove directionality).
... so, numerator = (C-O)*2 + (O-C1)

Combined
( (C-O)*2 + (O-C1) ) / ( H-L + abs(C-O) + abs(O-C1) )
... which simplifies to: ( 2*C -O -C1 ) / ( H-L + abs(C-O) + abs(O-C1) )

I call this the "Dean BG" (BodyGap) method.

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

However, as I studied the charts and effects more carefully during reversals, paying special attention to Doji's, I saw a third factor that seemed worthy of considering ...

4. The relative length of the tails (wick and shadow) have a significantly useful predictive impact ... good examples are Gravestone (long wick) & Dragonfly (long shadow) Doji's. If price "tries" to move a long ways in one direction within a bar, but *fails and returns*, that's an indication of weakening or reversal in the attempted direction. Probably (imho) the volume during that process is greater when the price *returns* from the failed excursion, than it was when it made the initial attempt. Therefore, the Dean variant should take that effect into account.

5. The relative weighting of these factors in the numerator should be: most = Body, moderate = opening gap, minor = tail excursions. The denominator should be representatively weighted to normalize the combo of those three, but be unsigned.

Folding those ideas in with the ones used in the BG equation above ... slightly different denominator (since the negative slider options *do* use True Range), plus an extra half-weighted term for numerator:

denominator = TrueRange + H-L ... this "doubles up" the body-portion of the TrueRange, which includes the overnight gap (if any) ... it also "doubles up" the tails portion of TR, to balance out the absolute value of the Dragonfly|Gravestone "RevTails" component.
... TrueRange = max(H,C1) - min(L,C1):

numerator = Body*2 + OpeningGap*1 + RevTails/2 ... double-weighted Body, std-weight Gap, and half-weighted "doji-tail" effect, to represent the theoretical volume associated with each:
... RevTails = ( max(O,C) - H ) + ( L - min(O,C) ) ... which is equivalent to: L - H + abs(C-O)
... so, numerator = (C-O)*2 + (O-C1) + RevTails/2 ...
... ... (expanded) = ( 2*C -O -C1 ) + ( max(O,C) - H ) + ( L - min(O,C) ) /2
... ... and since max(O,C) - min(O,C) is exactly the same as abs(C-O), then ...
... numerator = ( 2*C -O -C1 ) + ( L - H + abs(C-O) ) /2

Combining numerator and denominator:
... ( 2*C -O -C1 + ( L-H-abs(C-O) )/2 ) / ( TrueRange + H-L )

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

I've tested these out on a bunch of charts and they both seem to have noticeable advantages over any single one of the other four formulae. Between the two, the BG had a bit less entry/exit lag, and the TrueRange version of it had a bit less nuisance chop.

So, I created a THIRD version, which simply averaged the two (using the TrueRange denominator which is very similar to the BG denominator, as noted above) ...

( ( 2*C -O -C1 + 2*C -O -C1 + ( L-H-abs(C-O) )/2 ) / 2 / ( TrueRange + H-L) )
... combining terms ... ( 4*C -2*O -2*C1 +(L-H-abs(C-O))/2 ) / 2 / ( TrueRange + H-L)
... "simplified": ( 2*C -O -C1 + (L-H-abs(C-O))/4 ) / ( TrueRange + H-L )

Admittedly this formula looks like gobbledegook ... but hopefully the step by step rationale is clear.

I'll call the combined version the "Dean BGT" (Body, Gap & Tails) method ;~)

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

I'm still pondering which of these to use in CVW, and where.

Comments? Is my logic sensible? Is my math correct? What do you think the slider should map to?
Top of the page Bottom of the page
SalimHira
Posted 5/10/2019 3:34 PM (#9602 - in reply to #9178)
Subject: CVW Archived Devel Discussion



Veteran

Posts: 176
100252525
Location:
USA: MD, Columbia
+3
Focusing mainly on the FIRST pair (+3 Avg and +4 Dean BG), which one is "better" overall?

-4
Now, focusing on the Second pair (-3 Avg and -4 Dean BGT), which one is "better" overall?

This respond, I am reviewing again - still leery as very, very close to each other, but my bias still leans towards -4... but than, again, it calls for a specific situation for that "little edge" that is throwing me off, that I cannot seem to nail what it could be where they differ btwn -3 & -4.... while processing thru my mindset.

... finally, which seems better: +3 Avg(5+), or -4 Dean BGT ?

It's a tough one, but I lean toward -4.
Top of the page Bottom of the page
JimDean
Posted 5/11/2019 9:07 AM (#9605 - in reply to #9602)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
... Important ... four new Band colors ... confirm understanding and visual distinctions ...

Recall that the new BgnVot slider specifies Toe+Confirm for inputs 1,3,5 and specifies FullEntry for inputs 2,4. Alerts are turned OFF when the input is 2,4 since they don't *do* anything. Alerts are ON for 1,3,5 since they indicate a ToeIn-sized Trade. But also, if there is was no Alert active on the bar just before the first Bright grn/red of a new Wave, then if T+C is spec'd, the *first* Bright grn/red is *sized* as a ToeIn ... and *if* the *very next* bar also meets the Bright NetVote >= BgnVote rule, then it becomes a *Confirm* order that "boosts" the position size. However, if the next bar after the first-bright-Toe does not meet that rule, then the Wave continues, but it's only using the Toe size. Either way ... later in the Wave, after a Warn has hit followed by a bright, there could be an Add ... but that's unrelated to the T+C.

So ... a while back when I formalized the T+C option as a part of the slider, I mentioned that I was going to create a new pair of Band colors, to indicate *when* the first-bright grn/red of a new Wave was to be sized as a ToeIn, rather than a full-Entry.

As I was implementing this, I realized that in the case where T+C is active, then there *also* needs to be yet another new pair of Band colors to indicate when a Confirm bar occurs ... it's either the first (>=BgnVot) bar of a wave, just after an Alert ... or it's the second (>=BgnVot) bar of a Wave that started with a >=BgnVot Toe. Just the fact that it takes that many words to describe it, is evidence of the *need* for distinct colors to remind the user what's what, for T+C models.

That's in place now. The colors for the "normal" Alerts (which are sized as ToeIns) remain unchanged ... purple and blue. The new colors for ToeIn from the first bright of a new Wave that doesn't have an Alert preceding it are *lighter shades* of purple and blue ... VB knows them as "mediumpurple" and "dodgerblue". And, the new colors for a Confirm (described in prior paragraph) are bright purple ("thistle") and bright blue ("deepskyblue"). All the other colors are the same.

This does NOT affect any colors or bars, when the BgnVot slider = 2,4 ... that is, if a Wave begins with a bright-green or bright-red as before, then a Full-Entry size order is associated with it.

Note that the Return values also have been modified to clearly distinguish between Toe-sized, Confirm-sized orders and Full-sized orders (I'll detail those distinctions some other time ;~)

I'm attaching two identical charts for you to review. The first one is annotated, noting which bars changed ... the second one is clean so that you can view it unobstructed.

1. Are these color distinctions clear?
2. Can you clearly tell the difference between the new mediumpurple & dodgerblue and the previously-used Alert colors?
3. Are the new ToeIn colors sufficiently different from the other Wave colors that you can distinguish them?
4. Are the new Confirm colors (thistle & deepskyblue) sufficiently distinct from the other colors that might be adjacent to them?
5. Is the overall color-scheme nifty and pleasing, or is it too confusing?


PS: there are now a total of 18 colors (!) used in the Band. I'm pretty pleased about the mix ... and what seems to me to be very clear way it communicates what's going on. This color-mix will be a part of the "standard paradigm", so it's important to be "picky" about shades and hues. Thanks for your help!

(New Toe & Confirm Colors, annotated.png)



(New Toe & Confirm Colors.png)



Attachments
Attachments New Toe & Confirm Colors, annotated.png (63KB - 0 downloads)
Attachments New Toe & Confirm Colors.png (21KB - 0 downloads)
Top of the page Bottom of the page
SalimHira
Posted 5/11/2019 10:17 AM (#9606 - in reply to #9178)
Subject: CVW Archived Devel Discussion



Veteran

Posts: 176
100252525
Location:
USA: MD, Columbia
1. Are these color distinctions clear? YES.

2. Can you clearly tell the difference between the new mediumpurple & dodgerblue and the previously-used Alert colors? YES

3. Are the new ToeIn colors sufficiently different from the other Wave colors that you can distinguish them? NOT THE MEDPURPLE - tends to blend in, having trouble with that - not strong enough (distinguish as the medblue).

4. Are the new Confirm colors (thistle & deepskyblue) sufficiently distinct from the other colors that might be adjacent to them? YES

5. Is the overall color-scheme nifty and pleasing, or is it too confusing? YES, NIFTY... matter of getting used to it.

consolidated from later ... regarding the followup post below, with 15 more charts
I concur with your thoughts, and plot 3 visuals are sound and seems like winner. Btwn plot 4 and 5, my leaning is towards 4. Hope it helps. Thanks.
Top of the page Bottom of the page
JimDean
Posted 5/11/2019 11:23 AM (#9609 - in reply to #9178)
Subject: CVW Reference Information



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
OK ... this is the LAST post about this ... but it's VERY important imho so I want to get it right.

Currently, per prior posts, I've expanded the CumMethod options to -6 > +6 range, where -4=Dean BGT, -3=Avg(5negs), +3=Avg(5pos), +4=DeanBG.

Prior responses have indicated that +3 (avg of 5pos) is better than +4 (simple Dean), and that -4 (fancy Dean) is (a bit) better than -3 (avg of 5neg's). My opinion differs a bit ... I think the Simple Dean BG has some nuances to it that make it more attractive (related to Warn PXits and Toe entries) than I think may have been considered. But the jury is still out ;~)

I would like to SIMPLIFY, by removing things that really don't contribute a useful distinction, if possible ... it would be nice to go back to a Method range of -5 to +5 (for several reasons). And btw ... switching the code back is pretty straightforward so that is not an issue.

So, I've attached a zip file with **15** charts in it (please review them all). I'm attaching just one, with a "legend" for interpreting the 5 plots per chart. Note that the third plot is a brand new one that you've not seen before ... its the average of NINE calcs ... the Dean BGT plus the four Classics (positive) and the four Guts/TruRng negative-variants of those classics.

Note that these charts all use the new Toe/Confirm colors, which should help clarify your evaluations ... note that when a wave (usually short) just starts with a Toe and no Confirm appears, then the impact of that wave (usually not very profitable) is lessened, since the size is smaller.

Also, pay attention to where the dark-green/red bars occur ... those are partial-exits, and their placement should be a factor in your evaluation. For example, in the HAS chart, a long Jan trade shows two dark green PXits at very useful places, for plot #5 (that are not present on the other options).


I would like to eliminate two of the current options ... my initial thought is (using prior responses as the basis ... I haven't done my own review yet) that if the Dean BGT is as good as the prior opinions seem to indicate (or maybe the Dean BG), then I can make that the +3 default ... if so, I'd use the new Avg of Nine as the new -3 value ... the Dean BG (or BGT) and the two separate Avg's would go away, and the CumV slider would be back to a more-manageable -5 to +5.

If I make the change, then plot #3 and either (plot#4 or plot#5) will be the "keepers"

However, if it doesn't work out and if there's clear benefit to keeping it as is, I can do that too.

I promise that this is the LAST go-around on this. I'm pretty enthused about my own CumV formula creations, naturally ... but I won't be insulted if I need to kill them off ;~)

(Attempt at Meth=-5 to+5 range - QCOM.png)




Post moved by on 6/27/2019 1:15 PM from Custom TradeTight Routines > Tools In Team Development > CVW Reference Information


Attachments
Attachments Attempt at Meth=-5 to+5 range - QCOM.png (43KB - 0 downloads)
Attachments Attempt at Meth=-5 to+5 range - 15 syms.zip (380KB - 1 downloads)
Top of the page Bottom of the page
JimDean
Posted 5/12/2019 7:30 AM (#9613 - in reply to #9593)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
I haven't heard from Ken (understandably). Salim, thank you for the time you spent reviewing this. It's clearly *the* most important input. In a way, I'm glad it's such a close call between the options ... that means presumably that all of them are workable. I'm going back to the original -6 to +6 arrangement, with Avg's as #3 default, and Dean adjacent to them as #4 (http://tradetight.org/forums/thread-view.asp?tid=1432#M9600). Selah. Moving on ...

Getting ready (probably later today) to implement the four bands for Cut and Grab. Partials only if neg sliders, Full Bands always.

Our plan was to do Full Grabs (furthest below Long price) differently re tightening, so it could be a broker stop; unchanging gap with each new PX-order Step, only changing (tightening) with each Add. Broker stops use TP Order-menu gaps (smaller for each Add). So, the line would be less fluid and spend a lot more time a lot further away from price (for a profitable run) than the others.

But I hadn't considered the Broker line would work for a no-Adds Simple TP model. Sigh.

For the Simple TP, the Full Grab Broker line will be a *fixed* stop based on the last Step where an Entry was made (Toe, Confirm, or Single). It won’t rise with price since there are no Add steps to reset it. So - the “Broker Full Cut” line will really just be a “Fixed Stop Loss” line, for Simple TP - with maybe one small, early ratchet up on the Confirm Step (if T+C used).

So - I’m thinking that the planned model needs to change. I think that the Full Cuts line should be virtual using Mkt orders like the other three lines. Additionally, a Fixed-Stop line based on Broker stops as described above can be implemented. So, if Full and Partial Cuts and Grabs are all active, there would be five lines, four of which "track intelligently" with price.

ALSO: I’m trying to figure a way, using only the slider, to toggle “just Cuts” vs “Cuts and Grabs”. Maybe using "staggered pairs" sort of like Bgn and End Vote (1=24%gap,C+G, 2=24%,Conly, 3=22%,C+G, 4=22%,Conly, 5=20%C+G, 6=20%Conly. That would change the slider to -6 > +6, but the Master sampling would still be 1,3,5 I think (with C+G).

Or, I could extend the range so 1-5 is both C+G (24%,23%,22%,21%,20%), and 6-10 is just Cuts. I don’t see any logic in offering just Grabs w/o Cuts. (Of course the neg/pos slider already toggles Partial C+G on/off).

The PROBLEM either way is that I need to decide if the Master-mapping needs to grow, to represent both C+G and Conly options. If I just use -6 to +6, then 1,3,5 would have both G&C, and those COULD be the ones used by the Master, with Conly not represented in Master patterns.

Do you think that Just Cuts is an important toggle for the non-Custom user?

Do you prefer the paired 1-6 option, or the extended 1-10 option, and do you think Master needs to include samplings of Conly as well as C&G?
Top of the page Bottom of the page
JimDean
Posted 5/12/2019 8:23 AM (#9614 - in reply to #9613)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Regarding Medium-to-Warn counting.

Currently, when the Med2Wrn count-threshold is met and a Med triggers a Warn, the Med-count is reset to half of the threshold. That is, if the threshold for Med2Wrn = 4, after it creates a Warn, the count moves back to 2 ... requiring two more Med's to create another Warn ... that assures at least one med between successive count-gen'd Warns. If the threshold =3, the reset goes back to 1.

I'm rethinking this ... I think that it's too loose. Instead of resetting the count back to half of the threshold, I think it makes more sense to just decrement the count by one. That way, if another Med (decreasing) fires right away, another Warn is generated. Otoh, if a bright (increasing) appears before another Med, then yet another decrement is applied to the count, so after that it takes more Meds to create a Warn.

Similarly, if a Warn fires due to the OppVotes hitting the Warn threshold (unrelated to Med2Wrn counting), the current logic resets the Med2Wrn count (whatever it may have been) to half the threshold. Again, I think I should tighten that up ... if a Warn fires due to OppVote count, then I think I should force the Med2Wrn count arbitrarily to the Threshold-1.

These two changes will mean that more "back to back" Warns will occur, when the NetVote is consistently getting worse. This will create earlier exits and maybe a bit more chop. Keep in mind that the Med2Warn = 3,4,3,4,4, as the EndVote slider goes 1,2,3,4,5.

I've tested this on the 15 charts for EndVot slider= 1 & 3, new version vs current. In *many* cases, the change provides a beneficially-earlier full exit (by one bar). In a *very few* cases, for the Slider=1 input, the change causes a continuous run to get chopped in half (ie exit then immediate re-entry). And in some of those cases, price was fairly flat anyways during the brief hiatus.

So, it looks like this tweak is a good one.

No changes to the Wrn2FullX rules ... they currently only decrement by one when a bright occurs.
Top of the page Bottom of the page
JimDean
Posted 5/12/2019 11:47 AM (#9616 - in reply to #9614)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
I'm moving into the trade-modelling stuff now. A *crucial* aspect to this, both re plotted "dots" and re equity calcs, is to know whether the order type for Entry/Exit is MOO (ie order fires on Open of bar just after the Signal bar), or MOC (ie order fires at Close of the Signal bar).

MOO is the "goto" N solution, for all its platforms. Calc's are done overnight (for daily bars), and responded to at the next open. For intraday (such as 10 min) bars, the equivalent is a BOO order.

MOC is possible in OT for daily-bar *entries* using AutoTrade to download data and run the calcs at a predetermined time of day (say, 3:45pm for a 4pm close). However, AutoTrade does NOT explicitly control times for Exit orders ... technically, any time a download and recalc is done during the day, then the so-far-Last price of the bar "looks like" a Close price to the calcs ... and therefore if an exit rule is met by that Last price, OT could trigger an Exit order *long before* the Close (if say a download and recalc was done at 11am or 1pm or whatever).

So, for the Stradicator to properly handle MOC orders in an "unknown" environment, it needs to know NOT to fire Exits too early. Presumably (I haven't tested this yet), if AutoTrade is set up to process potential new Entries at say 3:45pm, then that same download/recalc would ALSO cause the TradePlan to do its thing. So ... making sure a download+recalc *IS* done each day at an appropriate time before the Close is AutoTrade's job. But ... making sure that orders don't fire due to arbitrary-user-initiated download/recalcs BEFORE that time is the Stradicator's job.

Fortunately, OT has an internal table for when Sessions begin and end for each Exchange, and each day of the week. Also fortunately, OLang's native time functions are keyed off of the BAR's time, not the computer's System Clock. So, handled properly, OLang can exercise the necessary control for Daily bars without requiring the user to tell the Stradicator about their time zone or exchange sessions. This post outlines how those time functions work:
http://tradetight.org/forums/thread-view.asp?tid=1441#M9615

There is no equivalent "BOC" order type, for intraday bars ... just BOO. However, there is no actual time gap between the close and open of two intraday bars (on the same date), so the distinction is arbitrary anyway.

*** Which brings me to the main reason for this post ***

I think that the "standard Stradicator paradigm" should somehow EASILY allow the user to choose between MOO and MOC order-types and times, for daily bars. Intraday bars would use BOO orders instead of MOO, and would use specially-managed Mkt orders to simulate a "BOC" order (up to user to assure that machine is fast enough to do the calcs in whatever pre-end-timegap is made available for intraday-bars.

If I can get the managed-Mkt BOC thing to work for intraday, then it could most likely be used also for daily bars (EOD or RT), which would simplify things significantly. So that's what I'll shoot for.

The user needs to somehow SPECIFY which (MOO or MOC) to implement. And I don't think this should be relegated solely to the Cstm user ... it needs somehow to be part of one of the "paradigm" sliders. The last two sliders are already chock-full of positive vs negative and override features, so they are out. The CutGrab is similarly replete with features, so it's not a candidate. Fuzzy neg toggles on Adds, and EndVot neg toggles on PXits ... both of those are crucial so I can't mess with them.

What's left is BgnVot. Currently, when BgnVot < 0, it toggles the "cutesy" Dynamic Sizing thing described in an earlier post ... ie the Confirm and All-In size%'s are a function of how many actual NetVotes appear on the bar. But imho that's not very important and actually could be counterproductive. Also, there's a later potential (with Robust TP and maybe Simple TP too) to vary the sizing based on a more intelligent mechanism, related to SmartSizing volatility vs price. So, it's no biggie to pass on the Dynamic Sizing thing.

Therefore, when BgnVot is negative, I can make it toggle on MOC logic, with positive being the N-goto choice of MOO. Of course this means the user must purchase Powr or Cstm version, but that makes sense ... it's a useful option that warrants a few extra $$.

I'm modifying the prior crib sheet post accordingly.

The BgnVot override for the Cstm user had been "TFV" (Toe size, Full size, and reqd BgnVote), so there are 4 more characters available. These will specify the order type, AND, for MOC (aka BOC), will specify how much time before the end of the bar needs to be reserved for calculations: "TFVMm", where "Mm" specifies the number of minutes before the Close of the bar that MOC orders need for calculation and submission. Note that Mm is independent of the bar-timeframe chosen ... it's related solely to user-specific things like machine speed, number of FL symbols, feed-firing-frequency, whether there is any delay-time or not, etc.

The default for Mm, if the BgnVot slider is negative, and Daily bars are used, will be 15 minutes before the Close. That means the machine must be fast enough and the FL must be short enough so that the total time for a download+recalc to complete is no more than 15 minutes. If you think, from actual experience, that is too short, please let me know. "Just in case", I'll allow the Powr user to type in a -BMm override, but I won't document that ... I'll just tell people how to do it, if they tell me 15min is too little time (-B will be the slider-value to use).

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

Note: I'm not for-sure-positive about how AutoTrade works, re already-active TP's that might be firing Adds or PXits or FullX's. Logically, with EOD feed, if the "dedicated trading machine" is not fussed with by the user during the Session, then the ONLY time a download and recalc will be done is during the AutoTrade Window ... which would manage the timing of both the entry and exit MOC signals. I'm writing Barry to confirm this.

For RT feed with Daily bars, AutoTrade can be used in the same fashion as above ... a tight time window before the Close can be spec'd, and Entry orders would be restricted to that time period ... without the 20-min delayed data that EOD is saddled with. But Barry told me a while back that active-trade TP's with RT feed DO allow active-trade orders (ie Add or PX or FX) to fire outside the specified AutoTrade window. So, to prevent that from happening before the final time-window, OLang has to check the time internally and block any MOC signals from firing too early in the day.

However, for RT feed with Daily bars, *IF* we wanted to allow the H/L to trigger a Cut or Grab, then OLang could allow Mkt (not MOC) event-driven orders to fire before the final time window. The special text-file-management for bar-control of the Robust TP would be needed for this. Therefore, all coding for the Cuts and Grabs lines (except the "distant" SM Broker stop) will be based on MOC orders.

For RT feed with Intraday bars, since the Close and following Open are just a nanosecond apart, the order type doesn't really matter ... BOO will be used so that the backtest modelling will more closely match what's happening at the HRE. However, even with Intraday bars, it's important to "try" to use the full-current-bar info in the calc that might trigger a BOO order on the next bar ... so the OLang code needs to "manage" that timing as well. I believe that with judicious use of the "Time" functions included in the above link, that's possible. The "start the calcs time" would just be adjusted for each new bar, to the last few minutes of that upcoming bar.

When Intraday RT is used with TOO short of a "time window" for the calc's to complete before the next bar begins, the routine will "seem" to run OK, but actually some of the symbols' calcs won't be processed until after the next bar starts. Usually that's no biggie. In theory, I could set up some logic to track that, and output a report for the "washover to next bar" calcs. But that's overkill imho. The user can solve the problem by changing the "Mm" setting, or by making his intraday bars last a bit longer.

For Intraday RT feed, I can check the barlength using Periodicity and Compression. Based on that, I can make the default Mm value be shorter than 15 min for intraday bars. The OT function calls don't permit seconds to be specified. Also, it seems unlikely that even a fairly fast machine with a not-too-long Focus List could always be relied upon to complete the calcs in less than a minute. So ... for Intraday bars, I'll set the default Mm to be ten percent of the bar length, rounded off to the nearest minute (no less than one minute). That is, a 30min bar would do it's calcs in the final 3 min of the bar; a 20min bar in the final 2 min, a 13min or 10min bar in the final one min ... and a 5min or 3min bar in the final 1 min. Obviously, it would be silly to try to use this feature for a 1-2min bar. But it would work ... it just would have a lot of "washover to the next bar" cases, and the historical backtest would not match well.

I think that covers it. I've updated the crib sheet to reflect this change ...
http://tradetight.org/forums/thread-view.asp?tid=1432#M9592
Top of the page Bottom of the page
JimDean
Posted 5/13/2019 3:32 PM (#9619 - in reply to #9616)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Adds are tricky. I've mentioned before that I'm *very* concerned about Adds occurring late in the trade, followed shortly by a full exit from a final pullback, with a net loss for the most recently Added shares.
I'm similarly concerned about bright-bar Adds occurring after a warn-pullback, when the bright bar is associated with a big jump which would be a poor entry price for the Add.
I'm also *a bit * concerned about Adds that might appear early in a trade that is just wiggling unprofitably and (as yet, anyway) seeming to go nowhere.
In summary, although the code PERMITS Adds (when the Fuzzy-slider is negative), I want them to be fairly *rare*, and nearly always *indisputably wise*.

I already had four rules in place to "qualify" an Add:
1. A non-entry bright(strengthening-vote) bar during an existing trade,
2. Sum of prior warn/pxit(s) sizes must be >= some spec'd % of the next-Add size
... subsequently I changed this to be at least one PX of any size must precede an Add ...
3. Nominal Add-size auto-decrements by 20% after each Add, so later-trade Adds reduce, to 0%
... there is also an override-rule option that limits the total #Adds, or decrements by 40% ...

Even with those rules, Adds were appearing at what in retrospect were "ungood" times. So, I created three more rules:
4. For Longs: Close <= (Highest Prior GutsPrice since last Entry|Add) - 1*ATR (Short: C >= Lowest + ATR)
... after testing, I removed the +/- ATR ...
5. Close of potential Add signal bar must show a profit *since* the most-recent Entry|Add's Close
6. If rules #1-3 are met, *decrement* the next-Add size even if #4+5 are *not* met

The #6 rule helps assure that late-in-trade Adds are *small* (even if prior failed possibilities weren't used, the decrements occur) ... while #2 assures that the "net" of (Added shares - PriorPXit shares) is not too big ... required priorPX size-sum varies with slider. The #5 rule prevents "doubling down" thinking ... if trade (or most recent leg) is a loser, then don't add more shares!

I'm not certain yet, but I might used a StopMkt order, with threshold = PrevClose of the Signal bar ... in the RobustTP for MoO (positive BgnVot) models, which would assure that the Add is only taken if the following bar does not "pop up". However, since it makes more sense to use MoC orders for the Robust model's Adds and PXits, I may not create a Robust TP for MoO. At least not unless there's a demand for it. The Simple TP should work fine for MoO.

Taken together, these rules *eliminate* a large percentage of the Adds that would have appeared with just #1-#3. Which is a good thing imho. I believe that the Toe+Confirm approach represents what *most* people think of as an "Add" ... ie in the first few bars of the trade. Most traders don't consider Adding more shares once a trade is "rolling along" ... they wait for the trade to end and then maybe re-enter.

I don't mean to say that mid-trade Adds are bad, but rather that they should be taken very cautiously, and sized wisely.
Top of the page Bottom of the page
JimDean
Posted 5/13/2019 5:40 PM (#9620 - in reply to #9619)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
The dots are appearing!

I've been working on an essential and "touchy" part of the code ... validating all the "rules" for "Signals" to be legit ... and plotting dots on the pricepane to indicate when and what they are.

Things seem to be working well, for the positive VoteGuru (no Adds or PXits).

Now I'm testing the negative-slider combos of EndVotPXit and FuzBndAdds ... and it's making me re-evaluate the rules I had in place, as I'm seeing the dots appear.

The first major issue was that Adds were occurring way, way too often, and most of them were not in places where a trader would in retrospect agree was wise. I added some rules (prior post) and think I've pretty much solved that by making "qualified" Adds fairly rare.

NOW, I'm working on the various rules that *use* the actual *sizes* of the entry/pxit/add/fullx process. And I think I may need to make one of the rules smarter.

Currently, the Add sizes automatically decrease after each add, by 20%. I've changed the Fuzz slider -1 to -5 to allow the first Add to be 60,40,40,20,20 (was 80>40). So, if the first Add is 60%, the next is 40%, and the next is 20% (final since next "would" be 0%). However, if some variant of the mod's proposed below is used, it's unlikely that actual Adds will be more than 20% anyways ... (read on). Currently, the PXit size is determined by the EndVot slider (-1 to -5 = big to small).

1. The farther along you get in a trade, the more likely it is for it's profit/bar slope to have slowed down, and the more likely it is to reverse or go into "freaky swings". So, maybe it would be better to use small PXit sizes at first, and let them grow as the trade progresses (ie the first PX=20%, and ultimately through one means or another, it becomes 100% and the trade ends).

2. If Toe/Confirm is active (recommended), and if only the Toe entry has occurred, and the price doesn't continue to improve right away to warrant a Confirm (maybe 30% of the time?), then even a fairly small PXit size will cut a relatively large chunk out of the Toe-Entry position. However, if price moved enough for a Confirm, then it seems less likely that a sudden loss will occur, with price dropping below even the original Toe entry ... so, the small starting PXit size may not be an issue.

3. If All-In is being used (which means there are no Alert bars), then many of the questionable-zone trades are gone, so what's left *should* be the more reliable trades that don't need relatively "big" PXit sizes at first.

4. The Wrn2FullX spec limits how many PXits can occur in a row, before terminating the trade. So, if the PXsize starts at say 10|20|30|40% and grows by 10% after each PXit, then even when Wrn2FullX=4 (EndVot= -5), the max PXit would be 50|60|70|80%.

5. The EndVote slider defines the starting point for the PX size ... currently slider -1 to -5 goes 50,40,40,30,30 ... but I'll change that to a "starting point" of 30,20,20,10,10. Toe-Ins are from BgnVot 1-5= 40,40,20,20,20% ... so any of those PXit sizes would take a decent chunk out of the Toe state.

6. Once the Confirm order hit, there will be more shares in the account (BgnVot 1-5 Confirm = 60,60,60,60,40 ... so total shares from T+C = All-In = 100,100,80,80,60. But in either T+C or All-In situations, the presumption is that the entry is by then a reasonably reliable signal that won't need rapid scaling-out immediately.

7. Ongoing PXits would grow by 10% each time ... so a T+C (or All-In) entry size of 100|80|60 would in *any* slider-combo cases be emptied by four successive PXits ... 10+20+30+40 = 100%.

---------

8. NOW ... consider what happens when an Add occurs. Part of the current Add rule is that the PXit(s) before it must be some spec'd % of what the next Add will be - if prior PXit size is insufficient, the Add is skipped. Also, the current Add rule is that each new Add is 20% smaller than the prior one. Using the enhanced qualifier-rules in the last post, the "dots" show that qualified Adds occur very infrequently ... so I can't rely on the 20%-reduction-per-Add rule to help much.

9. SINCE PXits seem to be a *better gauge* of how the trade is progressing ... I'm thinking of enhancing the "Add size control", by gradually reducing the "max total position size" (mentioned above), based on PXits. That is, whenever a PXit fires, the max-position-limit is reduced by 10% (and never goes up again).

10. I think that I need to "focus" the Add paradigm a bit ... maybe the new rule should be that the Add *never causes the total position size* to be greater than the T+C|All-In Entry size. The examples below illustrate this.

Extended Example: If Entry total = 100%, and initial PX(#1) = 20%, then the first exit would cut the actual size to 80%, and the total allowed would be cut to 90%. If the potential for an Add (that met all the Add requirements in prior post) came up right away, the available headroom to the limit = 90-80=10% ... which is too small (Adds are only increments of 20%). However, if another 20% PX(#2) hit before that Add, then the actual size would be cut to 60% and the max-limit size would drop again, to 80%. If a qualified-Add (#1) hit right after that, its max size could be only 80-60=20% ... bringing the net back up to 80%. The next 20% PX(#3) would cut the max-allowed to 70% and the actual to 60% ... too small for an immediate add ... so another 20% PX(#4) would need to hit first, cutting the max-limit to 60% and the actual to 40%. If the thing happens again ... a maxed-Add (#2) of 20% => actual=60%, then two 20%-PX's(#5,6) => actual = 20% and max-limit=40%. Another Add(#3) takes the actual to 40%, and the next two PX's(#7,8) would zero out all the shares of the trade.
Summary: in this example, there were three small (20%) Adds, and eight small (20%) PXits. The overall position size decreased gradually to the very end. Presumably, the "early" part of the trade contained the most profitable price-improvement, with small PX-pullbacks followed by new-leg Adds that resumed but with a smaller size. Wave-theory suggests that each new leg usually has a lower price-improvement velocity.

Quicker Example: If Entry total = 60%, and initial PX(#1) = 30%, then the first exit would cut the actual size to 30%, and the total allowed would be cut to 50%. A qualified-Add (#1) hitting right after that brings actual back up to 50%. The next 30% PX(#2) cut the max-allowed to 40% and the actual to 10%. If yet another qualified-Add appears (#2), there's 40-10=30% headroom but largest 20%-multiple Add = 20% => actual=30%, then the next 30% PX(#3) zeros out all the shares of the trade.
Summary: in this 60%-entry example, there were two small (20%) Adds, and three medium (30%) PXits. The trade presumably was much shorter than the prior example.

IMPORTANT to note: those two examples are NEVER likely to happen ... they call for Adds to be "available" after most any PXit ... but the reality is (see prior post) that the Add rules are pretty restrictive, so the two examples would more likely go like this:

Realistic 100%-entry, 20%-PXit example: The first PX(#1) cuts actual to 80%, and the total allowed to 90%. Then PX(#2) takes out another 20%, so actual=60% and limit=80%. This time, no qualified Add appears, so the next 20% PX(#3) cuts the max-allowed to 70% and the actual to 40%. If an Add qualifies now, it can only be 20% since 70-40=30 isn't a 20-multiple ... actual = 60%. Three more 20% PX's (#4,5,6) without a qualifying add after #5 wipe out all the rest of the shares.

Realistic 60%-entry, 30%-PXit example: The first PX(#1) cuts actual size to 30%, and the max-limit to 50%. The next 30% PXit would kill the trade, so assume a qualified-Add of 50-30=20% (#1) hit right after that, bringing the actual back to only 40%. The next 30% PX(#2) would cut the max-allowed to 40% and the actual to 10%. Without another (rare) qualifying Add, one more PX(#3) ends the trade.

-----

This calls for more thought.
Top of the page Bottom of the page
JimDean
Posted 5/14/2019 11:48 AM (#9623 - in reply to #9620)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
Okay ... new day, fresh re-read of the prior two posts, and some refined plans ...

First ... I modified the 2nd post back a bit, clarifying rules #2&3 and adding some italics. No biggie. And I switched #9 & #10 in the prior post.

Second ... the prior post items #1-#7 re increasing PXit sizes is actually an alternative to #8+, and I've decided *not* to implement 1-7. Reasons:
a. fairly complex to code, esp re maybe decrementing the sum due to bright bars, etc
b. it does not even approximately match the Med2Warn and Warn2FullX counting logic
c. would require significant override modifications of some sort
d. would likely be confusing, not knowing what % is used for a given warn/pxit
e. the CutGrab lines tighten during the trade, which sort of serve the same purpose
f. the Robust TP would be significantly bigger &/or more complex, to implement this

What I'm going to do (outgrowth of prior-post #8-#10 items):

A. Re #8 ... since the examples in #10 show that the likely Add sizes are already small in this new approach, and since we *want* Adds to be "biased" to occur early rather than late in the trade (if at all), I am changing the rule about the PXit size prior to the Add having to be a certain % of that Add. The new rule (matching the non-size W before A rule) will be that *any size* PXit will be required before any Add. Reason: the main purpose of requiring a PX before an Add is to help identify places where a pullback-weakening has occurred (as measured by CumV Votes, not solely price), followed by strengthening (implying resumption of the wave-trend). Also, this will simplify the code as well as the Cstm overrides, since that "required %" will not need to be specified or dealt with.

B. Re #9 ... I think the idea about reducing the allowed-max-limit is a good one ... it reflects whether or not there have been a lot of temporary-but-likely-indicative weakening instances during the trade, and presumes that the most profitable part of the trade is at the beginning. Decreasing the limit by 10% at a time makes it unlikely that the limit would ever get to 0 ... I'll include logic to prevent the limit from being less than the specified PXit size ... in that state, any kind of PXit will act like a full Exit, and no further Adds would be possible. However, since this often will limit the "utilized size" of Adds, I'm also going to make the Entry Size percentage options 20% larger:
1. BgnVot 1-5 Total Size = 120,120,100,100,80 (1,3,5=Toe+Confirm and 2,4=All-In)
2. BgnVot 1,3,5 Toe-In Size = 60,40,20 ... this reflects the "uncertainty" of the initial ToeIn
3. BgnVot 2,4 Confirm Size = 60,60,60 ... shares added only with timely bright-bar followup

... maaaybe I will use this instead ... PLEASE COMMENT re B.1-3 vs B.4-6:

4. BgnVot 1-5 Total Size = 140,120,120,100,80 (1,3,5=Toe+Confirm and 2,4=All-In)
5. BgnVot 1,3,5 Toe-In Size = 60, 40, 20 ... ToeIn = 40% of Total in all cases
6. BgnVot 2,4 Confirm Size = 80, 80, 80 ... trades w/Confirmation are more reliable than All-In

... in either case, the "All-In" options are #2=120% and #4=100%
... in either case, the #5 smaller size represents minimal required initiation (BgnVot= only 4 of 7)
... in all cases, the user can adjust what "100%" means, via the TradeCalculator shares input

C. Re #10 ... not allowing an Add to increase the size above the max-limit ... this sort of goes hand in hand with the existence of a max limit at all, but there are "issues":

1. Since Adds (and Entries) are always even multiples of 20%, while PXits are always even multiples of 10% ... this rule is mainly related to Robust TP complexities for more granular Add options ... that means PXit size choices that aren't 20%-multiples will cause "rounding down" for actual Adds.

2. Also, since PXits are usually smaller than the initial-add spec (depending on slider and overrides), that means an Add following a PXit will often be "clipped" ... which sort of emasculates the spec of the initial Add in the first place. Logically, if the user specs a larger initial Add, they are hinting that they are willing for the total position size to get larger even after the Confirm and the first PXit which is needed before the first Add (since the first PXit never wipes out the full Confirm, unless the override PX size spec is unwisely out of the ordinary.)

3. A reasonable solution to this is to keep the max-limit rule and the PX-reduces-max rule, but redefine what the initial max-limit is. The prior post uses initial max = Total Entry (ie Toe+Confirm, or All-In size). In order to allow Adds to potentially be their "spec'd" size, then the initial max-limit should be larger than the Total Entry ... increase it by the difference between the Initial Add and the PXit size.

4. As an adjunct to that, the "rounding" rule for the "actual size" of the Add used will allow rounding UP ... that is, if there is only 30% headroom available between Actual and Max, and if the Add *could* be (per spec) 40% or more at that point, then it will be allowed to be 40%, talking the actual-position-size 10% beyond the max-limit. In no cases will the Add be allowed to push the max limit by more than an extra 10%.

5. However, the code will remember that #4 "violation", and the next PXit, whatever it is, will reduce the Actual by an EXTRA 10% (as well as the normal max-limit PX of 10%) ... thus keeping the max-limit reduction "on track", and bringing the actual size back *within* that limit at the time of the PX. The benefit of this is that it's at least *possible* for the Init-Add size to be honored, but it won't affect the overall duration of the trade.

===== with all that in place, here are three examples =====

Big EntryAdd, Small-PXit Example: (using sliders) would be T+C (or All-In)=120%, InitAdd=60% and PXit=10%, which increases the Init Max by 50% to 170%. After the T+C, with *just one* PXit (which cuts Max by 10% always, to 160% here, and cuts Actual by 10% due to PX=10%, to 110%) ... then an immediate Add appears that meets all the (tough) rules, the first add would be the as-spec'd 60% (violating the limit by 10%), taking the actual size up to 170% ... so for a short while, the actual exceeds the max. However, the very next PXit lowers the Max Limit by its normal 10% to 150% ... and the PX itself is 10% bigger this one time ... so the actual size drops by 20% to 150%, equal to the max.
If a "qualified" Add hit right away, then the 10%-max-limit-extension-option would not allow the Add to even be 20% since Actual=Max at that point ... so the Add would have size=0 and be skipped ... but the Add size decrement would *still* happen (per rule #6 of 2 posts ago), reducing the potential Add size to 40% if and when the qualifications are met again.
HOWEVER, this example has a "trick" to it ... since the extremely-small fixed-PX size cuts the Actual only by 10%, and since the max reduces by 10% each PX, and since at this point in the trade the Max = Actual ... then no matter how many PX's occur after that, *no more Adds* will occur, since each PXit will reduce the Max and Actual in lockstep.
RESULT: only One Add, and it happens very early in the trade ... impossible for more Adds later on. Good ... just what we are shooting for.
WHAT-IF: assume that no potential Add (not even satisfying the simple 1-3 rules of two posts ago) is avail after the first PX, so a 2nd (or third, etc) PX hits. Since PX=10%, this lowers both the Max and Actual *equally*, maintaining the 50% differential, so when/if a qualified-Add appears, the same thing would happen (one Add, then no more), but later on in the trade. HOWEVER, this is *unlikely*, since the #2 PX rule *is* met and the #1 "bright bar" rule is *very* likely to hit, and rule #3 doesn't apply to the 1st Add ... therefore, when the *very likely* in-between-PX's bright bars hit ... and if the "tough" rules 4-6 aren't met in those cases, then the nominal-Add decrement kicks in ... which quickly reduces and soon zero-outs the potential for ANY adds ... so, even in this case, a single mid/late-trade Add is unlikely, and if it occurs, it will be small. Good ... what we wanted.

Small EntryAdd, Big-PXit Example: (using sliders) would be T+C (or All-In)=80%, InitAdd=20% and PXit=30%. In this case, since InitAdd < PXit, the Init Max just = Entry = 80%. After the T+C, with *just one* PXit (which cuts Max by 10% always, to 70% here, and cuts Actual by 30% due to PX=30%, to 50%) ... then an immediate Add appears that meets all the (tough) rules, the first add would be the as-spec'd 20% (Limit-Actual=70-50), taking the Actual up to the Limit 70%. The next PXit lowers the Max to 60% and Actual to 40%, thus allowing another Add ... BUT, due to the sequential-Add decrement rule, the next Add would be @0%-20%=0.
RESULT: just as in the example above, this allows ONE Add only ... the main reason being the sequential-Add-decrement rule. Good ... what we wanted.
WHAT-IF: assume that no potential Add (not even satisfying rules 1-3 of two posts ago) is avail after the first PX, so a 2nd PX hits. Since PX=30%, this lowers the Max to 60% and Actual to 20%. If a third PX hits with no Add, it zaps the position. But if before that, all Add-qualifiers are met, the first Add pushes Actual to 40%. The next PX drops Max to 50% and Actual to 10%. However, even if all the qualifiers for a second Add were met, none would occur, since the nominal-Add size decremented to zero. Good ... just one Add, after only 2 PX's, *if* qualifiers met.

Intermediate Example: (using sliders) would be T+C (or All-In)=120%, InitAdd=40% and PXit=20%, which increases the Init Max by 40-20=20% to 140%. After the T+C, with *just one* PXit (which cuts Max by 10% always, to 130% here, and cuts Actual by 20% due to PX=20%, to 100%) ... then an immediate Add appears that meets all the (tough) rules, the first add would be the as-spec'd 40% (violating the limit by 10%), taking the actual size up to 140% ... so for a short while, the actual exceeds the max.
However, the very next PXit lowers the Max Limit by its normal 10% to 120% ... and the PX itself is 10% bigger for catch-up ... so the Actual drops by 30% to 110%, a bit less than the max. If (unlikely) all the qualifications for a *second* Add hits right after that one PX, the Add would have a nominal size of 20%, due to the sequential-adds 20%-decrement. That Add would be allowed to "violate" the max-limit by 10%, taking the Actual to 130%.
The next PXit lowers the Max by its normal 10% to 110%, and lowers the Actual by 20% plus catch-up 10% to 100%. So it would seem that there's barely enough room for another Add ... BUT, the sequential Add-decrement hits again, lowering the next-Add nominal size to 0% ... therefore there will be no more Adds.
RESULT: this allows only two Adds (if all tough qualifiers met), mainly due to the Init being 40%, in combo with the sequential-decrement rule.
WHAT-IF: assume that no potential Add (not even a simple bright bar) is avail after the first PX, so a 2nd PX hits. Since PX=20%, this lowers the Actual to 80% and Max to 120%. If a qualified 40% 1stAdd appears now, Actual = Max = 120%, and decrement rule sets next Add nominal to 20%. When the third PX hits, the Max drops to 110% and Actual to 100%. Another tough-to-qualify Add appears, and the extra-10%-max rule allows it: Max=110 and Actual=120%. The next PX does 20+10% catch-up ... Max = 100% and Actual drops to 90%. At this point, no more Adds are possible, since the second decrement makes the nominal=0. If no FullX rules appear (there are several possibilities), then presumably the trade keeps moving profitably, and it will take five PX's to wipe out the position size. Good ... Adds only at the start, with plenty of room for ongoing profit moves to utilize the "extra" shares.

Of course there are other slider-combos of Entry, Add and PX ... but this long-winded set of three examples + "what-ifs" should have adequately explained how the rules work, and also proven that the normal way things play out will limit Adds to the early part of the trade, which is my key concern ... and the rules 1-6 will limit the Adds to a profitably-moving trade, with decent buy-in prices.
Top of the page Bottom of the page
JimDean
Posted 5/14/2019 2:35 PM (#9624 - in reply to #9623)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3861
200010005001001001002525
Location:
USA: GA, Lawrenceville
A. With all of that in mind, I'm considering modifying the Initial-Add slider-size options to its original range: FuzzAdd slider -1 to -5 = 80,60,60,40,40 ... ie 20% higher than the prior set of examples used. The reasons for the "staggered" sizes (rather than 100,80,60,40,20) are:

1. 100% seems like an inordinately large Add, and 20% seems silly-small for a "first and only" Add
2. the slider is also varying Fuzz% = 0,15,30,45,60%, so the stagger allows the same Add size to be modelled for two different Fuzz%'s
3. if the GuruVot slider (Powr) is used from -1 to -5, the staggering here logically matches up nicely with the T+C vs All-In and 6,6,5,5,4-NetVot stagger for the BgnVote-slider, and the 50%,40%,40%,30%,30% PX-size and 2,2,3,3,4-OppVot stagger for the EndVote-slider.
4. I'm allowing the override to spec InitAdd=80%, so the RobustTP has to support it, so it might as well be represented in the slider (even if just for slider=1)

B. Also, I'm revising the EndVot-slider PXit-size options halfway back to where they were earlier ... last post assumed 30,20,20,10,10 ... earlier they were 50,40,40,30,30 ... I'm changing them hopefully for the last time to 40,30,30,20,20. Reasons:

1. 50% seems too big, wiping out the trade with just two PX's, and 10% seems silly-small - hardly worth paying the commission
2. the slider is also varying OppEndVotReg=2,2,3,3,4 ... so the percent stagger matches up two different PX sizes with the same #votes, making for more, interesting combinations.
3. the slider also varies Med2Wrn#, Wrn2FX# thresholds: 3m2w, 4m2w, 3m3w, 4m3w, 4m4w ... each is different but the #Warns>Full staggers like the Votes do, pairing with differing PX%'s ... again, making more interesting combinations.
4. A "larger smallest" PX% of 20% will scale out of unsuccessful trades more quickly than 10%.

C. But before adding that extra 20% to the nominal InitAdd sizes and 10% to the PXits, I should probably see how those changes impact the Examples. Without further ado, here they are, revised for that other range (and note that the prior examples still are possible, especially if you consider overrides):

======

Big EntryAdd, Small-PXit Example: (using sliders) would be T+C (or All-In)=120%, InitAdd=80% and PXit=20%, which increases the Init Max by 80-20=60% to 180%. After the T+C, with *just one* PXit (which cuts Max by 10% always, to 170% here, and cuts Actual by 20% due to PX=20%, to 100%) ... then an immediate Add appears that meets all the (tough) rules, the first add would be the as-spec'd 80% (violating the limit by 10%), taking the actual size up to 180% ... so for a short while, the actual exceeds the max. However, the very next PXit lowers the Max Limit by its normal 10% to 160% ... and the PX itself is also 10% bigger this one time ... so the actual size drops by 30% to 150%. If a second Add that meets all the rules appears, although its sequentially-reduced nominal is 60%, the 160-150 headroom limits it to only 20%, leaving the Limit=160 and Actual=170
Another PX lowers Limit to 150% and Actual to 150%, which means no reduced-to-40%-nominal Add is possible.
Yet another PX (2 in a row now) drops Limit to 140% and Actual to 130%, allowing an unlikely-to-qualify-yet-again Add, but again headroom-limited to only 20% ... leaving Limit=140 and Actual=150.
The fourth PX of the trade sets Limit=130 and cuts Actual to 130 ... so even if an Add qualified, the zero-headroom would block it. A fifth PX and Limit=120, Actual=110 ... the sequentially-reduced nominal-20% Add barely fits ... new Limit-120 and Actual=130. The next catch-up PX drops them to Limit=110 and Actual=110.
No further Adds are possible, since the next sequential drop takes the nominal Add size to zero. So, if none of the several possible FullX events occur, then the trade can last a lot longer ... it will take 6 PX's before all the shares are gone.
RESULT: in this very unlikely example, all four possible Adds fired (80,20,20,20), but the various rules prevented even this extreme case from applying anything other than the smallest possible Adds after the first one ... and after they were done, the trade potentially lasts a *long* time. If you have a crystal ball, THIS is the set of size-choices you should use!
WHAT-IF: it's far more likely that the bright-bar between PX's that triggered the example-Adds would in some (or all) cases NOT satisfy the "tough" Add rules 4-6 ... in which case the nominal-Add size would still decrement, but no Add would occur. And note that when the 4-6 rules are met, there's a very good likelihood of the Add entry price being a fairly good one.

Small EntryAdd, Big-PXit Example: (using sliders) would be T+C (or All-In)=80%, InitAdd=40% and PXit=40%. In this case, since InitAdd = PXit, the Init Max just = Entry = 80%. After the T+C, *just one* PXit cuts Max by 10% to 70%, and cuts Actual by 40% to 40%) ... then if an immediate 40%-nominal Initial Add appears that meets all the (tough) rules, it would barely make it since the rule allows the max-limit to stretch by 10%, bringing the Actual to 80%. The next PXit lowers the Max to 60% and subtracts 40%+ catch-up 10% =50% from the Actual, to 30%.
The next Add decremented nominal =20%, which works (if all qualifying rules met) ... Actual goes up to 50%. The next PX drops Limit to 50% and Actual to 10%. Even though there's headroom, there are no further Adds since the nominal decrement has dropped to zero. Just one more PX kills the trade.
RESULT: this case has two Adds totaling 60% with two PXits after them that end the trade. The Adds are small ... one at beginning and one in the middle. It's unlikely since the difficult rules 4-6 usually aren't met.
WHAT-IF: assume that no potential Add (not even satisfying rules 1-3 of two posts ago) is avail after the first PX, so a 2nd 40% PX hits ... that kills the trade. Or, assume that the first Add hits and the second one is never fully qualified ... the 80% net after the first Add is cut to 50% due to catchup with the next PX ... and two more PX's kill the trade. Either of these cases (or no Add at all) are much more likely than the both-Adds-fully-qualified first case.

Intermediate Example: (using sliders) would be T+C (or All-In)=120%, InitAdd=60% and PXit=30%, which increases the Init Max by 60-30=30% to 150%. After the T+C, with *just one* PXit (which cuts Max by 10% to 140%, also cuts Actual by 30% to 90%). The first tough-to-qualify nominal-60% Add squeak past the limit by 10%, taking the actual size up to 150%.
The next PXit lowers the Max Limit to 130%, and the Actual drops by 30%+10% to 110%. If (unlikely) all the qualifications for a second Add hits right after that PX, the sequentially-reduced-nominal-40% Add would only be allowed 20% execution, taking the Actual to 130%.
The next PXit lowers Max to 120% and Actual to 100%. If (very unlikely) fully-qualified third Add with nominal size of 20% hits, it raises the Actual to 120%. But after that, the Add-decrement rule has dropped to 0, so no further Adds. Four more PXits end the trade, if no FullX rules intervene.
RESULT: this allows all three (60,20,20) Adds (if all tough qualifiers met), but only the first is nominal. Four PXits after that imply those Adds are all in the first half of a long trade. Good.
WHAT-IF: as suggested many times, the likelihood of all the Add-qualifier rules being met on even one Add is tough ... but for them to happen two (or three) times in a row is nearly ridiculous. So, if the prior example had a bright-bar sequential-nominal-Add reduction instead of the first add, then when the second Add rolled around after another PX (Limit=130% and Actual=60%), the Add would only be 40% ... so Actual goes to 100% and the nominal cuts to 20% for the next Add. Next PX makes Limit=120% and Actual=70% ... and if we assume the unlikely qualified bright after that Adds 20% (our last possible Add), the Actual becomes 50% and two more PX's kill the trade. Note that in these a-bit-more-likely scenarios (actually, no Adds is the most likely), even with mid-trade Adds, the net position size isn't very big. So, we're still good.

Keep in mind that the 3rd example on the prior post (and its whatif's) is still a valid slider-combo even with both the Add and PXit sizes having been raised here. The first and second prior-post examples are "legit" cases if either the Add or the PXit size used a Cstm-version override.

Whew. Congratulations for reading all that! I'll save these explanations for formal documentation.
Top of the page Bottom of the page
SalimHira
Posted 5/15/2019 5:41 AM (#9626 - in reply to #9624)
Subject: CVW Archived Devel Discussion



Veteran

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

I looked at the writeups and examples, and do not have much to comment - it all looks good, everytime I re-read, something else continues and pops in mind :-) to reflect upon. Lots of ideas.

In beginning, it kind of intimidating as everything new to someone never exposed too this concept (including myself, and never used these kind of methodology). So, one suggestion, to launch thought-process - I'd like to view, in addition, to the various examples you have provided in %'s, to include one-simple example as starters with how when individual starting with actual "share numbers", i.e., 100 shares, bought & than, partial sold (#'s), shares Added (how many), etc. etc... till full exit "# of shares", (left 0), scenario in a real life kind of situation that may unfold with Adds, PXit, etc. would work that they can relate too, that includes with providing the percentage examples. I believe, from there upon, the individual should be able to follow the rest of your %'s examples and explanations you have provided.

Some areas, I can see someone can get tangled up in thought with the %'s, that only, will make them come back to you for a refresher :-). In short, one real life example that a user may relate too for them to launch off.

Thanks, Salim ...
I’m glad to hear that there was only one word (percent) that you had issues with.

Please re-read/skim, but everywhere you see “%” read “shares”. Or, if you prefer, “dollars”. The explanation is exactly the same with any of the three words.

When I finally have time to write things up, I might add one more example, with a snippet of a chart, and arrows pointing to bars. The huge, huge problem with doing that is the true “rarity” of Adds as things now stand. It be practically impossible to find actual cases of all the examples, re how they play out.
Top of the page Bottom of the page
Jump to page : 1 2 3 4 5
Now viewing page 4 [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.