OUT OF MEMORY pop up and WINDOWS VIRTUAL MEMORY SHORTAGE requiring a system reboot.

[demarcog]

In post http://forum.esignalcentral.com/show...=lowerDonchian I saw reference to the upperDonchian and lowerDonchian and have incorporated the code into a few strategies.

When those strategies are run for 30 days of 1 minute data on EUR A0-FX Esignal and my PC crashes requiring a reboot.


When a simplier function such as low() is substituted it runs for 1986 ms and 27K function calls according to the performance monitor.

When the donchian functions are run it takes 284000 ms, in elapsed time thats 2 seconds without the functions to almost 5 minutes with them on 10 days data, beyond that it crashes my system.

Either I'm invoking them incorrectly or something is definately wrong.

If the functions are being invoked correctly then I can't imagine that they would not have discovered this in the system release testing.

   if ((Strategy.isInTrade() == true) && (Strategy.isShort() == true) ) {
        TrailingStop = (1 + TrailingStopPercent) * lowerDonchian(BarsSinceEntry, low(),0);  
   //      TrailingStop = (1 + TrailingStopPercent) *  low(0);
         BarsSinceEntry = BarsSinceEntry + 1;
    }
   if ((Strategy.isInTrade() == true) && (Strategy.isLong() == true) ) {
        TrailingStop = (1 - TrailingStopPercent) * upperDonchian(BarsSinceEntry, high(),0); 
     //   TrailingStop = (1 - TrailingStopPercent) *  high(0);  
         BarsSinceEntry = BarsSinceEntry + 1;
    } 

[ACM]

demarcog
I ran the efs posted at the link you provided on a 30 day 1 minute chart of EUR A0-FX (total number of bars on chart is 42047) and it is not causing any out of memory messages and/or crashes at my end (see following image showing also the Performance Monitor).



Regardless in the case of that efs comparing the performance when using high(0) or low(0) in place of upperDonchian(...) or lowerDonchian(...) is like comparing apples and oranges.
This is because when you use high(0) or low(0) you are retrieving a single value and not calculating the highest or lowest values of a data series. Furthermore because in that efs the upperDonchian(...) and lowerDonchian(...) studies are not based on a constant lookback period they need to be created at every instance in which they are being called. This will use more resources than just retrieving a single value which requires virtually no computational time.
Alex

[demarcog]

Alexis,

Although the systems I work on conform to the eSignal requirements, I'm unable to run strategies with the lowerDonchian or upperDonchian functions on certain symbol/interval/duration combinations (especially symbols that trade 24 hours for anywhere near the 120 days).

I realize that retrieving a single value and parsing through a series created by the functions isn't a fair comparasion and apologize for implying that the performace should be comparable.

I thought perhaps 2 seconds versus 5 minutes elapsed time suggested something unintended was happening and it was my intent to bring this to your atttention as something that you may be interested in knowing.

Primarily because it took me so long to identify what specific statement in a 500 line strategy was causing the delay. I wanted to save someone else the time to narrow down such a illlusive problem.

As I have given up on my Renko based strategies this is again a real issue for my system development and would appreciate any suggestions for possible alternative coding techniques for duplicating this one invocation-namely finding the lowest low or highest high for a known number of intervals?

Note: after posting this I found the hh() and ll() functions which may be the solution...

Wanted to take this opportunity to wish you and your family a very Merry Christmas and all the helpful staff at eSignal a happy holidays as well.

Without the help and you and JasonK the chance of overcoming the unfavorable possibility of ever providing for ourselves and families thorough successful strategy development would be a virtual impossibility, for which generous assistance I can never thank you both enough.

Sincerely,

Glen