|
PureBytes Links
Trading Reference Links
|
Totally agree.....that's why the DLL interface is there......
and I agree that doubles will utilize the floating point processor of the
Intel CPU...so the CPU hit won't be much at all.
However, the big hit is the memory storage of all of the series-based
variables......
that could be significant....and cause much paging and swapping at the
application-level.
> -----Original Message-----
> From: J. Rodney Grisham [mailto:Rod.Grisham@xxxxxxxxxxxxxxxxxxxxx]
> Sent: Monday, March 20, 2000 7:04 PM
> To: Bob Fulks
> Cc: M. Simms; omega-list@xxxxxxxxxx
> Subject: Re: Warning about accuracy of Array functions
> inTS2000i-CPU/memory hits
>
>
> Bob Fulks wrote:
> >
> > At 12:00 PM -0500 3/20/00, M. Simms wrote:
> >
> > >Totally agree that computers should be infallible and software should
> > >be "perfect".... but when huge performance trade-offs exist as would
> > >be the case of double floating point, I'd rather be fast rather than
> > >"perfect".
> >
> > I am glad you are not managing my money...
> >
> > >You wouldn't want to experience the combination of BOTH a CPU "hit"
> > >and a "memory" hit if Omega goes immediately to doubles......everyone
> > >would need 512k RAM and the new gigahertz CPUs.
> >
> > And they could pay for it with what they would lose in a few
> minutes on inaccurate calculations..
> >
> > >Also, I can't understand why everyone is trading today based on data
> > >20,000 bars ago anyway ? Wow - isn't that stuff ancient history ?
> >
> > The TradeStation function is coded to calculate the accurate
> value on the first bar and just adds and subtracts changes since
> then. The value 20,000 bars ago was correct. But along the way,
> the errors accumulate.
> >
> > Bob Fulks
>
> Bob, may as well give up. People who do not understand error
> analysis, just don't get it.
>
> I've posted several messages on this subject too. Here's part of
> one with some reference material for the uninitiated to read. It
> is not exactly appropos for the exact subject, but close enough.
>
>
> Scaling does not make any difference, unless you are approaching
> overflow or underflow conditions (not likely). You need to get
> a basic understanding of numerical error analysis. A place to
> start which is very thorough and which should be available in
> any university library or technical section of a public library is:
> The Algebraic Eigenvalue Problem
> J. H. Wilkinson
> Oxford University Press
>
> The version I have is 1969, but the basics do not change. You
> don't need to be intimidated by the whole book, and don't think
> that the title makes it inapplicable to rounding analysis. Just
> read the first 3 chapters, particularly Chapter 3 Error Analysis.
>
> The only thing not covered in this book which is needed for
> analyzing computations on Intel x86 processors is that the
> floating point registers are 80 bits long, if you can keep
> the computations in the floating point unit.
>
> EL is known to use single precision. What is not certain to
> anyone (that I know) outside of OR is whether EL makes any
> significant use of the floating point unit. I suspect it
> does not. Thus as you read Wilkinson's book, assume you
> have 32 bits of floating point precision. You will quickly
> realize how limiting this can be.
>
> The solution - do all significant computations in a DLL that can
> use double precision and which will take maximum advantage of
> the 80 bit registers in Intel cpu's.
>
> Rod
>
|