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

Re: Floating point error in SuperCharts



PureBytes Links

Trading Reference Links

MaxBarsBack is not a factor here as error occurs on identical data with
identical settings. Since writing the original note, I have some evidence to
back my assertion that DBZ/Overflow messages are displayed when the problem has
nothing to do with user code. Call it sloppy, or call it intentional, but the
net effect is that the user is led to believe he/she has screwed up when it's
the Omega software which is at fault. Here's an example - only the names have
been changed:

This does not give DBZ error in indicator QE: Plot1 = f_MTrend(InpA, InpB, InpC,
InpD, InpE, InpF, InpG, InpH)

System Version1 - this gives DBZ error in system QE: if MarketPosition <> 1 and
f_MTrend(InpA, InpB, InpC, InpD, InpE, InpF, InpG, InpH) > 0 then Buy Next Bar
at Market; if MarketPosition = 1 and f_MTrend(InpA, InpB, InpC, InpD, InpE,
InpF, InpG, InpH) < 1 then ExitLong Next Bar at Market

System Version 2 - copying Version 1 and wrapping conditions with "IFF" gets rid
of the DBZ error in system QE: if (iff(MarketPosition <> 1, 1, 0) +
iff(f_MTrend(InpA, InpB, InpC, InpD, InpE, InpF, InpG, InpH) > 0, 1, 0)) = 2
then Buy Next Bar at Market; if (iff(MarketPosition = 1, 1, 0) +
iff(f_MTrend(InpA, InpB, InpC, InpD, InpE, InpF, InpG, InpH) < 1, 1, 0)) = 2
then ExitLong Next Bar at Market;

This was tested in both SC4 and TradeStation4 with identical results. This is
not the first time I've run into a spurious DBZ/Overflow error, but it is the
first time I've been able to clearly isolate the failure as Omega's.

Earl

-----Original Message-----
From: Scientific Approaches <sci@xxxxxxxxxx>
To: Omega Mailing List <omega-list@xxxxxxxxxx>
Date: Saturday, March 07, 1998 12:05 PM
Subject: Re: Floating point error in SuperCharts


>Earl Adamy wrote:
>
>> Based upon experience using SC across 3 full versions and
>> many years of programming experience, I've come to conclusion
>> that Divide By Zero and/or Overflow messages are not only used
>> for DBZ/Overflow errors, but are used in lieu of proper error
>> handling of non-DBZ/Overflow errors.
>>
>> I don't remembe the details but I do remember getting both
>> overflow and divide by zero errors on perfectly good data using
>> Omega's own functions and studies.  I'm faced with an excellent
>> example right now. I have a user defined function which provides
>> trading signals. For testing purposes, I created an indicator
>> which calls the function using a series of inputs as arguments.
>> I used the indicator for well over a week through various
>> iterations of the function on the same data setup and never had
>> a problem not of my own making. When I had completed verifying
>> the signals, I created a system and literally copied the function
>> call from the indicator to the system. I added the system to the
>> same chart which contains the indicator expecting to see trading
>> signals. Instead I get a divide by zero error!
>
>That probably is due to the different Easy Language MaxBarsBack processing
>in user trading indicator and system programs.  An arithmetic overflow
>probably is occurring on the first price bar in the trading system program.
>Put a MaxBarsBack conditional test at the beginning of that program and I
>will be surprised if the error doesn't disappear.
>
>  -Bob Brickey
>   Scientific Approaches
>   sci@xxxxxxxxxx
>