|
PureBytes Links
Trading Reference Links
|
-----Message d'origine-----
De : Gary Fritz <fritz@xxxxxxxx>
À : omega-list@xxxxxxxxxx <omega-list@xxxxxxxxxx>
Date : dimanche 2 mai 1999 17:40
Objet : Re: Better Method
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.
====
Unfortunately not.
The MRO function is not coded internaly and uses EL code.
So, as it is called each bar, the while loop runs ( coud be shortern but
it's still a loop).
You can edit the MRO function in the Power Editor
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;
=====
This was typed directly in the Email software and not tested in the Power
Editor.
Of course the "=" is extra and would produce a Power Editor parser error.
I wrote condition1 in this cse in a general manner, because if you use this
code you may have a complex condition 1 if not using such simple things like
... c-c[1].
But you are right in this case, one line can be removed.
> 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.)
===
Yes, and I was considering only the loop length that is the main duration
between two codes.
Otherwise it's not a linear problem, as you pointed out.
Most of the optimisation coded that I proposed were not bound to spare 1%
of the time.
In this case, I would not post anything, even if Earl was the (ideal)
target.
Remember that I always compare the speed of the part of the code optimized
vs the same original part, regardless what could be done in the unchanged
code, not concerned.
Mainly, the optmization that were dealing with linearreg function and stddev
were worth to hav a look.
Sincerely,
.
-Pierre Orphelin
Représentant exclusif de Omega Research en France.
web: http://www.sirtrade.com
|