Crash in simple script with many trades per bar

Posted By: GPEngine

Crash in simple script with many trades per bar - 10/21/14 03:03

The following (silly) strategy Tested against AUD/USD using the official downloaded History dies for Error 111: Crash in script. at Bar 12034.

Why?

Code:

function run() {
  StartDate = 20090901;
  EndDate = 20140901;
  BarPeriod = 60;
  Hedge = 2;
  TradesPerBar = 256;

  var atrx = ATR(200);
  Stop = atrx * 3.0;
  Trail = atrx * 1.0;
  TrailLock = 50;
  int trade_num;
  for (trade_num = 0; trade_num < 147; trade_num++) {
    enterLong();
  }
}

Posted By: GPEngine

Re: Crash in simple script with many trades per bar - 10/21/14 03:06

If you change StartDate = 20090901; to StartDate = 20090101; you get a BADFREE2: TR as a bonus at Bar # 23993.

How could such a simple script go so wrong?

Posted By: jcl

Re: Crash in simple script with many trades per bar - 10/21/14 10:40

Thanks! The script looks perfectly normal and should not crash, yet it does - most likely due to the extreme number of trades. They will probably exceed the free memory. But it should then stop with an error message, instead of a crash. I'll forward this to the developers for fixing.

Posted By: GPEngine

Re: Crash in simple script with many trades per bar - 10/21/14 14:24

You're welcome!

What about the possibility of having Zorro survive this script rather than throwing an error or crashing?

Here's my use case
I am asking Zorro to compose a report which studies the outcomes of trades across several possible values of Stop, Trail, and TrailLock (and Entry too if it weren't for Bug Duplicate elements in all_trades w/ Entry + EntryTime limits) at every bar. I would like Zorro to collect the data for this report in a single pass through the History. Admittedly, it is easy to hit a combinatorial explosion with this plan. But, 147 trades per bar is an unworkably low limit.

Posted By: jcl

Re: Crash in simple script with many trades per bar - 10/22/14 17:06

The limit is far lower than 147 trades: it is 500 MB contiguous memory. For speed reason, trades are allocated before the simulation, not at runtime.

A possible solution would be a special "GPEngine mode" that allocates trades at runtime, or deletes trades when they are closed. In the former case the simulation would run noticably slower, in the latter case some statistics are not available, and OptF can not be calculated.