Can anyone code John Ehler's Empirical Mode Decomposition

• 01/24/2017 at 7:40 PM #22354
  Bard

  Hi, Is anyone able to covert this Empirical Mode Decomposition easy language code to PRT?  Thanks in advance.

  it’s a “novel approach for cycle and trend mode detection.” https://www.mesasoftware.com/papers/EmpiricalModeDecomposition.pdf

  <strong>BandPass Filter Code:</strong>

  1	<strong>BandPass Filter Code:</strong>

  Inputs: Price((H+L)/2), Period(20), delta(.1); Vars: gamma(0), alpha(0), beta(0), BP(0); beta = Cosine(360 / Period); gamma = 1 / Cosine(720*delta / Period); alpha = gamma - SquareRoot(gamma*gamma - 1); BP = .5*(1 - alpha)*(Price - Price[2]) + beta*(1 + alpha)*BP[1] - alpha*BP[2]; Plot1(BP); Plot2(0);

  1 2 3 4 5 6 7 8 9 10

  Inputs: Price((H+L)/2), Period(20), delta(.1); Vars: gamma(0), alpha(0), beta(0), BP(0); beta = Cosine(360 / Period); gamma = 1 / Cosine(720*delta / Period); alpha = gamma - SquareRoot(gamma*gamma - 1); BP = .5*(1 - alpha)*(Price - Price[2]) + beta*(1 + alpha)*BP[1] - alpha*BP[2]; Plot1(BP); Plot2(0);

  <strong>Code to Extract the Trend:</strong>

  1	<strong>Code to Extract the Trend:</strong>

  Inputs: Price((H+L)/2), Period(20), Delta(.1); Vars: gamma(0), alpha(0), beta(0), BP(0), Trend(0); beta = Cosine(360 / Period); gamma = 1 / Cosine(720*delta / Period); alpha = gamma - SquareRoot(gamma*gamma - 1); BP = .5*(1 - alpha)*(Price - Price[2]) + beta*(1 + alpha)*BP[1] - alpha*BP[2]; Trend = Average(BP, 2*Period); Plot1(Trend); Plot2(0); <strong>Code for the Empirical Mode Decomposition:</strong>

  1 2 3 4 5 6 7 8 9 10 11 12 13

  Inputs: Price((H+L)/2), Period(20), Delta(.1); Vars: gamma(0), alpha(0), beta(0), BP(0), Trend(0); beta = Cosine(360 / Period); gamma = 1 / Cosine(720*delta / Period); alpha = gamma - SquareRoot(gamma*gamma - 1); BP = .5*(1 - alpha)*(Price - Price[2]) + beta*(1 + alpha)*BP[1] - alpha*BP[2]; Trend = Average(BP, 2*Period); Plot1(Trend); Plot2(0);   <strong>Code for the Empirical Mode Decomposition:</strong>

  Inputs: Price((H+L)/2), Period(20), delta(.5), Fraction(.1); Vars: alpha(0), beta(0), gamma(0), //delta(.4), BP(0), I(0), Mean(0), Peak(0), Valley(0), AvgPeak(0), AvgValley(0); beta = Cosine(360 / Period); gamma = 1 / Cosine(720*delta / Period); alpha = gamma - SquareRoot(gamma*gamma - 1); BP = .5*(1 - alpha)*(Price - Price[2]) + beta*(1 + alpha)*BP[1] - alpha*BP[2]; Mean = Average(BP, 2*Period); Peak = Peak[1]; Valley = Valley[1]; If BP[1] > BP and BP[1] > BP[2] Then Peak = BP[1]; If BP[1] < BP and BP[1] < BP[2] Then Valley = BP[1]; AvgPeak = Average(Peak, 50); AvgValley = Average(Valley, 50); Plot1(Mean); Plot2(Fraction*AvgPeak); Plot6(Fraction*AvgValley);

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

  Inputs: Price((H+L)/2), Period(20), delta(.5), Fraction(.1); Vars: alpha(0), beta(0), gamma(0), //delta(.4), BP(0), I(0), Mean(0), Peak(0), Valley(0), AvgPeak(0), AvgValley(0); beta = Cosine(360 / Period); gamma = 1 / Cosine(720*delta / Period); alpha = gamma - SquareRoot(gamma*gamma - 1); BP = .5*(1 - alpha)*(Price - Price[2]) + beta*(1 + alpha)*BP[1] - alpha*BP[2]; Mean = Average(BP, 2*Period); Peak = Peak[1]; Valley = Valley[1]; If BP[1] > BP and BP[1] > BP[2] Then Peak = BP[1]; If BP[1] < BP and BP[1] < BP[2] Then Valley = BP[1]; AvgPeak = Average(Peak, 50); AvgValley = Average(Valley, 50); Plot1(Mean); Plot2(Fraction*AvgPeak); Plot6(Fraction*AvgValley);

  

  Bard

  Participant

  Topics: 131

  Replies: 809

  Been thanked: 99 times
  01/25/2017 at 8:14 PM #22482
  Nicolas

  “novel approach” .. since when? May I ask you some explanation about this? Don’t know why, but this kind of oscillator with bands reminds me of something coded earlier and I’m almost certain it was about Ehler too..

  Seems that I’ll jump into this project too. I will look at this as soon as possible. If you don’t get news by next Monday, please ring me here 🙂

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20828

  Been thanked: 4742 times
  01/25/2017 at 8:15 PM #22483
  Nicolas

  This indicator maybe? : https://www.prorealcode.com/prorealtime-indicators/super-bandpass-filter-john-ehlers/

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20828

  Been thanked: 4742 times
  01/27/2017 at 1:44 PM #22745
  Bard

  It’s “novel” in John Ehler’s “universe,” and for anyone else who likes trigonometry and can’t decipher his Superband Pass code… (-:

  Cycle Mode:

  “We begin by thinking of cycle mode in terms of frequency or its inverse, periodicity. Since the markets are fractal; daily, weekly, and intraday charts are pretty much indistinguishable when time scales are removed. Thus it is useful to think of the cycle period in terms of its bar count. For example, a 20 bar cycle using daily data corresponds to a cycle period of approximately one month.

  When viewed as a waveform, slow-varying price trends constitute the waveform’s low frequency components and day-to-day fluctuations (noise) constitute the high frequency components. The non-zero mean of filtered trending data changes relatively slowly compared to the cycle period (zero mean data). Therefore, if we measure the mean (or more approximately, the average (see blue horizontal lines)) of the cycle, this slow variation is a true reflection of the trend.

  Trend Mode:

  Market data is seldom as well behaved as we technicians would prefer. For example, an uptrend is marked by higher swing highs and higher swing lows. This means that our ideal sine wave generated by the phasor cannot be used without modification because a waveform with higher highs and higher lows will necessarily have a non-zero mean.

  However, the non-zero mean of filtered trending data changes relatively slowly compared to the cycle period. Therefore, if we measure the mean (or more approximately, the average) of the cycle, this slow variation is a true reflection of the trend.

  So we now have a method to empirically decompose the market data into a cycle component and a trend component. The cycle component is extracted by bandpass filtering the data. The trend component is extracted by averaging the bandpass filtered data over the most recent two cycle periods (to get smoothing without too much lag).”

  

  Bard

  Participant

  Topics: 131

  Replies: 809

  Been thanked: 99 times
  02/08/2017 at 10:54 PM #24449
  Bard

  Hi Nicolas, if you manage to get the time this could be worth adding to the Ehler’s indicators? I don’t know how it’ll compare to the Bandpass Filter?

  Also re: the Universal Supersmoother Oscillator, I have an Ehler’s MESA Period indicator to get cycle period lengths eg for a 1 hour or 10 min chart for example. Is that value suitable to enter as the frequency for the Bandedge in the Univ. Osc.? When it is used (usually values around 20 to 30) it never performs as well on backtests as say a 100 or 150 bandedge setting?

  Often I see very good results on the 10 min chart and 4 hours for the Univ. Osc. but not on the hour chart despite changing the bandedge and the 20/80% cut off values?

  Also when you get good results with the Bandedge/cut off values (without doing a full optimisation, i.e. just trying various settings e.g. change Bandedge from 100 to 150 and filter from 0.8 to 0.9), you can get the system to work over certain random periods of time like a month from 3 total months or for a week (using a 10 min chart) or even over years (using a day chart) but not 0ver the entire period that’s available to test (not ideal as you ”burn” the data in the sense that it’s now optimised). I can randomly pick many single week long periods at a time over a three month period (10 min chart) and they will be profitable 9 x’s out of 10 but just not over the entire period. I was hoping this Empirical Mode Decomposition indicator could be used in conjunction with the Univ. Osc.

  Also when I did a full optimisation (by adding the indicator code to the system code) for bandedge 5 to 150 in steps of 5, it returned the same maximum gain (20.69% pls see screen) for  every different bandedge value?

  Is the Walk Forward analysis the only way to go to test this phenomena where it’s profitable in many random sample periods but not over the entire period? Shouldn’t we just optimise to the latest current market conditions anyway?

  p.s. I cannot see the post I made in the forums two or three days ago about the Clenlow ATR Plunger? Subject Heading: “This looks interesting..“ and it has 4 charts. It’s not in the “my topics” in my account on here?

   

  Be interested to hear your thoughts,

  Cheers

  Brad

  

  Bard

  Participant

  Topics: 131

  Replies: 809

  Been thanked: 99 times
  02/15/2017 at 8:00 PM #25213
  Nicolas

  Hi Bard, I’ll try to get back on this interesting codes/topic later next week.

  About your “Clenlow ATR Plunger” : I did not see any topics named like this recently!  If it’s not in your topics list, it is not posted!

  1 user thanked author for this post.

  Bard

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20828

  Been thanked: 4742 times
  02/20/2017 at 10:10 AM #25707
  DAK

  I would also be interested in this indicator as I tried some time ago to code the Empirical Mode Decomposition but never really managed to. I’m still a beginner in programming.

  Having seen some examples I think it could be a very valuable indicator.

  Looking forward to Nicolas’ reply…

  

  DAK

  Participant

  Topics: 6

  Replies: 10

  Been thanked: 2 times
  02/20/2017 at 12:22 PM #25735
  Nicolas

  Please find below the empirical mode decomposition indicator code:

  //PRC_EmpiricalModeDecomposition | indicator //20.02.2017 //Nicolas @ www.prorealcode.com //Sharing ProRealTime knowledge //converted from EasyLanguage code Price = medianprice Period=20 delta=.1 Fraction=.25 if barindex>Period then beta = Cos(360 / Period) gamma = 1 / Cos(720*delta / Period) alpha = gamma - SqRt(gamma*gamma - 1) BP = .5*(1 - alpha)*(Price - Price[2]) + beta*(1 + alpha)*BP[1] - alpha*BP[2] Mean = Average[Period*2](BP) Peak = Peak[1] Valley = Valley[1] If BP[1] > BP and BP[1] > BP[2] Then Peak = BP[1] endif If BP[1] < BP and BP[1] < BP[2] Then Valley = BP[1] endif AvgPeak = Average[50](Peak) AvgValley = Average[50](Valley) endif return Mean as "mean", Fraction*AvgPeak as "avg peak", Fraction*AvgValley as "avg valley"

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

  //PRC_EmpiricalModeDecomposition | indicator //20.02.2017 //Nicolas @ www.prorealcode.com //Sharing ProRealTime knowledge //converted from EasyLanguage code   Price = medianprice Period=20 delta=.1 Fraction=.25   if barindex>Period then beta = Cos(360 / Period) gamma = 1 / Cos(720*delta / Period) alpha = gamma - SqRt(gamma*gamma - 1) BP = .5*(1 - alpha)*(Price - Price[2]) + beta*(1 + alpha)*BP[1] - alpha*BP[2] Mean = Average[Period*2](BP) Peak = Peak[1] Valley = Valley[1] If BP[1] > BP and BP[1] > BP[2] Then Peak = BP[1] endif If BP[1] < BP and BP[1] < BP[2] Then Valley = BP[1] endif AvgPeak = Average[50](Peak) AvgValley = Average[50](Valley) endif   return Mean as "mean", Fraction*AvgPeak as "avg peak", Fraction*AvgValley as "avg valley"

  If it’s ok for you, I’ll add it into the library for everyone’s benefit.

   

  2 users thanked author for this post.

  Bard, DAK

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20828

  Been thanked: 4742 times
  02/20/2017 at 12:25 PM #25738
  Nicolas

  @bard

  You get the same results for each optimised periods of “a”, because this variable is surely forced to another value into the strategy’s code. It’s a common mistake we all make..

  1 user thanked author for this post.

  Bard

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20828

  Been thanked: 4742 times
  02/22/2017 at 11:31 AM #26044
  Bard

  Did you mean that by adding the indicator code into the system code, that the indicator optimised “a” is not being optimised properly? What value is “a” being forced to and how?

  Cheers again Nicolas for the coding, I’ll take a look at the Empirical Mode Decomposition this week or next.
  Bard

  

  Bard

  Participant

  Topics: 131

  Replies: 809

  Been thanked: 99 times
• Author
  Posts