|
PureBytes Links
Trading Reference Links
|
Bob Fulks wrote:
> You could also use the MRO function:
> if MRO(C <= C[1], 30, 1) > Length then
Good point! You'd think after I just gave an example using MRO that
I would have thought of that. :-) That's what I get for knocking
out a quick answer without thinking.
I believe MRO is smart enough to save the last MaxBarsBack results of
the C<=C[1] test so you don't have to recompute the test 30 times, so
all it has to do is a quick loop checking the last 30 results. That
internally-implemented loop is bound to be faster than my loop, and
the code is simpler too.
You might want to code it as
if MRO(C <= C[1], Length-1, 1) < 0 then
...to minimize the MRO work for smaller values of Length.
Pierre Orphelin wrote:
> Yes but there is a clever method that will avoid the for loop and
> take advantage of the maxbarsback concept:
> Vars: Idx(0);
> Condition1 = c>c[1];
> if Condition1 = then idx=idx+1;
That is quite a clever solution, Pierre, and fairly straightforward
as well. Nicely done.
You have an extra "=" in the if statement that should be removed.
Personally I wouldn't bother with the Condition1 variable:
if C > C[1] then idx = idx + 1;
> For a N=23 value you should expect a 22 times faster code.
This specific code fragment might be about 20-30x faster, yes. (You
can't predict an exact 22x improvement, given the other differences,
e.g. loop overhead and "barsback array" overhead in my example.)
But as you suggested, in most systems I suspect this small code
fragment will be a relatively small piece of the overall execution
time. One should not expect that their entire system will run 20-30x
faster due to this change. The overall system speedup will depend on
the percentage of system-execution time that the loop took. For
example, if my loop took up 30% of the overall system time, then a
30x speedup **in that loop** would speed up the system by 29%. If a
backtest of the system formerly took 100 seconds, the 30x speedup of
the 30% loop would reduce it from 30 seconds to 1 second, and the
backtest would now run in 71 seconds. Which is a worthwhile
improvement, but not 30x.
And that's why I focus more on clarity than on the fastest-possible
implementation. In *most* cases, the speed gained by going to an
obscure implementation is not, IMHO, worth the confusion. Especially
since system-execution time is very seldom a critical problem. Some
of the optimizations you've posted in the past, while clever, were
not (again IMHO) worth the loss of clarity in the code. They might
have shaved 1 or 2% off your system backtest times, but at a cost of
some pretty obscure code.
In this case, especially for larger values of N, your example would
be dramatically faster, AND it's fairly clear what's going on. I
think this is a good example of a worthwhile optimization.
Gary
|