|
PureBytes Links
Trading Reference Links
|
My 2 cents:-
1. If software is well written changing types of one or more fields and/or
internal variables from single float precision to double should be a simple
exercise.
2. Equis could always compile and ship 2 binaries for the MS program - one
for single precision maths, the other for double. The users could then
choose which to install.
3. IMO additional memory or processing overhead concerns just aren't an
issue. No serious TA trader is going to be concerned even if they do have to
buy a bit more memory - the cost is insignificant in trading terms.
----- Original Message -----
From: "Charles Kaucher" <steinbr@xxxxxxxxxxxx>
To: <metastock@xxxxxxxxxxxxx>
Sent: Friday, May 04, 2001 2:01 PM
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>
|