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

RE: Numeric instabilities - a brief show-and-tell demonstration



PureBytes Links

Trading Reference Links

I know that it is an illustrative example, but as it is far away from the
current TS Float limitation and usual TS use, I only wanted to highlight
that the huge difference should not be used to make any  assumption in this
sense.

It was obvious in your post, but it could not be for some people here.

The code you use is  of course recursive because it uses the previous
squared value to get the new one after differencing by a constant and
squaring the result again, hence the huge error propagated,also because also
the values used are close.

Anyway, if this kind of error was similar to what you usually do, you could
not even write a trading system with the mathematica 50 digit precision, so
I found the example a little bit exagerated when you write that you do this
kind of things every day.
No...
You do things that could be recursive, acumulating, but not without using
new data at the next iteration
This example is close to a fractal example rather that to technical analysis
of price series.

And the result on error propagation is not in the same order  of magnitude,
hopefully.

Sincerely,

Pierre Orphelin
www.sirtrade.com
Disclaimer:
No affiliation with TradeStation Technologies, just a satisfied independant
reseller and Open Platform program provider.


> -----Message d'origine-----
> De : MikeSuesserott [mailto:MikeSuesserott@xxxxxxxxxxx]
> Envoye : jeudi 2 aout 2001 21:39
> A : pierre.orphelin@xxxxxxxxxxxxxx; Omega List
> Objet : AW: Numeric instabilities - a brief show-and-tell demonstration
>
>
>
> > you do not exactly use such calculations in a
> > trading system.
>
> Pierre, you like to misunderstand, don't you? This was an illustrative
> example, to show the principle. Of course you do not use *exactly* this in
> trading. But you do use iterations which come up quite often, and the same
> danger is there.
>
> > The test code that you propose is a fully recursive one,
>
> If you look at the program code, you may realize that that code
> is iterative
> (just a loop), not recursive, though it would be possible to
> program it that
> way. I purposely did *not* use recursive programming to avoid any
> numerical
> side-effects.
>
> > where ALL the
> > previous values are squared from one bare to the next, what explains the
> > fast propagation of the error.
>
> And this is another error. There are *many* ways for this kind of
> instability to occur. Just a combination of multiplications and additions
> will sometimes suffice to bring it about. And the introduction of new
> information within the iteration process can be another source
> for the same
> kind of distortions. Perhaps if you say "pleeease" I'll write
> another little
> program to show this.
>
> > Maybe with 1000 digits precision, this kind of calculus  will be
> > of interest
> > someday...
>
> Didn't you see that this kind of thing came up after only 27
> times through a
> loop? I assure you this is a very real problem, but since you use
> TradeStation to test TradeStation, you don't see it.
>
> Michael Suesserott
>