|
PureBytes Links
Trading Reference Links
|
At 4:07 PM -0500 3/25/02, Gene Pope wrote:
>Frankly, I cannot help but feel a little vindicated... I've been seeing
>these inconsistencies for months now... and most of the responses to my
>queries (not from Bob)... have been a polite brush off at best.
I was also confused by all the different results people were getting
so this prompted me to investigate further. A study I did last week
is posted at Mark Brown's <http://www.oddballsystems.com/> web site
under the heading NEW! Code Contributions in case you missed it.
Understand that the basic system idea clearly works well on "perfect"
data. In fact it is probably one of the best "public domain" systems
I have seen and a lot better than many systems costing thousands of
dollars. But you certainly need to modify the basic idea to work well
on "non perfect" (aka: "real") data...
>Add this to the problem of TS not calculating (especially on shorter
>intervals) on a particular bar if there is no valid price change
>(tick), and the whole notion of calculating on a time series and/or
>using multiple data's becomes a crap shoot.
As they say, "it's just a matter of programming," adding code to
handle all the special cases the system is likely to encounter. I
like the "autopilot" analogy. Creating an autopilot to fly a plane at
a fixed altitude to a fixed destination is very simple. But if you
want it to fly around areas of turbulence, find smoother altitudes,
dodge other planes and thunderstorms, as in real flying, it is a
lot more complicated...
A robust trading system has a lot of code to handle such special
cases. People try to use simple trading systems and wonder why they
don't work well in real trading. A simple system, like a simple
autopilot, is fine if the pilot is ready to turn it off and take
over the controls when something happens that the computer wasn't
programmed to handle...
>Now, perhaps your system concept is already robust enough to absorb
>such vagueness (and more power to you!), but it's frankly
>disheartening to be honing one's system skills when such errors can
>cause such erratic backtest results. How many man-hours of time have
>been collectively blown on the Omega list by this nonsense?
It is not the fault of the original OddBall code. That gives pretty
good results even on dirty data, but different results for different
people caused by data errors. The basic rate-of-change function is
very sensitive to noise on the data to start with. Short trading days
cause other errors. Using two data series adds subtle complexity when
bars are missing, etc. It is surprising that it works as well as it
does on "typical" data.
People with training in numerical analysis would recognize the
potential for errors. It sounds from your message as though you
understand that stuff...
>I've been a bit busy lately, but this is as good a time as any to
>share a reasonably simple method I found to work past the "missing
>interval" problem that I spoke of a while back. This solution was
>based on attempting to create a system using intervals of 10 mins and
>above (for example), on a chart that is 2 mins or less, including
>tick intervals.... in order to study the advantages of a higher
>compression as noise filter, vs. a shorter interval for stops or
>reversals or whatever other method might benefit from more
>granulatity. For my own reasons, I didn't want to mess with multiple
>data's, *particularly* when trying to track down these darn
>inconsistencies that kept cropping up. The solution, although
>tailored to my particular needs, may be of value in an oddball
>or any other type system.
I think people call this creating "synthetic bars". I spent several
days last week on code to do this, too, for another project. It is
very tricky if any bars are missing. That work clued me into the
potential problems with missing bars in OddBall.
I have some solutions I need to try and will post results later.
Bob Fulks
|