Gamestudio Links
Zorro Links
Newest Posts
Data from CSV not parsed correctly
by EternallyCurious. 04/25/24 10:20
Trading Journey
by howardR. 04/24/24 20:04
M1 Oversampling
by Petra. 04/24/24 10:34
Zorro FIX plugin - Experimental
by flink. 04/21/24 07:12
Scripts not found
by juergen_wue. 04/20/24 18:51
zorro 64bit command line support
by 7th_zorro. 04/20/24 10:06
StartWeek not working as it should
by jcl. 04/20/24 08:38
folder management functions
by VoroneTZ. 04/17/24 06:52
AUM Magazine
Latest Screens
The Bible Game
A psychological thriller game
SHADOW (2014)
DEAD TASTE
Who's Online Now
5 registered members (AndrewAMD, TipmyPip, VoroneTZ, Quad, 1 invisible), 688 guests, and 11 spiders.
Key: Admin, Global Mod, Mod
Newest Members
Mega_Rod, EternallyCurious, howardR, 11honza11, ccorrea
19048 Registered Users
Previous Thread
Next Thread
Print Thread
Rate Thread
Verifying "Those cycles are not found in random data." #449044
03/02/15 07:03
03/02/15 07:03
Joined: Sep 2013
Posts: 504
California
G
GPEngine Offline OP
User
GPEngine  Offline OP
User
G

Joined: Sep 2013
Posts: 504
California
The manual page on Trading Strategies
http://zorro-trader.com/manual/en/strategy.htm says
"Another effect - a real inefficiency that can be exploited in strategies - is visible in the following spectral analysis chart:" and goes on to say "Cycles arise from synchronized trading behavior and are not necessarily aligned to days or weeks. Those cycles are not found in random data."

The spectral analysis chart presented in that section is compelling at first glance. There are several well-defined peaks implying some inefficiency at certain cycles. But Spectral analysis of a random-walk timeseries also results in a set of well-formed peaks. This one, for example, has a nice juicy peak to draw your attention to a cycle of ~= 80 hours. The AVG amplitude (39) is nearly as high as the one discussed in the manual (41 @24hrs), and higher than all the others mentioned. An even more significant peak (42) sits at 146 hrs. Of course, this is all meaningless since the series behind it was generated by the Random.c script.
Code:
function run() {
  BarPeriod = 60;
  StartDate = 20080101;
  EndDate = 20150101;
  LookBack = 500; // 2 x highest Cycle

  vars Random = series(0);
  if(Bar == 1) {
    Random[0] = price();
  } else {
    Random[0] = Random[1] + 0.01 * random();
  }

  plot("Random",Random[0],0,BLUE);
  int Cycle;
  for (Cycle = 5; Cycle < 250; Cycle += 1) {
    plotBar(
    	  "Spectrum", Cycle, Cycle, Spectrum(Random,Cycle), BARS+AVG+LBL2, RED);
  }
}

Can you identify anything different about the attached graph compared to the one in the manual? In general, what supports the assertion that the cycles on display in the chart do not appear in random data?

Attached Files
randspec_EURUSD_s.png (22 downloads)
Re: Verifying "Those cycles are not found in random data." [Re: GPEngine] #449052
03/02/15 14:56
03/02/15 14:56
Joined: Jul 2000
Posts: 27,982
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,982
Frankfurt
Very good question. Spectral peaks also appear in random data when not enough samples are used. This is the case here, so the statement in the manual is not sound. The spectrum function here uses only about 500 samples, and thus is not really suited for proving that a spectral inefficiency exists. It is only for finding the peaks of the current snapshot of a spectrum, under the assumption that those peaks already do exist.

This is due to the nonstationarity of price data. We should look deeper into this and provide a function that samples a larger amount of data for the spectrum, so that it's still quasistationary, but can be distirguished from random data.

Re: Verifying "Those cycles are not found in random data." [Re: jcl] #449068
03/03/15 04:01
03/03/15 04:01
Joined: Sep 2013
Posts: 504
California
G
GPEngine Offline OP
User
GPEngine  Offline OP
User
G

Joined: Sep 2013
Posts: 504
California
Was this chart enough to convince you that Z1 % Z2 would work, or did it take something with more depth?

Re: Verifying "Those cycles are not found in random data." [Re: GPEngine] #449073
03/03/15 08:42
03/03/15 08:42
Joined: Jul 2000
Posts: 27,982
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,982
Frankfurt
Z1 and Z2 are relatively simple trend and counter trend systems similar to those in the tutorial. They have nothing to do with the chart or the spectrum function.

Re: Verifying "Those cycles are not found in random data." [Re: jcl] #449329
03/15/15 11:00
03/15/15 11:00
Joined: Feb 2014
Posts: 181
R
RTG Offline
Member
RTG  Offline
Member
R

Joined: Feb 2014
Posts: 181
Doesn't the dominantPeriod function take the most dominant cycle period of the past x bars?

That is, it deals with this issue?

Re: Verifying "Those cycles are not found in random data." [Re: RTG] #451311
05/02/15 05:22
05/02/15 05:22
Joined: Sep 2013
Posts: 504
California
G
GPEngine Offline OP
User
GPEngine  Offline OP
User
G

Joined: Sep 2013
Posts: 504
California
Sounds nice doesn't it?

Re: Verifying "Those cycles are not found in random data." [Re: jcl] #457111
12/26/15 17:53
12/26/15 17:53
Joined: Sep 2013
Posts: 504
California
G
GPEngine Offline OP
User
GPEngine  Offline OP
User
G

Joined: Sep 2013
Posts: 504
California
Originally Posted By: jcl
Very good question. Spectral peaks also appear in random data when not enough samples are used. This is the case here, so the statement in the manual is not sound. The spectrum function here uses only about 500 samples, and thus is not really suited for proving that a spectral inefficiency exists. It is only for finding the peaks of the current snapshot of a spectrum, under the assumption that those peaks already do exist.

This is due to the nonstationarity of price data. We should look deeper into this and provide a function that samples a larger amount of data for the spectrum, so that it's still quasistationary, but can be distirguished from random data.


I am surprised you continued to use charts like this in http://www.financial-hacker.com/build-better-strategies-part-2-model-based-systems/ December 25, 2015

Re: Verifying "Those cycles are not found in random data." [Re: GPEngine] #457126
12/28/15 10:15
12/28/15 10:15
Joined: Jul 2000
Posts: 27,982
Frankfurt
jcl Offline

Chief Engineer
jcl  Offline

Chief Engineer

Joined: Jul 2000
Posts: 27,982
Frankfurt
The spectrum function has a parameter for setting the data amount. That was already implemented some time ago.

Aside from that: The mere existence of peaks in a spectrum is indeed no proof of cycles in the price curve, since short-lived cycles are in fact found in random data when you look only at a short period. It's the same for almost all inefficiencies. A single 1-week trend, mean reversion, or cycle can be real or just random. For determining a real inefficiency, you must look at a long period of price data and check if the anomalies occur more often than in random data.


Moderated by  Petra 

Gamestudio download | chip programmers | Zorro platform | shop | Data Protection Policy

oP group Germany GmbH | Birkenstr. 25-27 | 63549 Ronneburg / Germany | info (at) opgroup.de

Powered by UBB.threads™ PHP Forum Software 7.7.1