|
PureBytes Links
Trading Reference Links
|
> We do not need 150 Emails from someone that do not master his subject
every time than a problem may occur.
True, the mailgroup do not benefit from that many mail one one simple topic.
Unfortunately that many mails are needed to get you even close to the truth,
since your eyes reamins closed most of the time. My first mail contained the
data needed for the verification, and a correct analysis. So did all the
rest of the mails from me on the same topic.
The mails from you were always pointing in different directions, all the
time missing the problem. Finally you admitted that I was correct. The long
way to that admission was your 150 mails. I have made the below extract from
your answers, and it is interesting to read, and see how your opinions
change. They are interesting from the beginning, since you are contradicting
yourself even in the beginning, but a lot funnier in the end where your need
to defend Omega really brings you out on thin ice. Looking at how your
arguments spin around is quite amusing, and also explains why you never
understand the problems given to you.
By the way, have you reported your "TS does not use LONGS" bug to Omnega
yet?
Below is the gallery of Pierres interesting statements:
plusdm for the test case should be above zero, that is not an error
plusdm for the test case can never be zero, it is incorrect usage of
EL to code it like this
plusdm for the test case will never be zero due to roundings, but
the resulting error will not be bigger than epsilon
the magnitude of the price data precision is a lot higher than the
resulting error
Omega has more than 7 significant digits, this is a false problem
and bad understanding of reality
The pixel size of the screen will not be enough for showing the DMI
error
The difference will probably not bring noticeable differences in the
system summary report
Omega has 7 significant digits, same as C
The comparison is an error, but it is not a part of Tradestation
Your results show you can probably not even count to 7
The resulting difference is far below the three digit precision of
the price data
You will have the same problems using C
The error you reported only appear from the data window, and will
not affect a trading system
Your problem is not a precision problem, read a physics book where
this is the first lesson
If you do not understand the elementary maths error calculus that I
used, please ask someone
At the risk of repeaing myself, I am a french teacher in physics and
chemistry
It seems that you still confuse mathematical calculus with infinite
precision with experimental calculus
My conclusion is that the dumbest part of the Omega List should need
holidays, or some maths holiday course
According to wat I see with the TS2000 DMI code and what has been
said here on error propagation with recursive calculus and price precision,
i cannot see where it could fail
You use the same variables for both calculations is the same code...
This is the problem
The bug has been craated by the "Better DMI", not the Omega DMI
26% I cant believe it!
you decided to add a check condition that is bad designed,dangerous
and worthless(your MIBGreaterEqual function)
you function may turn the comparizon into a false result because you
added an epsilon to it
rewriting all the TS functions is a hint for the dustbin hint
your problem do not fail with the price data and fails with the
decimal directly passed to a variable, where the epsilon error is created.
the roundoff errors do not exists from price data results that
should be equal from different formula
your problem has rather to do with a local error in the price
database than with the code
32 bit precision is kept when you perform raw data price basic + - *
operation
price preciion for calculus done in a row is not an issue util you
override the unsigned LONG precision,
As explaied, the DMI bug cannot exist, because the PlusDM and
MinusDM values have the LONG precision
a calculation derived from prices as it is the case in my example
or the DMI example is not affected by the bug precison,
remove the 200 or so message sent to finally demonstrate that the
bug is only existing in the mind of those who are not confident enough in
the software
There is a problem with the Dmi EL code, but not with the TS
software.
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.
|