|
PureBytes Links
Trading Reference Links
|
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.
|