|
PureBytes Links
Trading Reference Links
|
Pierre's business rely on TradeStation. He is basically a TradeStation
business partner. He is never going to admit TS has any problems because it
is against the interests of his business. If Pierre was an average TS users
he would not defend TS the way he does.
Robert Holt.
----- Original Message -----
From: "Bengtsson, Mats" <mats.bengtsson@xxxxxxxx>
To: <pierre.orphelin@xxxxxxxxxxxxxx>; <omega-list@xxxxxxxxxx>
Sent: Friday, August 03, 2001 9:48 AM
Subject: RE: BEWARE: Pierre thinks it is a frog trap ( but it is a DMI bug)
> Pierre, once again you are endangering to fool your fellow participants in
> this list. That is sad, we know you are trying to be worthy of Omega, but
> give them a call, I bet they will tell you it is allowed to give this
cause
> up in this case.
>
> I also see you got your marketing material in front of you. You delivered
a
> nice long theoretical description of how it was supposed to be. But you
are
> confused, we should be talking about how it is right now, maybe it will be
> like your marketing material in "TS Enterprise sp14", who knows? Anyway,
you
> are throwing out so many theories. You have sent a number of "this is how
it
> is" and then you have been wrong all the time, which always results in new
> theories without any connection to reality (no miscalculation in DMI,
better
> than 7 digits precision, 7 digits precision, 6 digits precision,
> mibgreaterequal being the reson, data problems being the reason, reuse of
> variables being the reason, translation from integers being the
reason,...).
> You keep on sending out new versions of how it is, without bothering to
test
> anything. Instead insert the data you got from me yesterday (or the ones a
> week earlier, or the ones a week earlier...) into two consecutive dates in
> any symbol, run the testfunction, run the original plusdm function, see
for
> yourself, test your own balderdash before delivering them as truths..
>
> Remember, there is still an original DMI function in Tradestation, not
> written by me. That DMI function still produces the error for this kind of
> data, no matter what theory you want to give to people. Omegas code says
"if
> minusdm>=plusdm ..." I did not write their code, if it does not use their
> longs it is their fault not mine. I do not run Tradestation with one
> handcoded version of DMI for every date in every symbol like your theroy
> seems to build on. Skip theory since you can not get theory to behave as
> Tradestation, we all (except you) know Tradestation does not behave like
the
> marketing material. Do not give marketing info, test things instead.
>
> Besides, changing omegas code to "if (low[1]-low[0]>=high[0]-high[1]) ..."
> still gives the same incorrect result, so probably the easy language
> compiler has not read all your mails. When I come to think of it, that
must
> mean you just submitted a new bug report, according to you it should work.
> Remember to send that one in to Omega. :-)
>
> Please try to realise: I do not device frog traps, I just printed two
dates,
> which is data from the real world. They are causing a bug to become
apparent
> in the real world DMI function delivered in Tradestation. Nothing is
> constructed from my side (which differs from your funny code parts
> "2*h+l+o-o-h+h[1]"). Test reality instead of theory, use the data in a
> symbol.
>
> The trap is your own head, people walk into a lot of things when they
> persist in walking around with their eyes closed.
> > >
> > > value1=6.800-6.750;
> > > value2=6.600-6.550;
> > > if value2>=value1 then
> > > print ("value2>value1")
> > > else
> > > print ("Pierre is struggling to not admit the bug in the Omega DMI
> function");
>
> > -----Original Message-----
> > From: pierre.orphelin [mailto:pierre.orphelin@xxxxxxxxxxxxxx]
> > Sent: den 3 augusti 2001 02:07
> > To: omega-list@xxxxxxxxxx
> > Subject: BEWARE: that DMI is correct
> >
> >
> >
> > A little bit more technical explanation to explain what
> > confused Mats when devising the latest TS frog trap:
> >
> > TradeStation treats prices as signed LONG (32 bits
> > precision), but in fact LPLONG pointer, a Pricescale (
> > probably a WORD or INT),and an offset (INT, 16 bits signed
> > integer) from currentbar. This should be familiar to TS DLL
> > developers.
> >
> > When TS performs such calculus value1=h+l+h[1], it only use
> > LONG before doing anything that will put the result into a
> > FLOAT ( variable), uses the offset for H[1] that is still a
> > pointer to a LONG, then is Pricescale adjusted. This is why
> > the 32 bit precision is kept when you perform raw data price
> > basic + - * operation. The FLOAT issue precision should only
> > occur when the result has been stored into a variable or an
> > array element.
> >
> > When writing
> > value1=6.800-6.750; the value1 precision is the FLOAT
> > precision already discussed. Here you can see the 7th digit
> > error ' 5.000001 for example
> >
> >
> > IT will NOT give the same results than:
> > value1= h-h[1] althought h=6.800 and h[1]= 6.750 in the
> > database. There you will read : 5.000000
> >
> > This means that the price preciion for calculus done in a row
> > is not an issue util you override the unsigned LONG
> > precision, until the result is written into a float variable.
> > The precision issue occurs once you REUSE the variable, what
> > is not the case for the DMIplus part of the code.
> >
> >
>
>
> 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.
>
>
|