|
PureBytes Links
Trading Reference Links
|
> -----Message d'origine-----
> De : MikeSuesserott [mailto:MikeSuesserott@xxxxxxxxxxx]
> Envoye : jeudi 2 aout 2001 16:27
> A : Omega List
> Objet : Numeric instabilities - a brief show-and-tell demonstration
>
>
>
> Before we lay this topic to rest I would like to offer, as promised, two
> short programs (summary of results attached) to demonstrate some dangerous
> pitfalls described in my recent propositions. These were, briefly:
>
> -- 1. feedback processes (iterations) can lead to extreme numeric
> instabilities, with errors larger than the signal itself;
> -- 2. most software developers, and of course users, are totally
> unaware of these problems;
> -- 3. the said instabilities usually cannot be detected from within
> a software package but only through recalculation
> at a higher precision;
> -- 4. the instabilities are the ineluctable consequence of
> floating-point representation; though they cannot be avoided,
> the use of higher precision can, to a degree, delay some of the
> detrimental effects.
>
> The iteration example demonstrated below uses no advanced
> mathematics, only very simple basic math as probably used every day in EL
> programming (square a number, then subtract 2). The formula I chose
generates
> normalized numbers that will not grow out of bounds, but will stay roughly
between -2 and 2,
> for easier handling. In spite of this simplicity you will see that after
> less than 30 iterations (no 35000 are necessary!) the single-precision
> calculation will create errors of a magnitude of more than 100%, with all
> further iteration results in single precision proving totally meaningless
> and belonging purely to the realm of chance.
> Double precision fares somewhat better, though it also soon
> succumbs to the relentless powers of instability. After 58 iterations,
double-precision
> results become equally worthless.
Unfortunately, you do not exactly use such calculations in a trading system.
First, it will not allow to backtest on more than 58 bars if you use
doubles, and probably less than 200 using the 50 digits mathematica
precision.
The test code that you propose is a fully recursive one, where ALL the
previous values are squared from one bare to the next, what explains the
fast propagation of the error.
It's an EMA like code on steroids, and has no application in real trading
world, where the information from the new bar replace a part of the old one,
what is not the case in this example.
Maybe with 1000 digits precision, this kind of calculus will be of interest
someday...
Sincerely,
Pierre Orphelin
www.sirtrade.com
TradeStation Technologies representative in France
>
> Here are the programs, first C++, then Mathematica:
>
> -------------------------------------------------
> #include <condefs.h>
> #include <iostream.h>
>
> int main(int argc, char **argv)
> {
> float a[101]; // single precision
> double b[101]; // double precision
>
> a[0]=b[0]=0.5; // initial condition
>
> for (int i=1; i<=100; i++) // 100 iterations
> {
> a[i] = a[i-1]*a[i-1] - 2;
> b[i] = b[i-1]*b[i-1] - 2;
> cout<<"i="<<i<<" a["<<i<<"]="<<a[i]<<" b["<<i<<"]="<<b[i]<<"\n";
> }
>
> getchar();
> return 0;
> }
>
|