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

RE: BEWARE: Pierre still has not understood that DMI is incorrect



PureBytes Links

Trading Reference Links

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");

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.

Only one data, only one day, the first day printed for that symbol LAPOB in
the previous mail from me. The same goes for all the other dates, all the
other symbols with the same error. This is a good example, you are likely to
have similar data in your own symbol list.

First date: High=6.800,low=6.550
Second date:High[1]=6.750,low[1]=6.600, 
Full precision high minus high[1]=plusDM=0.050
Full precision low[1] minus low=minusDM=0.050
Comparison value used in MIBGREATEREQUAL=0.000005
Comparison done in MIBGreaterEqual=0.050>=0.050-0.000005 or: 0.050>=0.049995
MIBGREATEREQUAL=true gives plusdm=0.000

But, since 0.1 can not be exactly represented in Omega Tradestation:
Comparison done by Omega 0.04999999999>=0.05000000 gives oldplusdm=0.050
Result: Better DMI =plusdm14[1]-(PlusDM14[1]/MyRange)+0
Result: Omega standard DMI=OldDM14[1]-(OldDM14[1]/MyRange)+0.050

Result: Better DMI dminishes slightly, Omega DMI grows slightly.
Resulting difference after one bar: 27%, not in the 7th digit,  in the very
first digit, and more than so.

Reiteration of what MIBGreaterEqual does:
It simulates the logic of x>=y by saying that equality can be the case of
both values being equal in the decimal world, but values being different in
the binary world. For example the values above (thus the error in the omega
dmi calculation) is the same in the decimal world, but differs in the binary
world. By adjusting the value y with a very slight value (behind the 5 digit
input data accuracy, near the 7 digit accuracy range) the subtracted value
is so low that the comparison >= works, x is bigger than y minus a very
small figure, but since the Omega DMI does not make that comparison, the
little error of epsilon results in the comparison saying "it is less" when
it should say "it is greater or equal".

If you do not read my mails, if you do not read Bobs mails, then please read
your own mails. It is mentioned in them a number of times (your own estimate
was 150 posts). A number of them dealing with 10.1-10.3. Read you very own
explanation on why they do not come out as exactly equal, even if they are
equal in the decimal world. Read your very own explanation of what needs to
be dones to compare them correctly. Read your own explanation why you can
not expect a comparison without including epsilon to give the right result.
Read your own explanation why the values are correct to the 6 digits Omega
can sometimes keep track on, but still do not compare as >= in a direct
test. Read the mails from some kind of school physics teacher if you do not
read mine or Bobs.

Still trying to get through to you in some way
--- Mats ----



This message contains information that may be privileged or confidential and is the property of the Cap Gemini Ernst & Young Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.