|
PureBytes Links
Trading Reference Links
|
If I could define a component as double precision say;
FullDate:=DoublePrecision(dayofmonth()+(month()*100)+(year()*10000));
Then it would address those "rare" occasions that DP is required. MStock
could limit DP's to say 20 which are user defined as above thereby limiting
any huge increase in memory requirements. Does this make sense or is it
plain IT stupid?
Steve
> -----Original Message-----
> From: owner-metastock@xxxxxxxxxxxxx
> [mailto:owner-metastock@xxxxxxxxxxxxx]On Behalf Of Charles Kaucher
> Sent: 04 May 2001 14:02
> To: metastock@xxxxxxxxxxxxx
> 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>
>
>
|