|
PureBytes Links
Trading Reference Links
|
Cool. I considered something along these lines but I don't think that a
command within something like the formula language would do what we need
without rebuilding the math core to accept double precision anyway. Then,
how would you as a programmer tell the program to store single precision
information from the double precision? Then, what would you do if you did a
further calculation with single and double precision data? Pop up a warning
message? The biggest concern I have had is: Without actually being able to
see every number that is used within a calculation to arrive at a number for
a plot or indicator, how do I know which one of those numbers will exceed
the single precision limit and be rounded? Take a close look at some
indicators that deal with large numbers such as volume. Any computation
(Indicators, System Tests, Explorations, & etc.) which through
multiplication or power increases a number over the single precision limit
will introduce a rounding error before further operations such as divisions
or roots which would reduce the apparent magnitude of the number.
However, you are on to what could be the basis of a fix. Excel has the
option of giving you the decision (Tools/Options/Calculation) of the
precision you prefer.
-Corey
----- Original Message -----
From: "Steve Brann" <steveb@xxxxxxxxxxx>
To: <metastock@xxxxxxxxxxxxx>
Sent: Friday, May 04, 2001 7:26 AM
Subject: RE: Double Precision (was RE: Current Day!)
> 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>
> >
> >
>
>
|