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