|
PureBytes Links
Trading Reference Links
|
The following are my observations as I have used TS and the
Powerediter. I do not have any inside information about how code runs
in TS. Some of my observations may be incorrect and if so I sure someone
will let me know.
1.) The first code items to be evaluated (calculated) on each bar are
not series functions but the values from the input statement (input:
length(25), Price(c), etc., etc.;). This can be shown by the code:
input: x(DMI(18));
var: y(0);
y=RSI(x,14);
plot1(y,"ser");
{plot2(x,"DMI");}
RSI is a series function and as such has been considered to be the first
item executed on each bar. But RSI can not be calculated until X is know
for a give bar. X will only be know if it is the first item to be
calculated on each bar. DMI is a simple function but the same results
are obtained for ADX, a series function. A value that varies from bar to
bar can be used as an input to a series function if it is part of the
input statement. A plot2(x,"DMI") will show how x changes with each bar.
Note that the function inside RSI can be substituted from the chart by
changing inputs.
If we write the following it will not work.
var: y(0);
y= DMI(18);
plot1(RSI(y,14);
Y must be known before the series function RSI can be calculated. But y
is a simple variable and therefore is calculated after a series
function. This is an impossible situation and results in an error. This
is the key to understanding series and simple functions. Series is the
first to be calculated (if there is no input statement).
2.) Simple functions (variables) do have histories and can, if coded
properly, be accessed to the extend of maxbarsback. The following code,
using the simple function DMI, verifies and computes, showing that past,
local, simple variables can be accessed.
var: z(0);
z=DMI(9)[2];
plot2(z,"DMI"); {or use z[2] with DMI(9)[0].}
An recently given example to show that simple functions are devoid of
history is
value1=SquareRoot(close)[4];
value3=SquareRoot(close[4]);
where it was said by the author that value1 produces an error message
and value3 verifies. Value1 will verify and gives exactly the same plot
as value3 if it is written as follows (this shows one of the many
idiosyncrasies of TS)
value1=(SquareRoot(close))[4];
plot4(value1,"sq");
Or
value1=SquareRoot(close);
plot4(value1[4],"sq");
Or with a different bars back and therefore, a slightly different plot
value3=SquareRoot(close[4]);
plot4(value3[2],"sq");
It is seen that the simple variables value1 and value3 have a history.
3.) About maxbarsback (MBB). Imagine a freight train box car with a
door open and you are inside looking out the open door. On the open door
side, the train passes by a picket fence which has 1000 pickets. You
will only see, say, 25 pickets at any one time but you will eventually
see all pickets. 25 is maxbarsback. The TS code can only, at any one
time, see back 25 pickets (bars) from the current (last) bar if MBB is
25. TS from any one bar can only see back MBB from that bar. Of course,
all bars will eventually be seen as the code moves along the bars, but
only through the maxbarsback window.
If maxbarsback for the code
var: z(0);
z=DMI(9)[0];
plot2(z,"DMI");
is User Set to 25, the plot does not start until 25 bars from the second
bar (the first bar seems never to be included in a calculation). That
is, the code is using the first 25 bars to start the calculation and
starts to show the results on the 25th bar. 25 bars may not be needed to
do (or start) a calculation but since that is the setting 25 will be
used. Now if DMI is referenced back 30 or 50 bars with [x] an error
message results. It can be referenced back 25 bars at a time from any
given bar and that is it.
Strange, inconsistent results can occur in TS if a set pattern in
testing code is not followed. At 1:00 am last night while testing the
above code, with MBB set at 20, I could reference back 30 bars ([30])
and the plot started at 15 bars from second bar on the graph! (Or at
least, I thought it did). Hitting F3 did not catch any error (?). This
morning, on reloading charting and the powerediter, everything worked
normally. As your final test of new code, reload it, do not fully depend
on F3 (maybe status on/off is the same as reloading, I use it a lot).
Other times, late at night, while programming code (not in TS) I have
gotten such strange results I thought the machine must have a virus only
to find in the morning it was cured.
Wayne Mathews
> Subject: > Re: Simple and Series Functions ?
> Date: > Mon, 6 Sep 1999 11:09:37 -0400
> From: > Bob Fulks <bfulks@xxxxxxxxxxxx>
>
> At 2:25 PM +0200 9/6/99, Philippe Lhermie wrote:
>
> >I read Jurik's article about Simple and Series Functions in Omega
> >Research Magazine.
> >
> >1. I understand that a Series function is always calculated first
> >even if it's embedded in a IF Then statment and whether this
> >condition is true or false ? Am I right?
>
> It is pulled out as if it were a separate program and executed on
> each bar. Thus, the inputs can only be constants or values related to
> a price that are known on each bar without referring to the other
> code in your program. They cannot be variables since the values of
> those variable might depend upon the context in your other code. Even
> if the variables do not depend upon the context in your code, Omega
> does not allow you to use variables as inputs to a series function, a
> major pain in the a--.
>
> >
> >2. In which case is it preferable to use a Simple Function ? may be
> >it's only when it performs a calculation not referring to some past
> >values of bars ago and because it consumes less RAM ?
>
> If the inputs to the function contain a variable, it has to be a
> simple function. If you designate it as a series function it will not
> verify. If it is a simple function, it cannot refer to a past value
> of a price or a variable with the "Close[4]" type of notation. You
> can write code to remember past values as in the following example;
>
> Val3 = Val2;
> Val2 = Val1;
> Val1 = Close;
>
> X = Close - Val3;
>
> Simple functions only get evaluated when they are called so if you
> call a simple function on every fourth bar, for example, the values
> will only be evaluated on every fourth bar, so in the above code
> example, you would be remembering only every fourth closing value. So
> if you are trying to remember every closing value, you have to be
> sure that the simple function is called on every bar:
>
> Incorrect:
> if <condition> then Value2 = SimpleFunction(A, B);
>
> Correct:
> Value1 = SimpleFunction(A, B);
> if <condition> then Value2 = Value1;
>
> In the first case, the function "SimpleFunction" is called only if
> <condition> is true so will not be called on every bar.
>
> In the second case, the function is called on every bar and equated
> to Value1. Then Value2 is set to Value1 only if <condition> is true.
>
> The situation can be tricky to determine as in the following example:
>
> if Close > 25 and SimpleFunction(A, B) > 4 then begin
>
> It looks as if "SimpleFunction" is called on every bar but this may
> not be the case. If "Close is less than 25" then the second part of
> the "if" statement may not be evaluated so the function may not be
> called on that bar. When in doubt, always equate the simple function
> to a variable and then use that variable in any complex expression as
> below:
>
> Value1 = SimpleFunction(A, B);
> if Close > 25 and Value1 > 4 then begin
>
>
> >
> >3. In a series function, when we use the brackets [x], how far in the
> >past can we go ? Up to the BarNumber 1( in order to take into account
> >the MaxBarsBack setting)?
>
>
> You can refer back as far as the MaxBarsBack setting. If you write an
> indicator and designate MaxBarsBack as AutoDetect, it will try to
> find a value that works. In complex situations, where the number of
> bars back is a variable dynamically determined at run-time, it can
> take it several attempts to find a value that works. This shows up
> slow operation as it tries various values. You can see this if you
> use a "Print" statement such that you print data on each trial.
>
> Many common functions (such as "Average") are provided in both series
> and simple versions and the system selects the proper one
> automatically. In most simple programs the distinction is invisible
> to the user and works pretty well. It is only when you start doing
> more complex operations that you have to be concerned with the
> distinction.
>
> Bob Fulks
|