|
PureBytes Links
Trading Reference Links
|
>From: Thomas Alexander <alexander_enterprises@xxxxxxxxx>
>To: Robert <robert_h@xxxxxxx>, Eskimo Omega List <omega-list@xxxxxxxxxx>
>Subject: Re: BEWARE: Pierre thinks it is a frog trap ( but it is a DMI
>bug)
>Date: Fri, 3 Aug 2001 10:02:13 -0700 (PDT)
>
>I often wonder how it feels to be Pierre on this list?
I sure don't know, but i'm glad he's here. He's the Yin to
our Yang. He's a wall to bounce off of.
>Did you know that a school of Amazon pirhanna can strip a
>full-grown bull clean of all it's flesh and muscle meat in
>less than two minutes? Pierre, you must certainly have the
>cajones of el torro to wade into this river (:-o)
>
>PS. I'm not Pierre, but if someone on this list started
>referring to me as a "Kraut" and my postings as
>"Sauerkraut" I might feel a bit tweaked. Pierre, just
>curious, what is one of the many derogative European terms
>for "American?"
My travels have been south and west, so I've been called a
"Gringo" and a "Haoli." I am, we are, who cares? I
**try** to stay above at all and you're right: we should. Still
and all sometimes a little emotion, a little edge, gets the
juices flowing and motivates those ideas sometimes.
For sure hate is a bad thing, but if you had a soap opera where
everyone was happily married no one would watch. To some
extent the same is true here. Do you think this thread would
have as much value if everyone didn't want to prove PO wrong?
Bill "I Swim With The Sharks, and Then I Swim With The Sharks" Wynne
** Haoli means white person or tourist/non-native in Hawaiian
PS: Frogs like bugs.
PPS: PO: I'm thinking of coming to France to surf someday, any
suggestions?
>
>Thomas "I Don't Polka" Alexander
>
>
>Robert wrote:
>
>Pierre's business rely on TradeStation. He is basically a
>TradeStationbusiness partner. He is never going to admit TS
>has any problems because itis against the interests of his
>business. If Pierre was an average TS usershe would not
>defend TS the way he does.Robert Holt.----- Original
>Message -----From: "Bengtsson, Mats" To: ; Sent: Friday,
>August 03, 2001 9:48 AMSubject: 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 thiscause> up in this
>case.>> I also see you got your marketing material in front
>of you. You delivereda> nice long theoretical description
>of how it was supposed to be. But youare> 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 howit> 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
>thereason,...).> You keep on sending out new versions of
>how it is, without bothering totest> 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, seefor> 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 likethe> 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, thatmust> 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 twodates,> which is data
>from the real world. They are causing a bug to
>becomeapparent> 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
>confidentialand is the property of the Cap Gemini Ernst &
>Young Group. It is intendedonly for the person to whom it
>is addressed. If you are not the intendedrecipient, you are
>not authorized to read, print, retain, copy,
>disseminate,distribute, or use this message or any part
>thereof. If you receive thismessage in error, please notify
>the sender immediately and delete all copiesof this message.>>
>
|