|
PureBytes Links
Trading Reference Links
|
False problem again.
A 10^-7 precision problem than should affect the results of a trading system
has nothing to do with the raw materials quality ( precision) from which the
system is derived ( ie price data).
Speaking of such rounding erors when performing technical analysis
calculus is a serious misunderstanding of the basics of relative errors as
they are evaluated in dummy sciences like physics, for example.
Unless you believe that the price data precision is higher than the
magnitude of the error.
But here again, I think that you are not currently living in the real
world...
Sincerely,
Pierre Orphelin
www.sirtrade.com
TradeStation Technologies representative in France
> -----Message d'origine-----
> De : Bengtsson, Mats [mailto:mats.bengtsson@xxxxxxxx]
> Envoyé : mardi 17 juillet 2001 10:11
> À : pierre.orphelin@xxxxxxxxxxxxxx; Eskimo Omega List
> Objet : RE: Language problems causes bugs not to be understood as the
> bugs they are
>
>
> So, we got to the point where we almost communicated a little. I am
> greateful for your answer, you have really spent time on the question. But
> you have not yet opened your mind and allowed yourself neither to
> understand
> nor think.
>
> You started with the statement that this is a mathematical reality, not
> something that has to do with Tradestation. Now you are actually
> back to the
> mathematics beeing okey, and the Tradestation being the problem. That is
> good, one step on the way.
>
> But now you claim the problem to be the same in other implementations than
> Tradestation, the problem would exist also in double precision.
> This is not
> true. In fact, the problem does not exist even in single precision. The
> Tradestation mathematical engine cuases this problem due to a very sloppy
> math engine which does not even keep the accuracy of single
> precision. This
> is the real problem, the accuracy in Tradestation is worse tyhan single
> precision.
>
> Now finally your conclusion is that the problem will only affect
> the results
> with the epsilon effect. This is not true either. The code was taken from
> the DMI calculation, where the resulting values are based on a running
> accumulation, which in turn should not accumulate unless the Plus side is
> greater than the minus side. But the accumulation occurs, even though the
> plus side is not greater then the minus side, due to this bug
> which is a bug
> a lot bigger than even single precision. If the error produced had been
> epsilon, i would not have found it. The error produced is the resul of the
> whole bar being added to an accumulator when it should not be.
>
> > -----Original Message-----
> > From: pierre.orphelin [mailto:pierre.orphelin@xxxxxxxxxxxxxx]
> > Sent: den 17 juli 2001 02:28
> > To: Eskimo Omega List
> > Subject: RE: Language problems causes bugs not to be
> > understood as the bugs they are
> >
> >
> >
> >
> > > -----Message d'origine-----
> > > De : Bengtsson, Mats [mailto:mats.bengtsson@xxxxxxxx]
> > > Envoyé : mardi 17 juillet 2001 01:15
> > > À : pierre.orphelin@xxxxxxxxxxxxxx; Eskimo Omega List
> > > Objet : RE: Language problems causes bugs not to be
> > understood as the
> > > bugs they are
> > >
> > >
> > > Ok, so you tell me that it should never plot a zero.
> > Interesting. This
> > > based on simple mathematics. Even more interesting.
> >
> > I do not want to spend the night with this.
> > Here is your code with comments ( and it produces an
> > horizontal line here)
> >
> >
> > > > > > > var: plusdm(0);
> > > > > > > var: minusdm(0);
> > > > > > > var: plusdm1(0);
> > > > > > > var: minusdm1(0);
> > > > > > > If 10.387 - 10.280 < 0 Then
> > > > > > > PlusDM = 0
> >
> > So PlusDm will never be set to 0 (10.387 >10.280) 10.387 -
> > 10.280 produces a positive number
> >
> > > > > > > Else
> >
> > Yes, else...
> >
> > > > > > > PlusDM = 10.387 - 10.280;
> >
> > PlusDM will always (Else) produce : 10.387 - 10.280 =0.107,
> > means an horizontal line.
> >
> > > > > > > If 10.280 - 10.173 < 0 Then
> > > > > > > MinusDM = 0
> >
> > Minus DM will never be set to 0
> >
> > > > > > > Else
> > > > > > > MinusDM = 10.280 - 10.173;
> >
> > But set to 0.107
> >
> > > > > > > If MinusDM >= PlusDM Then
> > > > > > > PlusDM = 0;
> >
> > Yes, it shoud be set to 0 if the rounding errors that is
> > always the same over bars produced a stricly 0 value. But
> > even with double precision, this error wil remains and the
> > result will be 0 if the epsilon difference is below 0, 0.107
> > in the other case. What you see here is computer
> > approximation on basic operation, and as your opration
> > remains the same over bars, the same epsilon value is
> > produced. This will not affect in any case the precision of
> > the calculus more than the epsilon effect ( single or double
> > precision)
> >
> > Good night.
> >
> > PO
> >
> > > > > > > plot1 (plusdm);
> > > > > >
> >
> > >
> >
>
>
> 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.
|