|
PureBytes Links
Trading Reference Links
|
Mark -
Just wanted to thank you for this information.......it actually solved
several problems in the SP2 release....with variables assigned from
NumericSeries Functions. I was getting wierd "-1.#J" return values until I
"forced" the compiler to define the ValueX variables as NumericSeries with
your subtle trick.
I have been reluctant to move-up to SP3 because of some of the performance
issues I've been reading about.....no doubt they are related to this new
addressing requirement which I believe exacts a LOT more overhead for the TS
compiler...and more importantly memory management and memory size
requirements.
My feeling is that Omega designers should have accomodated this with special
variable names such as SeriesValue1, SeriesValue2, etc....or permitted a
variable initialization to indicate a series variable: Variables:
MyVar(9999.999) <- "nines" indicate a series variable.
Instead, to make it easy on SOME the users, ALL of us must pay a performance
penalty.....again, another classic "tradeoff" and design decision was made
here without really consulting the experts.
> -----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
>
>
>
>
>
>
|