|
PureBytes Links
Trading Reference Links
|
> -----Message d'origine-----
> De : Bengtsson, Mats [mailto:mats.bengtsson@xxxxxxxx]
> Envoyé : jeudi 2 août 2001 23:23
> À : pierre.orphelin@xxxxxxxxxxxxxx; omega-list@xxxxxxxxxx
> Objet : RE: BEWARE: Pierre still has not understood that DMI is
> incorrect
>
>
> Pierre, please be careful, somebody actually might believe you, and they
> might lose a lot of money from believing you instead of believing in the
> truth. You have been so much in affect (probably still are) that
> you do not
> even remember how this thread came up, and the examples that was in that
> thread. The error in your reasoning is illustrated by the below code
> segment, please run it:
>
> value1=6.800-6.750;
> value2=6.600-6.550;
> if value2>=value1 then
> print ("value2>value1")
> else
> print ("Pierre is still totally wrong and so is the Omega DMI
> function");
>
Yes, I see the problem.
The infamous message appears, but it is wrong
Now, try this ( TS2000):
==========================
value1=h+l+h[1];
value2=2*h+l+o-o-h+h[1];
if value2=value1 then
messagelog ("value2>value1")
else
messagelog ("Pierre is still totally wrong and so is the Omega DMI
function");
messagelog(value1:5:15," ",value2:5:15);
Of course value1 and value2 are equal, for all price bars
Can you get get the message telling that I am wrong? NOOOOOOOOOOOOOOOOOOOO!
You cannot!
Now use the print ( message log feature and see what happens with data that
are price and data that are numeric values passed to a variable like in your
example.
In the first case, the calculus made from price data never fails (otherwise,
not only the DMI would be affeced but even a simple candlestick pattern will
be too).
The reason is that TS reads the full price precision available from the
price database in the first case, and in the second case, it treats the
variable with the float precision.
This explains why you problem do not fail with the price data and fails with
the decimal directly passed to a variable, where the epsilon error is
created.
> Now, after running the code and astonishing yourself with the result, read
> the below explanation. I have include more data about the Omega DMI error
> example below (I am getting quite tired of this, you will get
> only one data and only one explanation for that data, we have been through
this so many
> times with a number of examples already, examples you yourself agreed on,
> even explained why it had to be so). This time I do not do this for you,
> because I do not think you will admit to the bugs that are there, not even
> remember the output of the above code. I do this for the rest on the list
> who might think you were right if they read your mails.
>
I do not have your data and your TS4 software so I'm unable to verify (and
I'm not very interested)
Of course, if one >= test fails and sets dmiplus to 0 , it's normal to have
a huge jump that will be cause by the epsilon error.
But again, the function that you have added to your code can produce the
same drawback when it is called and when it is not necessary ( and it is
not, because the dmplus calculus only use price data, in one pass). Moreit
will make fail when the "=" condition is really true!
So, from today, you should have learned that TS works on price data, with
the requested precison ,and that the roundoff errors do not exists from
price data results that should be equal from different formula ( what is the
case for the Dmi), but that this test fails if you use TS as you do with a
palm calculator ( eg adding numbers passed by value to a variable).
I guess that the solution to your problem has rather to do with a local
error in the price database than with the code, because I am not able to
reproduce your false results.
The current score is:
Omega List :3 ( Credited to Bob Fulks)
Pierre Orphelin : >=10 (roughly)
Sincerely,
Pierre Orphelin
www.sirtrade.com
TradeStation Technologies representative in France
|