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 Timothy 6:6-8 (ESV) … Now there is great gain in godliness with contentment,  for we brought nothing into the world, and we cannot take anything out of the world.  But if we have food and clothing, with these we will be content.


CVW Archived Devel Discussion
Frozen
Jump to page : 1 2 3 4 5
Now viewing page 5 [50 msgs/pg]
Jump to room :
JimDean
Posted 5/15/2019 6:59 PM (#9631 - in reply to #9626)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
I'm tweaking the Ntr/Add/PX/FX "dot-signals" today, as I review the impacts of the rules ... so this post will "grow" during the day. Please watch for bolded questions and answer ASAP if you can.

===== Initial thoughts:

A. Some bugs to work through, but it appears at this point that the "sizing" rules for PX's => FX's are chopping up the Waves a bit more than I'd like. Also, there are VERY few Adds appearing ... I tested all 15 symbols with 25 permutations of EndVPX and FuzAdd negative-sliders, and only found three bars ... all on AAPL, where Adds ever appeared. They were in just the right "kind" of locations, but I expected them not to be quite *that* rare. This needs more review, but there are three things to try:
... 1. consider loosening up the "tough" Add rules #4-6 somewhat.
... 2. consider making the PX's smaller (30-10% instead of 40-20%)
... 3. consider logic-mod's so late Adds are *more* discouraged, for Shorts
When the "D" mods were made, the charts didn't look so problematic. I'll keep an eye on it though

B. Too many of the "short" trades initiated as a Toe are also Confirming on the second bar, even though the trade is in a chatter-zone and really should not be in play. So, I'm thinking about changing the Confirm rule to require that the bright which fires the confirm is always the *2nd* bright after the Toe/Alert. opinions?
Major fixes and tweaks and qualifiers for T+C logic during "E" seem to have resolved this ... I'll keep an eye on it


==== Second Check-In:

C. Just noticed that the current code allows cases where the Confirm-bar Close is actually *less* than the Toe-bar Close. That is, the Confirm is an "Up" bar, but it comes after enough of a "Down" leg since the Toe, that even though it's bright, it's not really confirming anything about the trade direction. And that's what Confirm is supposed to be about. So, I'm adding that rule for Confirms ... the Confirm-entry ONLY is permitted (w/existing rules), if the Close of the Confirm bar shows a profit vs the Close of the Toe bar.
... I could also require the Confirm Close to be better than the prior Close - should I?
... and/or, I could require the Confirm candle (O-to-C) to be green/red for L/S - should I?
... &/or, I coud require both of those conditions ALSO for the Toe-In bar - should I?


For now, I'm implementing the Conf C better than Toe C, and I'm going to test out using *either/or* of the rules in bold above, for both T & C. That is, for Longs, if C > C1 OR if C > O for the T|C candidate, it passes the test.
I ended up using "and" ... ie both rules ... I modified the C vs C1 to allow ATR/20 as a fuzzy overlap. This seems to nicely eliminate some chatter-trades.

D. Currently, the EndVotPX slider 1-5 assigns: 2V3m2w, 2V4m2w, 3V3m3w, 3V4m3w, 4V4m4w
... and when the slider is neg, it also sets PXit sizes to: 40%, 30%, 30%, 20%, 20%

The idea for this and the BgnVot slider is for 1&2 and 3&4 pairs to be identical re #Votes, but have the other "nuances" for PXits & T+C|All-In vary within each pair in a logical fashion. For EndVotPX, the nuanced variants are M,W,PX%. PX% applies when a Warn is created (for whatever reason) ... the current mapping has two diff PX%'s for each pair, as it should be ... AND, the PX% gradually decrease as the slider increases. Good.

However, the M's (ie #Meds to create a Warn) currently "stagger": 3,4,3,4,4 ... there are two options per pair but the sequence is not smooth. Since M>W is the "count" equivalent of the PX% size (ie when M succeeds, a W is gen'd using PX size), the sequence should be similar. I've noticed this on the chart, too, now that PX dots show up.

The W's are in a sensible progression ... they create fullX's, so they "relate" to the Votes and don't vary within a "pair" ... W's are just different logic for ending a trade ... 2,2,3,3,4 is fine as is.

Therefore, I'm changing the M-list to 2,3,3,4,4 ... the only "issue" with this is that "2m2w" means that a succession of three M's without any brights between them will create a full exit ... second M is converted to a Warn, and third M makes another Warn which auto-converts internally to a FullX. That's not a bad thing ... it is after all the "1" input ... but it's pretty scaredy-cat logic.

So the overall EndVotPX 1-5 Vmw map becomes: 2V2m2w, 2V3m2w, 3V3m3w, 3V4m3w, 4V4m4w
I've tested this and it works like a champ.


==== Final Check-In:

E. Not sure if I mentioned it before ... I added a new "full exit" Indigo (very dark purple) color to the band, to indicate when a full exit occurs because the SizePct drops to zero (ie due to PXits). So, there are three colors that might appear when a trade ends: midnight blue (was navy) = "normal" rules (a bunch of them); black = either a reversal or M,W logic; indigo = position size dropped to zero. This is informational only ... the Signal return in every case is "full exit". ALSO, I tweaked the various shades of blue to better distinguish between them ... a ToeIn from an Alert is regular blue, a ToeIn as the first bright is a clearly a lighter color but not bright; a Confirm after either kind of ToeIn is a fairly bright blue. For All-In mode, the Entry is bright green or red as before. The color-families make sense, and the individual colors are easy to distinguish.

F. I've spent most of the day working over the ToeIn, Confirm, PXit, and FullX code. There are *many* permutations of what can happen and when ... it took a lot of work to tweak and revise to cover all the situations. I'm pretty sure that is complete now, but I'll give it a once-over tomorrow AM or later tonight, with fresh eyes. This logic is hugely important ... I'm pleased with the results.

G. Forgot to mention ... the prior posts about the new Add and PXit logic which called for changes (simplifications) to the slider-overrides have all been implemented. I'm not actually testing the overrides yet, but the variables they assign are integral to the calcs, so I'm confident there won't be a need for major re-coding later. The big unknown is whether or not some of the oddball override patterns that cannot be modeled with sliders, will really be a lot "better" than slider-models. If I've done my intuitive tasks properly, they won't.
Top of the page Bottom of the page
JimDean
Posted 5/16/2019 8:52 AM (#9632 - in reply to #9631)
Subject: CVW Archived Devel Discussion



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Another new day's post with progressive updates ...

===== Initial thoughts:

A. I did a thorough review once again of the T+C, All-In with FullX models. Tweaked a the price-fuzz amount regarding the C > C1-ATR/fuzz (longs) rule ... I reduced it from my initial guess of ten, by stages down to fuzz-divisor=50. Thus the comparison is very close to a simple C > C1, but the fuzz allows for minor vagaries in negotiated close-price. Also, I did a final review of the BgnVot options of 6,5,4 ... confirmed proper operation and reasonable range. I'm satisfied that all these rules are solid now.

B. Now focusing on repeating the eval for PXits (EndVot slider <0). I'd modified the M,W a tad bit (to make the M-progression smooth= 2,3,3,4,4) and had reassigned the PXsiz%'s to 40-20 (orig was 50-30, toyed with 30-10). All-in-One: 2V2m2w40, 2V3m2w30, 3V3m3w30, 3V4m3w20, 4V4m4w20
Initial overview (15 symbols @ 6mo's) indicates that:
1. it seems likely that the rules might need to differ for longs vs shorts
2. the MW's cut off longs a bit too early; the PX%'s cut off shorts too late (NOT consistent tho)

The typical "Short" trend has a sm-med drop, a noticeable pullback, a med-big drop, then a bounce up and back. At least that's how I'm thinking of the run for logic purposes. So ... any Adds for Shorts should be early, NOT late (will work on Adds next). And Warns at the beginning of the run should not reduce size too much, but at the end they should quickly get to a full exit. This implies the #Meds2Wrn on high side (to minimize #Warns at first), #Wrns2FX on low side (to quickly FX at end), and PX% on high side ... or maybe even ramped-PX, where first PX is small and last is large.

Otoh, a typical "Long" trend moves up fast initially, pauses or has a small pullback, moves up for a longer period but not as rapidly, has a med pullback, then any further upwards move is either at a slow rate, or highly volatile, or both. Rules for Adds can be more flexible, allowing some mid-run, as long as they aren't too big (much like prior written-out examples). Potential for several manageable pullbacks implies #Wrns2FX could be higher, and to encourage early Adds, #Med2Wrn could be lower (Wrn is req'd before an Add can be considered). Since Adds are tough to qualify, and since there can be several Warns during an extended but typical trend, the PX% shouldn't be too big, so as not to end the trade too early.

So, maybe change from 2V2m2w40, 2V3m2w30, 3V3m3w30, 3V4m3w20, 4V4m4w20 to:
Shorts: 3m2w50, 4m2w40, 4m3w40, 5m3w30, 5m4w30
Longs: 2m3w40, 3m3w30, 3m4w30, 4m4w20, 4m5w20
... increased M's for shorts, increased W's for longs, and increased %'s for shorts
... this presumes the same paradigm, with PX%'s and MW's constant during the trade (no ramping)
... the slider-def's => two lists; EndV override PMWV => PMWpmwV: caps=Long, lower=short


===== Second Check-In:

C. Increasing the W's for Longs doesn't help and sometimes hurts ... so changed back to same as for shorts, but for now, left in the other mod's mentioned above. However, to keep the #W2FX comparable to the PX%'s,
Shorts: 3m2w50, 4m2w40, 4m3w40, 5m3w30, 5m4w30
Longs: 2m2w40, 3m3w30, 3m3w30, 4m4w20, 4m4w20
... need to test more, with Adds ...

D. Finally got round to updating the popup help that has all the derived settings, etc. Fixed all prior lines, added some more for Bgn/End/Fuz derived values. Still need to add lines related to CutGrab, and handle overrides for Filters, BarWndo, and PltRtn. Along the way I also fixed the order of inputs and syntax for the popup function-call strings.
Top of the page Bottom of the page
JimDean
Posted 5/21/2019 8:31 PM (#9636 - in reply to #9178)
Subject: CVW Reference Information



Owner/Admin

Posts: 3925
2000100050010010010010025
Location:
USA: GA, Lawrenceville
Extensive eval done re TradePlan requirements and structure, so that min# diff Signal types can be defined. The notes below explain it all. They also provide for even more Ribbon-Band color variants, so that each kind of event has its own color. The Return values will be similarly expanded.

===========

Current definition for Signal is TOO detailed ... TradePlan analysis below allows simplification:
'Signal (0= no sig for this bar) ... SigNAX (BrkFX based on H|L, others on C)
'T.Ppp: TrdDir +L,-S; Size as Decimal Ppp% (always mult of 10, so really just Pp)
'LONG pos: 9=NrmNtr,8=ToeNtr,7=Cnfrm,6=Add,5=GrbPX,4=CutPX,3=VotPX,2=FullX,1=BrkFX
'SHORT neg: 9=NrmNtr,8=ToeNtr,7=Cnfrm,6=Add,5=GrbPX,4=CutPX,3=VotPX,2=FullX,1=BrkFX

Event-based Sigs use *same* TrdPlan 10%-inc PX Cond+Ord, so all PX same; BrkrFX req sep SM Order
... Ppp size used in Cond-Shell OLang check to fire Cond=True (OLang=> generic TP for diff Strads)
... No different for MoO, MoC, Limit or Mkt orders used for PX's &/or Adds (poss partial-fill prob)
... Event-based FX *never* Limit order, but otherwise just bigger-size PX, so Sig "T" can be same
S1=Toe|NrmNtr, S2-8=szdBrkFX, S9-15=szdCndFX @+0|4-6 CndCnfrm, S16-21=TCszBrkFX, S22-27=TCszCndFX

"ScaleEntry" TP - separate MoO and MoC versions ... no Add/PX support
Step 1 has 7 Stradic-Ctl Cond'ns for init size: Toe% = 20,40,60 or Nrm% = 80,100,120,140
Step 1 same-bar jumps to one of 7 Steps @w/uncond Broker-SM order, based on 20-140 size
Each of 7 Broker-SM steps jumps to 1 of 7 diff-init-size FX|Confirm Steps, each having:
... Full-Exit event-Condition for that particular Step-1 size (Stradic controls firing)
... #Strad-Ctl Cnfrm scale-in Cond'ns depends on Step1 Toe sizes only - T+C never > 140%
... CnfrmCondSizes: Toe=20:20,40,60,80,100,120; Toe=40:20,40,60,80,100; Toe=60:20,40,60,80
If Confirm fires, jump to one of 6 Steps to update uncond Broker-SM size & price-level
... Six, since smallest Toe+Cnfrm= 20+20=40, largest= 140(cap) => 40,60,80,100,120,140
Each refreshed-BrokerSM step then jumps to 6 same-Net-Size Strad-Ctl Cond Full-Exit steps
So, total# "ScaleEntry" TP Steps= 1+7+7+6+6= 27; Cond's= 7+7+7+15+6+6= 48

SmartSize -10%|0|+10% size-adj as func(SymATR vs AvgC) - Cstm-Strad Sig= T.PppIR (IR=PltRtn ov'ride)
... license activates SmrtSiz DLL calc, in the generic OLang-shell Cond-Stops (else no Ppp change)
... requires longer TradePlan since Toe, Cnfrm & Norm entries can be multiples of 10, not just 20
Step 1 now has 15 entry-size Conditions 10-150
Then 15 same-bar BrokerSM steps for each size
Then 15 eventFX+Confirm steps ... Cnfrm can be 140+10, which if Toe=20+10, Max Net=160
... Toe=10, 15 Cnfrm-Cond's (net=20-160); Toe=20, 14C's; Toe=30, 13C's
... Toe=40, 12C's; Toe=50, 11C's; Toe=60, 10C's; Toe=70, 9C's (15+14+13+12+11+10+9= 84C's)
... All 15 of those steps also have Strad-Ctl Cond-FX for that Step1 size
Then 15 simple no-Condn BrokerSM-refresh steps if Confirm fired: Toe+Cnfrm = 20-160 by 10's
Then 15 Strad-Ctl Cond-FullX steps for sizes 20-160 (these & prior 15-steps *only* if Cnfrm)
So, total# "SmartEntry" TP Steps= 1+15+15+15+15= 59; Cond's= 15+15+15+84+14+14= 157

NOTE: SmartEntry TP w/SmrtSiz DLL also works w/20%-inc cases, so it replaces ScaleEntry TP

So, NEW Signal-Output map:
Signal (0= no sig for this bar) ... SigNAX (BrkFX based on H|L, others on C)
S.PppIR: Decimal Ppp = Order's %BaseSize (always mult of ten); I&R for SmartSize (Cstm only)
Integer 9-5 = Long ToeOrFullEntry, ConfirmEntry, AddOn, CondEvent-PX|FX, SMkt-BrokerXit
Integer 0-4 = Short ToeOrFullEntry, ConfirmEntry, AddOn, CondEvent-PX|FX, SMkt-BrokerXit
("Do-nothing" bars after a Long FullX = 5.000; after a Short FullX = 4.999 (FL sorts to middle)

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

'DC.PKB: Direction & Status-Colors (neg = in buffer or band w/white line)
'Dir: (EqtyF Pass) L=9|8, 5=None, S=1|2 (2&8=ToeSize) ... EqtyF Block: L=7|6, S=3|4
'Clr: 9=NrmNtr,8=AlrtT,7=BrytT,6=Cnfrm,5=Add,4=NcrV,3=SamV,2=DcrV,1=AnyWrn,0=AnyEnd
'decimal PKB= Slope, Stack, BarV color-states (-3 > +3 output as 2 > 8)

Add+PartCG:
'+5= yellow= part-grab
'0= gainsboro= add
'-5= gold= part-cut
'Full Exit:
'+10= midnitblue= vote|strip => warns|strip? (wrncnt tricky, strip obvious)
'-10= black= warns|reverse => oppvote|reverse? (diff clarified by 3strips)
'+11= indigo= zero-size (dedicated since net-size invisible on ribn+3strips)
'-11= darkslategray= broker-exit|eqty-blk (diff obvious from broker-line)
'+12= slategray= full-grab
'-12= gray= full-cut

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

Top of the page Bottom of the page
Jump to page : 1 2 3 4 5
Now viewing page 5 [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.