|
PureBytes Links
Trading Reference Links
|
> -----Message d'origine-----
> De : Bengtsson, Mats [mailto:mats.bengtsson@xxxxxxxx]
> Envoyé : dimanche 5 août 2001 23:35
> À : pierre.orphelin@xxxxxxxxxxxxxx; omega-list@xxxxxxxxxx
> Objet : RE: Dmi flaw: final explanation and fixed version
>
>
> Nice to see we finally agreed it was a bug. Now we could jointly join the
> discussion with Gamble who sees it as a very large limitation. I
> do not want> to reopen the case, so I shall not go back on my proofs that
the TS float
> does not behave exactly as ordinary floats do. Even though the difference
> exits, the discussion will be around small differences and not as
> significant as this bug.
>
I never said that is was a TS bug ( related to the software core itself).
It's a bad programming issue ( somewhat tricky), or if you prefer a flaw in
the EL dmi code.
The float issue has nothing to do and however this is how you introduced the
dmi bug, that you gave as an example of the lack of porecision that you
attacked just before:
Here is your very first message introducing the dmi bug, and how elegant and
unbiased it was:
-----Message d'origine-----
> De : Bengtsson, Mats [mailto:mats.bengtsson@xxxxxxxx]
> Envoyé : lundi 16 juillet 2001 15:59
> À : Eskimo Omega List
> Objet : I think I have to change my opinion from bad precision to buggy
> calculations
> Tradestation is thus not just bad at calculactions only due to single
> precision logic. Neither is it unsuitable for backtesting stock data only
> due to the stupid notion of converting data from 1984 to integers
> based on a conversion factor suitable for price levels from 2001. It is
> actually buggy due to calculations using some math routines that are
lacking
> precisions in a way that I can not compare to anything but the old
Sinclair handheld
> calculators from 1974.
>
> Why did I discover this, which I can only see as a bug? What happened was
> that I got funny results during backtests, so I started tracking what
> happened. I knew that price conversion to integers was a source
> for very big errors, I knew that single precision would add to those
errors, I
> knew that figures shown would not be the real figures due to the decimal
> printout bug, but what I saw was accumulators accumulating to levels that
did
> not have to do with price errors or precision errors but something else.
The DMI
> calculations builds on accumulators (as seen in the code from where the
> enclosed indicator code comes). These accumulators accumulate when they
> should not, due to the above mentioned bug in calculations, increasing dmi
> levels when there should be no increases, resulting in exits
> coming way off from what they should. To this can then be added the single
> precision error in the calculations.
>
> To test, create a new indicator calling it whatever you like and
> insert the
> below code into it:
> var: plusdm(0);
> var: minusdm(0);
> var: plusdm1(0);
> var: minusdm1(0);
> (snip)
> It should plot a straight line at zero, but does not.
>
> --- Mats ---
No data example was given to verify, no analysis of the problem given.
The above explanation was wrong because it was not an integer conversion
issue ( no conversion occurs in a variable), so started the dmi discussion
on the wrong general path that was float vs double one message before.
> But I do like to point out that my first mail, the very first on
> this issue,> gave an exact example of when the error occurred, highs and
lows of two
> different days with the same problem as this last example, and an
> isolation of the code where it ocured.
See your message above. Nothing like this in this very first message. NO
DATA EXAMPLE.
Then you started with this FLOAT problem:
{Test Indicator, must plot Zero line}
Value1 = 10.387 - 10.280;
Value2 = 10.280 - 10.173;
If Value1 = Value2 Then Value1 = 0;
plot1 (Value1);
Then you gave data with dmiplus and better dmiplus values and code +
functions, but AGAIN WITHOUT THE PRICES:
-----Message d'origine-----
> De : Bengtsson, Mats [mailto:mats.bengtsson@xxxxxxxx]
> Envoyé : mardi 31 juillet 2001 23:32
> À : omega-list@xxxxxxxxxx
> Objet : FW: AW: TradeStation Precision - Summary with example
LAPOB,Date990416,OmegaDMI,11.425,BetterDMI,15.599,diff,-4.174,diffpercent,-2
6.76
LAPOB,Date990419,OmegaDMI,9.061,BetterDMI,12.372,diff,-3.310,diffpercent,-26
.76
LAPOB,Date990420,OmegaDMI,7.508,BetterDMI,10.251,diff,-2.743,diffpercent,-26
.76
>I have not counted the mails, but I did repeat that example, and 2 or 3
mails later, I gave another example with the same> results, and finally I
gave this last example, a couple of mails
> ago, and I have repeated those values in almost every mail to you since
then. The
> reason it took you so long to see it was not the lack of real examples, it
> was the way you defended Tradestation without stopping and
> thinking. It did trigger a lot of discussions though, so it might have
been more
> contributing this way, led to a lot of thoughts.
>
You never gave the price values, excepted these last days, making to
reproduce and understand the flaw impossible to me.
> The verbosity has to do with the different reasons you have
> given, each time> a new reason, some times contradicting a previous one.
The last one for
> example being that there is no epsilon in the calculation since all
> calculation are performed in longs.
I just printed the results from an other file and an other test. They were
showing no epsilon value at all, and this was first to verify the following
anomaly that does not show espilon values with the price function that I
used.
Value1 = 10.387 - 10.280;
Value2 = 10.280 - 10.173;
> A previous one stating that my correction, which utilised an epsilon value
in the same way as
> your current imitation, was a flaw of logic and caused the difference.
Another one that
> said that my copying the variable to a test caused the problem, ... All
> those warranted a number of lines of text to get you back to realities
> again.
>
I only tried to figure out where you could find such an anomaly without the
price data you used.
Just for the record, a few days ago, you started an other thread telling
that I had the Omega API server, what was not true, and heavily insisted on
it. Then you assumed that I was biased because of my supposed relationship
with omega. Do not ask me to be an angel after that. I'm not a masochist.
My last mail should show that it is not the case. I wanted proofs, not
gossip or things that could be gossip as usual with no in depth treatment of
the problem.
> By the way, I know that my function is not needed in this special
> case, your solution works, but I prefer to have a function that can be
used in all
> places where this kind of test is needed, and some of those places are not
> comparing prices. It is important not to lock onto price relative values,
> but values relative to the data compared.
This is of importance only if the comparizon of equal values has some
consequences, like resetting or not a non zero value
Anyway, I sure that all of the people have learnt something from this
painful thread, no exception admitted.
Sincerely,
Pierre Orphelin
www.sirtrade.com
TradeStation Technologies unbiased representative in France
|