Jump to content

Welcome to the new Traders Laboratory! Please bear with us as we finish the migration over the next few days. If you find any issues, want to leave feedback, get in touch with us, or offer suggestions please post to the Support forum here.

  • Welcome Guests

    Welcome. You are currently viewing the forum as a guest which does not give you access to all the great features at Traders Laboratory such as interacting with members, access to all forums, downloading attachments, and eligibility to win free giveaways. Registration is fast, simple and absolutely free. Create a FREE Traders Laboratory account here.

Aston01

Smoothing Color Change in MA Signal Line ?

Recommended Posts

Has anyone come across a good technique for smoothing the color defining transitions without disturbing the entry and exit points of blatant directional changes?

 

I am sure inevitably someone is going to come on here and say that further smoothing of an MA will lessen false signals but delay entry, and I don't disagree.

 

BUT due to the standard way of coding a color alternating signal line being an either or approach, minuet changes in the direction are approached as veritable True or False in nature. All of this ultimately allowing for what I personally refer to as micro chop or false signals.

 

HMAChopMicro.jpg

 

 

I have had some success in limiting the issue by replacing the standard price input with (High + Low)/2 as opposed to Close, as well as changing the number of look back bars from 1 to 2.

 

 

{ Color criteria }
if (Value1 > Value1[2]) then 
SetPlotColor[colourDeltaBar](1, upColour)
else if (Value1 < Value1[2]) then 
SetPlotColor[colourDeltaBar](1, downColour);

 

I have contemplated using a percentage of variance or some form of a slope calculation to allow for a margin of error, but I just can't seem to wrap my head around which would be more effective and adaptive to various circumstances.

 

Any suggestions would be much appreciated.

Share this post


Link to post
Share on other sites
Has anyone come across a good technique for smoothing the color defining transitions without disturbing the entry and exit points of blatant directional changes?

 

I am sure inevitably someone is going to come on here and say that further smoothing of an MA will lessen false signals but delay entry, and I don't disagree.

 

BUT due to the standard way of coding a color alternating signal line being an either or approach, minuet changes in the direction are approached as veritable True or False in nature. All of this ultimately allowing for what I personally refer to as micro chop or false signals.

 

HMAChopMicro.jpg

 

 

I have had some success in limiting the issue by replacing the standard price input with (High + Low)/2 as opposed to Close, as well as changing the number of look back bars from 1 to 2.

 

 

{ Color criteria }
if (Value1 > Value1[2]) then 
SetPlotColor[colourDeltaBar](1, upColour)
else if (Value1 < Value1[2]) then 
SetPlotColor[colourDeltaBar](1, downColour);

 

I have contemplated using a percentage of variance or some form of a slope calculation to allow for a margin of error, but I just can't seem to wrap my head around which would be more effective and adaptive to various circumstances.

 

Any suggestions would be much appreciated.

 

there are hundreds of ways to smooth a MA...

 

eg.

 

use medianprice instead of close

Share this post


Link to post
Share on other sites

Aston,

 

Preface: :) For real life, though, you said it just right with

I have contemplated using a percentage of variance or some form of a slope calculation to allow for a margin of error, but I just can't seem to wrap my head around which would be more effective and adaptive to various circumstances.

 

The simplest, non-adaptive start I can give you

[pseudocode]

inputs:
…
nSdevLen(200),
…
nBrktMlt1(.6),   { manually tweak this input and your value1’s length parameter to get goldilock’s settings }
…

// also add a flatColor(neutralcolor) input...		
;

vars:
…
degree(0),
sdev(0),
colorThreshold(0),
…
;

//////////////////
{Color criteria}
degree = absvalue(arctangent(nlAvg- nlAvg[1]));
sdev = stddev(degree, sdevLen);
colorThreshold = sdev * nBrktMlt1;

{ 
notes: 
> [2] changed to [1] throughout this example - why wait?  .  
> nlAvg equivalent to your Value1…
}


if (degree <=  colorThreshold)  then begin
 SetPlotColor(1, flatColor);

end else begin
if (nlAvg > nlAvg [1]) then     
  SetPlotColor(1, upColor)

else
 SetPlotColor(1, dnColor;

end;   // if (degree >  colorThreshold)

 

///

 

 

This concept could also be modified to keep the dnColour during your red circle (because angles haven’t changed sufficiently to up )

 

You could also get more fuzzy using GradientColor reserved word, etc. hth

Share this post


Link to post
Share on other sites
Has anyone come across a good technique for smoothing the color defining transitions without disturbing the entry and exit points of blatant directional changes?

 

I am sure inevitably someone is going to come on here and say that further smoothing of an MA will lessen false signals but delay entry, and I don't disagree.

 

BUT due to the standard way of coding a color alternating signal line being an either or approach, minuet changes in the direction are approached as veritable True or False in nature. All of this ultimately allowing for what I personally refer to as micro chop or false signals.

 

HMAChopMicro.jpg

 

 

I have had some success in limiting the issue by replacing the standard price input with (High + Low)/2 as opposed to Close, as well as changing the number of look back bars from 1 to 2.

 

 

{ Color criteria }
if (Value1 > Value1[2]) then 
SetPlotColor[colourDeltaBar](1, upColour)
else if (Value1 < Value1[2]) then 
SetPlotColor[colourDeltaBar](1, downColour);

 

I have contemplated using a percentage of variance or some form of a slope calculation to allow for a margin of error, but I just can't seem to wrap my head around which would be more effective and adaptive to various circumstances.

 

Any suggestions would be much appreciated.

 

Hi Aston,

 

I have been using a heat-map approach to determining support and resistance for my grid trading application. This technique could be adapted to MAs, Please see my last blog post here and then PM me if you are interested in pursuing.

 

Best

 

John

Share this post


Link to post
Share on other sites

Tams - I gave median a whirl and it seemed make an improvement in the smoothing without much lag...Thanks for the idea

 

John - Interesting idea ..I'll have to do some more reading on it

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Topics

  • Posts

    • I'm pretty sure that a Russian resident would say that recessions are real today. Their prime interest rate is 21%, their corporate military contractors are threatening to file bankruptcy, and sticks of butter are kept under lock and key in their grocery stores because shoplifters are stealing it in bulk so they can resell it on the black market. A downturn is cyclical until it turns into a collapse. I really don't think anyone will be buying-into this mess.😬
    • Well said. This principle is highly analogous to trading. Any human can easily click buy or sell when they "feel" that price is about to go up or down. The problem with feeling, commonly referred to as "instinctive" trading, is that it cannot be quantified. And because it cannot be quantified, it cannot be empirically tested. Instinctive trading has the lowest barrier to entry and therefore returns the lowest reward. As this is true for most things in life, this comes as no surprise. Unfortunately, the lowest barrier to entry is attractive to new traders for obvious reasons. This actually applied to me decades ago.🤭   It's only human nature to seek the highest amount of reward in exchange for the lowest amount of work. In fact, I often say that there is massive gray area between efficiency and laziness. Fortunately, losing for a living inspired me to investigate the work of Wall Street quants who refer to us as "fishfood" or "cannonfodder." Although I knew that we as retail traders cannot exploit execution rebates or queues like quants do, I learned that we can engage in automated scalp, swing, and trend trading. The thermonuclear caveat here, is that I had no idea how to write code (or program) trading algorithms. So I gravitated toward interface-based algorithm builders that required no coding knowledge (see human nature, aforementioned). In retrospect, I should never have traded code written by builder software because it's buggy and inefficient. However, my paid subscription to the builder software allowed me to view the underlying source code of the generated trading algo--which was written in MQL language. Due to a lack of customization in the builder software, I inevitably found myself editing the code. This led me to coding research which, in turn, led me to abandoning the builder software and coding custom algo's from scratch. Fast forward to the present, I can now code several trading strategies per day across 2 different platforms. Considering how inefficient manual backtesting is, coding is a huge advantage. When a new trading concept hits me, I can write the algo, backtest it, and optimize it within an hour or so--across multiple exchanges and symbols, and cycle through hundreds of different settings for each input. And then I get pages upon pages of performance metrics with the best settings pre-highlighted. Having said all of this, I am by no means an advanced programmer. IMHO, advanced programmers write API gateways, construct their own custom trading platforms, use high end computers with field programmable gateway array chips, and set up shop in close proximity to the exchanges. In any event, a considerable amount of work is required just to get toward the top of the "fishfood"/"cannonfodder" pool. Another advantage of coding is that it forces me to write trade entry and exit conditions (triggers) in black & white, thereby causing me to think microscopically about my precise trade trigger conditions. For example, I have to decide whether the algo should track the slope, angle, and level of each bar price and indicator to be used. Typing a hard number like 50 degrees of angle into code is a lot different than merely looking at a chart myself and saying, that's close enough.  Code doesn't acknowledge "maybe" nor "feelings." Either the math (code) works (is profitable) or doesn't work (is a loser). It doesn't get angry, sad, nor overly optimistic. And it can trade virtually 24 hours per day, 5 days per week. If you learn to code, you'll eventually reach a point where coding an algo that trades as you intended provides its own sense of accomplishment. Soon after, making money in the market merely becomes a side effect of your new job--coding. This is how I compete, at least for now, in this wide world of trading. I highly recommend it.  
    • VRA Vera Bradley stock watch, pull back to 5.08 support area at https://stockconsultant.com/?VRA
    • MU Micron stock watch, pull back to 102.83 gap support area with high trade quality at https://stockconsultant.com/?MU
    • ACLX Arcellx stock watch, trending at 84.6 support area with bullish indicators at https://stockconsultant.com/?ACLX
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.