|
PureBytes Links
Trading Reference Links
|
At 2:06 PM +1000 8/2/01, jonmac wrote:
>As a very green programmer with lesser knowlegde of maths;
>
>I been building a system based on use of COT interaction as a filter.
>I find it not only interesting, but figure I've almost a good start
>on the concepts visualised in the indicators I've built. Taken me
>forever. Next stage is to start on entry & exits. I'll probably be
>dead before I've got it together, but nevertheless....
>
>NOW after all this I'm wondering how these indicators would come
>together in respect of our lengthy discussion on precision.
>
>I wonder if its not too much to ask our best for, some very
>elementary detail (FOR NOVICES) on what to be wary of and
>workarounds, please?
>
>(Bob, I have your summary and noted the likes of "if Mod(currentbar,
>100) = 1". It appears a very simple fix, and from the way I read it,
>I presume it could always be used in place of "if currentbar = 1"? My
>request here is related to what could be used as a very basic list of
>scenarios/fixes).
This usually works well for cases where there is a different
calculation on CurrentBar = 1. As I mentioned, a few functions (such
as RSI) initialize with a different algorithm than they use for
succeeding bars because that is the way it was defined originally. It
should not be done in cases where certain variables are initialized
on CurrentBar = 1 because you will want them to retain their values
from bar to bar.
I often separate the things I want to do once from those I want to do
every 100 bars as follows:
Vars: Init1(TRUE), Init2(TRUE);
if Init1 then begin
<initialize variables one time only>
Init1 = FALSE;
end;
if Init2 or Mod(CurrentBar, 100) = 1 then begin
<complete calculations to be repeated every 100 bars>
Init2 = FALSE;
end else begin
<calculations to be done the other 99 bars>
end;
I use the variable "Init1" and "Init2" rather than "CurrentBar = 1"
in functions so that code will run on the first bar it is executed in
case that is not CurrentBar = 1 (if it is a "Simple Function"
enclosed in some "if ... then" statement.)
I usually want to know about "divide-by-zero" and
"subtract-near-equal-number" errors so often use the follow code:
if Denom <> 0
then Result = Numer / Denom
else Print(Date:7:0, Time:5:0, "Error XX");
where XX is some number. The Print Log then records cases where you
get this error. If it is just some weird combination of values that
occur occasionally then you can usually forget it and "Result" will
retain the value from the previous bar. But sometimes you find major
errors that need to be handled by different code or algorithms.
The subtract-near-equal-number" errors can be detected by code similar to:
If Term1 is always > 0 (often the case) you can use:
Result = Term1 - Term2;
if AbsValue(Result) < 0.0001 * Term1 then
Print(Date:7:0, Time:5:0, "Error XX");
If the terms can be either positive or negative you would need to
check additions also. This adds lots of calculations to the program
so I would only use it when the terms are big and complex, such as in
some statistical routines, and would comment it out after I was
satisfied that there was seldom a problem with that calculation.
As Dennis mentioned, it is always wise to build an indicator with
exactly the same code as your system to plot the key values. I ALWAYS
do this, even for the simplest systems. It is amazing what you find!
Something like the following code:
Inputs: IMode(2), ......
Vars: Init1(TRUE), Init2(TRUE, ....);
if Init1 then begin
<initialize variables one time only>
Init1 = FALSE;
end;
if Init2 or Mod(CurrentBar, 100) = 1 then begin
<complete calculation to be repeated every 100 bars>
Init2 = FALSE;
end;
<calculate the values of all variables here>
{=================System-only code========================}
<put Buy/Sell/Exits here>
{===============Indicator-only code=======================}
if IMode = 1 then begin {Subgraph1 Plots}
Plot1(Variable1, "1");
Plot2(Variable2, "2");
if FALSE then Plot3(0, "3");
if FALSE then Plot4(0, "4");
end;
if IMode = 2 then begin {Subgraph2 Plots}
Plot1(Variable3, "1");
Plot2(Variable4, "2");
if FALSE then Plot3(0, "3");
Plot4(0, "4");
end;
if IMode = 3 then begin {Subgraph3 Plots}
Plot1(Variable5, "1");
Plot2(Variable6, "2");
Plot3(Variable7, "3");
Plot4(0, "4");
end;
{===============End Indicator-only code===================}
Then copy/paste the EXACT SAME CODE in both the System (or "Signal"
in TS2000i) and Indicator. Comment-out the System-only code in the
Indicator and comment out the Indicator-only code in the system. Then
apply both the system and as many copies of the Indicator code (with
different values of IMode) as needed to cover all the key variables.
Look at the values of the indicators while the system is running to
confirm that they look "reasonable". With the Data Window, you can
read the actual values of the key variables.
Make sure the MaxBarsBack setting is the same for both the System and
all copies of the Indicators so all copies of the code see the
exactly the same values. When you run an optimization on the system
("Strategy" on TS2000i), you have to change the values of the inputs
on all of the copies of the Indicator so that they are the same (a
royal pain).
(There are more sophisticated versions of this technique that use
Global Variables to allow the Indicator values to actually be those
calculated in the System code but they require extra code modules.)
Many errors will become readily apparent on the plots. You can then
look into why each one occurs and take appropriate actions.
Of course, for simple things that you are just "researching", you can
be less demanding and just leave out the checks. But if you do not
take steps like this for a system you are going to trade, then you
are really asking for trouble. These techniques catch the
TradeStation precision errors we have been discussing and also give
you a much better idea of how your system is actually working on real
data.
I will post a chart illustrating this in the next message (to avoid
the size limit on messages.)
Bob Fulks
Bob Fulks
|