|
PureBytes Links
Trading Reference Links
|
Can anyone tell me how these MAJOR items are getting thru BETA testing ?
If fact, can anyone on this list stand up and say they were on the beta test
program ?
BTW: Who gets into the "elite" beta program ?
I have asked to be included, but have received NO RESPONSE from
mailto://beta@xxxxxxxxxxxxxxxxx
> -----Original Message-----
> From: Mark Jurik [mailto:mark@xxxxxxxxxxxx]
> Sent: Thursday, November 04, 1999 6:40 PM
> To: 'Omega List'
> Cc: 'mchale@xxxxxxxxxxxxxxxxxxx'
> Subject: SP3 Compiler Bug -- PART 1
>
>
> 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
>
>
>
>
>
>
|