|
PureBytes Links
Trading Reference Links
|
Seems to me yr. trading disk space, I/O and performance for memory. Me I
prefer maximum bang. - I find Metastock my machine I/O bound when updating.
Please don't make it worse. Ultra SCSI disk space is still expensive and
certainly not as fast as Rambus memory, or at least it isn't on my machine.
----- Original Message -----
From: "Lionel Issen" <lissen@xxxxxxxxx>
To: <metastock@xxxxxxxxxxxxx>
Sent: Friday, May 04, 2001 4:48 PM
Subject: Re: Double Precision (was RE: Current Day!)
> One way to reduce storage requirements a little would be to use a database
> system. All the ticker data would be stored in a single data base. The
user
> could specify groups of tickers that could be called up in one or more
> folders, the indicators for the tickers would be kept in each separate
> folder, the price data would stay in the database. This is the sort of
> system that is used in Investors FastTrack, TC2000, and Quotes Plus.
> Lionel Issen
> lissen@xxxxxxxxx
> ----- Original Message -----
> From: "Charles Kaucher" <steinbr@xxxxxxxxxxxx>
> To: <metastock@xxxxxxxxxxxxx>
> Sent: Friday, May 04, 2001 8:01 AM
> Subject: Double Precision (was RE: Current Day!)
>
>
> > Some thoughts.
> >
> > To make a trade in almost all cases do not require double precision.
> >
> > To make a calculation probably does require Double Precision more times
> > than not.
> >
> > Even if it were just for built in functions, calculated values performed
> in
> > Double and their bar results shown as Single would probably satisfy most
> > users. Certain static values for things such as Exponential MA and
> > recursive MAs may need to be stored as doubles. This is not new
> technology
> > here -- arithmetical accuracy has been addressed before.
> >
> > Data probably doesnot need to be stored as Double and there are ways to
> > reduce the size of data storage.
> >
> > So a lot can be accomplished without doing a global search an replace
for
> > every float to be replaced with double and would hardly double you
memory
> > requirements to levels you suggest.
> >
> >
> >
> >
> > At 03:41 PM 5/3/2001 -0600, you wrote:
> > >All:
> > >
> > >I do not want this issue to blow up again. To revisit what was stated
> > >several months ago:
> > >
> > >1. MetaStock currently uses single precision floating point numbers.
> This
> > >guarantees only 7 digits of ultimate precision on all numbers. Double
> > >precision numbers will extend this to 15 digits (but still not 100%
> > >accurate) at a cost of double the memory requirements.
> > >
> > >2. We are considering a change to double precision in the future, but I
> am
> > >not able to give a specific time frame for the availability of this
> > >functionality.
> > >
> > >3. In the meantime, we are willing to help customers understand this
> issue
> > >and to help them achieve the accuracy that they desire.
> > >
> > >FWIW: Assuming the bars you load contain open, high, low, close and
> volume,
> > >that is 5 values per data point. If each value uses 4 bytes of storage
> that
> > >equates to 20 bytes per data point. Multiply 20 bytes per data point
by
> > >50,000 and you get a total requirement of 1,000,000 or 1 million bytes
of
> > >storage required simply to hold the data for the price bars. If you
> throw
> > >in two indicators that produce one new data field each, that adds an
> > >additional 8 bytes per data point or an additional 400,000 bytes for
that
> > >single chart. So, for the single precision version it requires 1.4
> million
> > >bytes for that one chart. If you go to a double precision number for
> data
> > >storage (8 bytes) the requirement becomes 2.8 million bytes per chart.
> When
> > >you throw the additional storage required to QUICKLY give user feedback
> for
> > >drag and drop operations, the memory requirements balloon rapidly.
This
> > >does not include the code required just to provide the functionality of
> > >MetaStock itself.
> > >
> > >I am not trying to trivialize your need for improved floating point
> > >accuracy. Please do not trivialize the memory requirements of a
program
> > >with the capabilities of MetaStock. The fact remains that MetaStock
> > >currently uses single precision numbers and we are considering a future
> > >change to double precision. Arguing over the merits of the current
> > >implementation will not solve the problem for anyone. In the meantime,
> > >there are ways to work through most precision problems presented with
> single
> > >precision floating point math.
> > >
> > >Ken Hunt
> > >Programming Manager
> > >Equis International
> > >
> > >
> > <SNIP>
>
>
>
|