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

Special thread for Pierre Orphelin, the man who do not want to see



PureBytes Links

Trading Reference Links

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
a number of defined indicators out there. In one of them is PlusDM which
accumulates only if the difference between highs is higher than difference
between lows. The bug causes this not to happen as specified. This bug
occurs in a part of the Omega code that calculates DMI.

I have shown that their code calculates DMI incorrectly due to bugs in
Tradestation. It is their code that comes up with the wrong results. And not
results that are wrong by 10^-7, but results that are wrong by the magnitude
of differences between current and previous highs, caused by these small
errors. To express it so even you can not avoid thinking about it: The error
of 10^-7 affects the trigger value with dollars. 

By your own statements, they should never write code like that. Thus they
should correct it. By my statements such errors occur due to bugs in the
math part internal to Tradestation. Thus they should correct it to at least
follow single precision accuracy. A tool specially made for calculating
indicators on thousands of bars of data that does not even keep single
precision accuracy.

I guess your answer is a typical Pierre: "I have no more good arguments and
realise I am wrong. Thus I will no longer discuss the case at hand, I will
from now on deviate to discussions about other matters in sweeping terms". 

Please, instead of spending your time on your believes that I do not live in
the real world, let us cooperate together to report the bugs that exist and
get them out of Tradestation. That is beneficial for all of us. Even for you
as a reseller, because the product might live longer. I am sorry if it hurts
when somebody says there is a fault in Tradestation. But the fault does not
go away if we ignore it and discusses other subjects. The fault goes away
only if we get Omega to correct it. Probably they would correct it faster if
their resellers thought it was important to get a bug free product, or at
least a product with fewer and fewer bugs as the old bugs are found.

> -----Original Message-----
> From: pierre.orphelin [mailto:pierre.orphelin@xxxxxxxxxxxxxx]
> Sent: den 17 juli 2001 11:51
> To: Eskimo Omega List
> Subject: RE: Language problems causes bugs not to be
> understood as the bugs they are
> 
> 
> 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.
>