|
PureBytes Links
Trading Reference Links
|
Regarding data precision, I have been wrestling with the following
quandary. In VB, you have the option to choose single, double or
currency data types. When you can get away with it (your numbers fit
within the currency data type) wouldn't you be better off using the
Currency data type as opposed to single and double so that you would
be ensured of no rounding errors? By implementing a simple scaling
factor routine, it seems you could fit most numbers into the currency
data type (multiply or divide by a number like 10,000) without ANY
rounding errors at all.
What do you think about this?
Patrick White
Trading Sale Going On. There are still a few items left:
http://www.black-hole.com/users/spy/
-----Original Message-----
From: Robin B. Lake <rbl@xxxxxxxxxxxxxxxxx>
To: lwright@xxxxxxxxxx <lwright@xxxxxxxxxx>
Cc: omega-list@xxxxxxxxxx <omega-list@xxxxxxxxxx>
Date: Monday, June 21, 1999 12:19 PM
Subject: Re: EL precision can cause problems
Folks, I've been doing digital filtering for 30+ years, have a
A.M. degree in Applied Math, and used digital filters in my Ph.D.
dissertation.
There is a vast body of literature on digital filter design and the
precision REQUIRED for a class of digital filters to be STABLE (not
blow up). If you don't have the math precision cranked up, it
is equivalent to introducing random noise into the data and thus the
results. This is particularly true if you are dealing with RECURSIVE
digital filters, such as are found in very many indicators.
The so-called "stochastics" fall in this class, in that they use
the results of a prior filter calculation as part of the next filter's
calculation.
Simple filters, such as averaging filters won't be much affected
by lack of precision, as there are no "small differences between
large numbers" encountered and these results don't affect the next
calculation.
A MACD, on the other hand, uses a long chain of calculations over
historical data to produce the latest result. Single precision simply
won't give the right result. Or, worse yet, may produce an
oscillation
in the output or even blow up.
If it DOES blow up, at least you're lucky enough to know that
something
is wrong --- if it doesn't blow up and just put out bad results,
you're
screwed.
There is one serious commercial package that exhibits just this
behavior when an artificial step- or pulse-function is put in as
test historical stock price and/or volume data. Blows up about 72
days from time=0. Wonder why you're getting yanked around?
I implemented my system on a machine (not current technology) with
a parallel, vector, floating point processor just to get superb
accuracy until such time as I could "tune" the filters and determine
how much accuracy/precision is really required. The math I use is not
classical math, so the vast literature was of little help.
And,
by the way, fuzzy logic might well do well, but all the classic
indicators would have to be re-thought from scratch, for the art of
fuzzy recursive digital filters has not yet been well-developed. A
slight imprecision/inaccuracy in one step of a recursive fuzzy filter
could
quite easily lead to a mis-classification of all subsequent filter
outputs. Think about it.
Thus, I would not touch a system with single-precision math for
real-money
trading!
Cheers,
Rob Lake
rbl@xxxxxxxxxxx
> On Sat, 19 Jun 1999, The Omega Man wrote:
>
> >
> > I've said it before and I'll say it again: This debate over
precision is
> > ridiculous.
> >
> > Second, extra precision is not needed for trading. What's needed
for
> > trading is not more precision, but less. We need "fuzzy"
approaches, not
> > precise ones. Carrying calculations out to the nth decimal place
in a fuzzy
> > environment is ridiculous.
>
> Not so, but it does depend on what you try to do.
>
> Example: I built a digital filter outside TS, and then tried to run
it in
> TS. I could not put all the digits in TS, but I thought the TS
digits
> would be enough to operate OK.
>
> Well, guess what? The filter **crashed** TS. At first, I thought it
was my
> error, but after much looking, I finally traced the problem to a
lack of
> precision in EL! I found a different filter that would run OK, and
when
> the numbers approached the real filter, at some point it would crash
TS.
> Before the crash, one could see the numbers beginning to diverge and
> become very large.
>
> For some folks, precision does matter!
>
> (-: let's hear it for VB double precision :-).
>
> Larry
>
>
>
|