|
PureBytes Links
Trading Reference Links
|
Gosh, Pierre wouldn't it be much easier to say "I was wrong!".
Regards, Randall
Tuesday, July 24, 2001, 19:54:45, you wrote:
>> -----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
>>
|