|
PureBytes Links
Trading Reference Links
|
Do not think people will be interested in a new long series of mails on how
this mail series started, but some of them might be interested in evidence
of your lies (or "flawing the truth" if you prefer that). Let us start with
a semantic discussion first and get to the lying 6 lines later:
> 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.
So it is not a bug in your eyes, it is a flaw, or like Gamble expresses it
"a limitation". Delivers 30% difference in single bars, adjusts your signals
5 bars forth or back, does not follow the official specification, is write
protected, but is not a bug. Does it have to be delivered without source
code so we can not see where their "flaw" occurs to call it a bug? This
semantic part always makes me curious.
Let us then look at your lying a little more careful. I have taken a part of
the mail I am now replying to, and with your comment after that part:
> > var: minusdm1(0);
> > (snip)
> > It should plot a straight line at zero, but does not.
> >
> > --- Mats ---
And in that mail, the below text is the comment on the contents of my mail:
> No data example was given to verify, no analysis of the problem given.
Now, let us then look at what you cut away were you indicate "(snip)",
before telling everyone there was no data included in may mail:
>If 10.387 - 10.280 < 0 Then
> PlusDM = 0
>Else
> PlusDM = 10.387 - 10.280;
>If 10.280 - 10.173 < 0 Then
> MinusDM = 0
>Else
> MinusDM = 10.280 - 10.173;
>If MinusDM >= PlusDM Then
> PlusDM = 0;
>plot1 (plusdm);
After that followes the code in DMIPlus to show what those data values
correlated to (high,high[1],low[1],low. I would absolutely call that data,
anyone can see that it is data. Data followed by parts of the Omega DMI code
to show where that data were used in the indicator. Which of course is the
reason you cut it away, else your statement "no data" would look a little
ridicolous. :-)
If you had inserted those data into any symbol and opened your eyes, than
the thread would have been much shorter, with you next mail saying "this is
not a bug it is a flaw", and the debate could have been about the word flaw.
:-)
I also preceded the data with a clear indication that it was a programming
error by Omega in how these values where handled (you might remember your
previous mail where you stated that this is integer data and it should be
calculated with the precision of long data, about 30 lines in the mail I
think?). Since we both agree on this as well, I think it is your turn to
report the error to Omega, that by some reason and in spite of your 1.5 page
mail, they do not treat their integers as integers when they do comparison
on them. My analysis was as below (I know it makes you red to read all those
lines saying not so nice things about Omega, but it is still an analysis):
>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.
I am tired of this thread, I have already given an example of the printout
bug in one mail. It is easy to give example on the problem with price
conversion to integers and I have already done that as well. The debate if
single precision delivers less precision than double precision is quite
unneccessary, there is no doubt. You could debate in how many cases you need
it, but you have yourself written now and then something like "use dll:s to
get to doubles where needed".
And then, since you remarked at my tone in the mail, you "mistakenly" missed
the beginning of that mail, you included the headlines, skipped the
beginning but never mentioned "(snip)" (but I forgive you):
>I have been looking at this for a day now. If there is a fault in my logic,
I can not find it without help.
>At the same time, if I am right there is a tremendous error in Tradestation
causing a lot of things to go
>wrong, really going wrong that is a bigger error than I would ever have
thought should have gone through
>unnoticed. Well, to decide which it is, I send you an indicator that
illustrates a math error. Some of you
>will recognise it as part of the code from the dmiplus logic from the built
in library. This explains the bad
>formatting. Did not want to change more than necessary. Please tell me if I
am missing something here, this
>has made me totally lose confidence in Tradestation indicators.
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.
|