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

RE: Precision Errors



PureBytes Links

Trading Reference Links



> -----Message d'origine-----
> De : Bob Fulks [mailto:bfulks@xxxxxxxxxxxx]
> Envoyé : mercredi 25 juillet 2001 00:23
> À : pierre.orphelin@xxxxxxxxxxxxxx
> Cc : OmegaList
> Objet : RE: Precision Errors
>
>
> More on this seemingly endless thread. The short version:
>
>   > TradeStation numeric variables seem to be all single-precision
>     floats with a precision of +-2^24 = +-16,777,216
>
I will stay with the sort version...
According to your loop test, it seems exact.
So the 2^24-1 limit that I gave [ should read 2^(24-1)] = 2^23 = 8388608 was
taking in account 1 bit less from your own mail for the sign value, and is a
matter of notation, not of country location.
In this case it should mean that the sign value is coded outside the 24 bit
mantissa, and maybe explain why the exponent part (10^15 according to you)
is less than expected ( usually 10^+ - 38 for a float)


>   > TradeStation 4.0 can handle numbers as big as 2.147483 * 10^15
>     in some of the math routines. Beyond that they have big errors
>     (with no error messages).

Probably true.

>
>   > In response to several private messages from people wondering
>     why I think this is so important, I describe (with an example)
>     errors produced by the Omega LinearRegSlope function and show
>     alternate code for the same function that is much faster,
>     simpler, and more accurate.

You are right.
Your Linregslope version ( I have not verified, but I believe that it is
true) is clever and not sensitive to the Float precision effect.
This also means that the TS problem is not really a Double precision
problem, but first a coding problem.
In this sense, you are right to point out the fact that some EL functions
should have been more carefully written (I suspect that some of them came
from numerical calculus books, adapted to EL).
In this case, the fix should come from Omega and they need to replace the
considered version by a better one when apply.

Unfortunately,I do not have any influence on TRAD policy, but as you know
that they monitor this forum, they should know what to do.

You may reproach some hard attitude from me and you may be right.
But if I had not taken the counterpart on this list, most of these problem
would never have been solved ( or explained), because none would have digged
into these problem where the only solution was and has always been : We want
double, for years and there are bugs without doubles

To summary, we have now a better idea of:

-What is the float precision in TS
-What is a significative number of digits and how much are expected.
-What are the errors to avoid when performing precision operation and what
are the common interpretation errors on what precision or residual precision
really means. I' sure that some of the readers of this list have learned
from this discussion.
-Correct calculations can be made by using floats and smarter coding without
using double
-Some EL built in fuctions have to be recoded or a new  precision version
for each of them has to be added to the next EL library available.
-This also applies to any EL code that anyone could write, not only to
TRAD...

Thanks for your time and your inputs.

Sincerely,

Pierre Orphelin
www.sirtrade.com



>