[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SP3 Compiler Bug -- PART 1



PureBytes Links

Trading Reference Links

I've received several requests for a repost of my original message.....

=========== SP3 compiler bug ================

SP3 has introduced a compilation bug that, as far as I can tell, causes the explicit "SERIES" and "SIMPLE" type declaration in the Properties Box to be ignored.  With SP3, function type is determined as if "auto-detect" was selected.  With auto-detect, type simple is selected if no code inside the function refers to past values, that is, the lookback [ ] notation is not employed.  If historcal values are referenced by using lookback notation, then the function is automatically determined to be type series.

The problem that occurs by ignoring explicit SERIES/SIMPLE selections by the user is that code written prior to SP3 that uses no historical reference but was compiled as type series is now being compiled as type simple.

This will create all sorts of problems in code that was expecting a function to be type series.  Here are some of the problems that you may be experiencing after installing SP3.....

1.  Your trading system has the line ....

                  If MySeriesFunc1 crosses over MySeriesFunc2 then Buy;

The "crosses over" operation expects both functions to produce a time series.  However, if the code inside MySeriesFunc1 does not reference historical values, then it will verified as type simple, which does not produce a time series.  This does not stop the "crosses over" function from looking in memory for the historical value, and when it does, it reads in random garbage. When it then tries to interpret it as a floating point variable, you may get a FLOATING POINT ERROR message.

The fix is to convert the output of all functions to a local variable first, then refer to that variable.  So, in the example above, the problem is avoided the following way....

                Vars: MyFunc1(0), MyFunc2(0) ;
                MyFunc1 = MySeriesFunc1 ;
                MyFunc2 = MySeriesFunc2 ;
                If MyFunc1 crosses over MyFunc2 then Buy ;

The practice of storing function values into local variables often produces more efficient code, so its a good habit to get into anyway.


2.  Your indicator has your series function contained within conditional code, such as the following.....

                If close > close[1] then begin
                     value1 = MySeriesFunc ; 
                     end;

In this code, you are expecting MySeriesFunc to be assessed on every bar, even though it is being assigned to value1 only during certain conditions (when close > close[1]).  However, if this function is now verified under SP3 as a type simple, then MySeriesFunc will NOT be evaluated on every bar, completely destroying the integrity of the function.  You may get very different results that what you were getting before SP3.  

One way to avoid this type of problem is to make sure ALL series functions are evaluated unconditionally on every bar, starting at currentbar 1.  In the above example, you could avoid the problem as follows.....

              vars: MyFunc1(0) ;
              MyFunc1 = MySeriesFunc ;    { function is not within a condition block }
              If close > close[1] then begin
                     value1 = MyFunc1 ;         { assignment is still inside condition block }
                     end;

3.  MySeriesFunc1 requires an input of type NUMERICSERIES, and you intended to use MySeriesFunc2 to supply that input, as in the following code....

             value1 = MySeriesFunc1 ( MySeriesFunc2 ) ;

and inside MySeriesFunc1 you use historical values of that input, such as in the code...

	inputs: Series(NumericSeries);
	value1 = Series[10] ;

If MySeriesFunc2 is converted by SP3 into a type simple function, then it is not feeding a time series to MySeriesFunc1.  Nonetheless, the code inside MySeriesFunc1 is still going to look for historical values as if the time series did exist.  I have no idea what that will produce.  

The workaround is sneaky.  If you can open the affected function using the power editor, then you can guarantee it will be compiled as type series by placing at the end of the code a dummy command that references a historical value.  For example, you might append the following line of code....

             vars: ForceSeries(0) ;    ForceSeries = ForceSeries[2] ;

This will require that maxbarsback for that function be at least 2.

======================================================
ANNOUNCEMENT ......

Jurik Research will modify all its functions to avoid the SP3 bug and a new installer will be available on its web site 10:00pm, November 4.

Mark Jurik
Jurik Research
http://www.jurikresearch.com