|
PureBytes Links
Trading Reference Links
|
God, this is taking some time. You do actually not explain anything to me,
you are just stubbornly confusing people by trying to state things against
the facts provided by the examples of what happens in real life
calculations. What you have written below is totally and fully wrong, it
does not help that you repeat it, it still remains wrong. All my mails so
far has tried to show you that, to help you open your eyes to facts. If you
stopped and listened for just a second, you would realise that you are
totally wrong here. I will now try to open your eyes one more time, through
a step by step reading exercise.
If you look at the example again then you will not see any 7 digit price
data. I hard coded prices. The hard coded data was taken from the price data
I had, but hard coded in the example you can see. Look at the hard coded
data. How many digits do you see? You do not see 7 digits, you do not see 6
digits, you see only 5 digits. Thus, my example is using 5 digits price
data. Before hard coding them and mailing them I used them where they were,
5 digit price data used by Tradestation as price data. Not 7 digits, just 5
digits. Exactly the precision you yourself claim is a reasonable price data
precision. Ok, so let us then get that part over with, no more talk about 7
digit price data please. There is nothing wrong with using 5 digits price
data, and when using 5 digit price data the problems pop up. If you look at
the number of decimals, they are the default number of decimals used by
Tradestation. Thus there is a 5 digit price data precision, with a default
number of decimals. Just like in real life, because the example comes from
real life.
Now, if EL could use 7 digits, a mathematical operation of two variables
using 5 digits both having the same magnitude would stay stable for those
digits. The example proves this is not the case. The example proves (like
Raj mentioned about globalserver as well) that Tradestation can not handle a
precision of 7 digits. Neither can it handle a precision of 6 digits. This
was proven in another discussion in code list a month ago, using another
example, totally different, but proving the same thing. You can not keep
closing your eyes to this no matter how much extra benefits you get from
Omega for defending them. Single precision operations can handle 6 digits
precision. For example C++ can handle 6 significant digits in single
precision. Single precision operations can correctly calculate the example
given. Single digit precision is more accurate than Tradestation precision
in maths. Tradestation math precision is thus not above 7 digits as you
state. Neither is it 7 digits. Actually, it is not even 6 digits. This is
proven by this example, and it has been proven by previous examples. Please
quit claiming EL precision is 7 digits, you might have to say it when
selling to people, but here in this list, let us stick to facts. Fact is,
Tradestation does worse than single precision, Tradestation does not have 6
digits precision in calculations.
Now, let us revisit the original exampel code again. You state that the
error magnitude is far below the precision of the raw data. Let us go back
to the resulting error. It is 0.107 in the given example, an example which I
did not code, it is coded by Omega, which is the PlusDMI, which is trying to
calculate the DMI as described in a number of books. The error introduced in
that calculation is 0.107. The price data is 5 digits, for exampel 10.280.
The decimal precision of that data is 0.001. This is the same as the default
precision in Tradestation for converting price data to integers. So the
magnitude of precision in price data is 0.001, resulting in a calculation
error of 0.107. 0.107 is above 0.001. The error is thus above the precision
of raw data. The precision of price data can be multiplied by 10 and still
remain smaller than the resulting error. The precision of price data can be
multiplied by 100 and still remain smaller then the resulting error. Thus,
the resulting error is way above the precision, it is a magnitude above the
price data decimal precision.
Then finally, it is not my system. It is the DMI calculation. It is not me
who wrote the DMI calculation, it was written by Omega. The DMI is not
invented by Omega. The DMI is described in many books not printed by Omega.
The error in the DMI calcualtion is a magnitude above the price decimal
precision. If you want to claim that DMI is an example of bad understanding
of reality of computerized technical analysis calculus, do that to Welles
Wilder or his followers, but be prepared to stand with no good arguments
there as well.
Since DMI is write protected, Omega need to correct the code, we can not do
it. Since the exmaple uses 5 digits price values, we should be able to
expect calculations based on those values to be accurate. They would be if
single precision was used. They would be if 6 digits precision were
available in Tradestation. Omega ought to fix this. Not being able to
operate on 5 digit values and keeping the precision is a big wekness in a
calculation engine like Tradestation.
> -----Original Message-----
> From: pierre.orphelin [mailto:pierre.orphelin@xxxxxxxxxxxxxx]
> Sent: den 17 juli 2001 13:59
> To: Eskimo Omega List
> Subject: RE: Special thread for Pierre Orphelin, the man who
> do not want to see
>
>
> What I explain to you is that the magnitude order of the
> error is far below of the magnitude of precision of raw data.
> If your system is so sensitive to epsilon rounding effect,
> yous system will ot be stable over unseen data, where the
> precision of the considered data is far below the epsilon
> value. Roughly, price data precision is no more than 5 digits
> and EL precision is above 7 digits, what is enough for most
> technical analysis applications. If you consider that the
> precision in price data is weakened by the market moise
> overlaid, that has by definition, less precision than the
> raw price, your internal precision consideration are far
> below any mathematically correct meaning derived from the
> meaningful component of the raw price.
>
> Typically, it's a false probleme and a bad understanding of
> the reality of cmputerized technical analysis calculus.
>
> PO
>
> > -----Message d'origine-----
> > De : Bengtsson, Mats [mailto:mats.bengtsson@xxxxxxxx] Envoyé : mardi>
> 17 juillet 2001 13:07 À : pierre.orphelin@xxxxxxxxxxxxxx; Eskimo
> > Omega List Objet : Special thread for Pierre Orphelin, the man who
> > do
> not want to
> > see
> >
> >
> > Fantastic! You will never see, not even admit to what you
> admitted to
> > in previous mails, until someone from Omega stands up and
> says "it is
> > allowed to admit it as a bug". Then you will claim that it comes in
> > SP7... :-)
> >
> > There is no problem with the raw data. The raw data is fine and
> > correct. Raw data actually are the prices as they occurred, and raw
> > data are not wrong just because Tradestation happens to get wrong
> > figures from them. There are
>
>
> >
>
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.
|