|
PureBytes Links
Trading Reference Links
|
Hi Ken,
no bashing intended. <g> Merely trying to point out that a double-precision
version of Omega products would cause some Omega users (euphemistically
referred to as programmers) to be in for an occasional surprise: they might
find some of their trading systems report totally different results.
I remember this is what happened many years ago when Excel first went from
single to double precision.
As for the Omega programmers (meaning Bill's employees who create and
maintain TS code), changing TS to double precision would probably have to do
mostly with changing data formats rather than any math
libraries (though this cannot be totally excluded, either).
Best,
Michael Suesserott
----- Original Message -----
From: "TradeMaker" <TradeMaker@xxxxxxxxxxxxxxx>
To: "MichaelSuesserott" <MikeSuesserott@xxxxxxxxxxx>; "Gary Fritz"
<fritz@xxxxxxxx>; <omega-list@xxxxxxxxxx>
Sent: Sunday, March 21, 2004 20:07
Subject: RE: Need fixed StandardError function
> Boy, programmer-bashing sure is fun, isn't it?
>
> -Ken
>
> -----Original Message-----
> From: MichaelSuesserott [mailto:MikeSuesserott@xxxxxxxxxxx]
> Sent: Sunday, March 21, 2004 2:00 PM
> To: Gary Fritz; omega-list@xxxxxxxxxx
> Subject: Re: Need fixed StandardError function
>
>
> Hi Gary,
>
> if Omega products are programmed in standard C or C++, a rewrite of math
> libraries may not even be necessary. Very likely, a simple recompilation
> with the correct compiler switch set would be sufficient.
>
> Most systems should be stable enough so that they would not react much to
> this change of precision. But programmers who love to depend on a lot of
> number crunching may be in for a surprise. It's fun to think how such
system
> developers would be looking with some desperation at the unexpected
changes
> in their system statistics.
>
> Best regards,
>
> Michael Suesserott
>
>
> ----- Original Message -----
> From: "Gary Fritz" <fritz@xxxxxxxx>
> To: <omega-list@xxxxxxxxxx>
> Sent: Sunday, March 21, 2004 19:34
> Subject: Re: Need fixed StandardError function
>
>
> > > > I always wondered why the calculations are single-precision.
> > > > That always seemed stupid to me.
> > > >Speed.
> > >
> > > No, not speed. Floating point math these days is almost always
> > > handled by a math coprocessor (nearly all computers have had them
> > > since the early 1990s) and math coprocessors are designed to run
> > > optimally for double-precision math.
> >
> > But remember that Easy Language has its roots in the early 90's.
> > (Or was it late 80's? I don't remember.) Math coprocs weren't
> > as universal then, especially for some of the "legacy" PC's then
> > in use. Memory was also more valuable, and the EL designers may
> > have decided to trade off numerical precision for speed and space
> > savings. It seems pretty clear nobody at TRAD understands
> > numerical precision anyway.
> >
> > I understand double-precision is an option in TS7. That's a big
> > improvement. Now if they just had somebody competent rewrite
> > their math libraries...
> >
> > > >plus most programmers are mathematically incompetent.
> > >
> > > Well, there's that... I see a number of functions in EL that look
> > > like they were written by following a classical math textbook rather
> > > than a book on efficient computer algorithms.
> >
> > It's not efficient, or even correct. The code you see in many TS
> > library functions would get you flunked out of any numerical-
> > methods class. It produces patently incorrect results because it
> > ignores the critical issues of numerical precision in computer
> > math. And obviously nobody at TRAD ever bothered to check their
> > results against a reliable reference, like Excel.
> >
> > Gary
> >
> >
>
>
>
>
>
|