|
PureBytes Links
Trading Reference Links
|
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
-----Original Message-----
From: Allan Havemose [mailto:havemose@xxxxxxxxx]
Sent: Thursday, May 03, 2001 2:10 PM
To: metastock@xxxxxxxxxxxxx
Subject: RE: Current Day!
The memory argument is getting a bit dated:
If you have 50000 bars for a security and load it all, it requires 100k
with single precision and 200k with double precision.
I'd trade precision for 100kb of RAM anytime! Even with 10 charts open,
we're only talking about 1 MB.
Secondly, floating point calculations are generally faster in double
precision than single precision.
Allan
--- PD Manager <pdmanager@xxxxxxxxxxxxxxxxx> wrote:
> At the risk of opening this can of worms again: you are correct in
> your
> assumption. All numbers in MetaStock are stored as single-precision
> floating point numbers. With this type of floating point
> representation,
> the computer only guarantees 7 digits of precision. When you have a
> number
> that exceeds this number of digits, any digits beyond the seventh are
> not
> guaranteed to be accurate. Any numbers that contain more digits than
> 7 are
> only approximations.
>
> To restate from past discussions on the subject: In the future, we
> could
> move to double precision numbers to get 15 digits of precision (any
> digits
> beyond the 15th would be inaccurate), but this would more than double
> the
> memory requirements of the program. The additional memory
> requirements of
> this approach is why the decision to make this change has not been
> made up
> to this point.
>
> Ken Hunt
> Programming Manager
> Equis International
>
>
> -----Original Message-----
> From: John R [mailto:jrdrp@xxxxxxxxxxxxxxxx]
> Sent: Wednesday, May 02, 2001 3:52 PM
> To: metastock@xxxxxxxxxxxxx
> Subject: Re: Current Day!
>
>
> I would guess this problem is caused by the underlying floating point
> representation MS probably uses for numeric variables. i.e. losing
> accuracy
> at the extreme limits of range.
>
> Instead of using full century why not try using just 2 digits i.e.
> 00, 01,
> 99. Or if year collating order is reqd. 3 digits i.e. 098 (for 1998)
> 099
> (for 1999) 100 (for 2000) 101 (for 2001) etc.
>
> Haven't checked any of this!
>
> John
>
>
> ----- Original Message -----
> From: "C.S." <csaxe@xxxxxxxxxxx>
> To: <metastock@xxxxxxxxxxxxx>
> Sent: Wednesday, May 02, 2001 8:38 PM
> Subject: Re: Current Day!
>
>
> I tried the equation backwards to see if DDMMYYYY would work.
>
> DOM:=DayOfMonth();
> MON:=Month();
> YR:=Year();
> YR+(MON*10000)+(DOM*1000000)
>
> It works for the first day but not for the days at the end of the
> month.
> for 4/30/2001 I get 30042000 and not 30042001.
>
> -Corey
> ----- Original Message -----
> From: Steve Brann
> To: metastock@xxxxxxxxxxxxx
> Sent: Wednesday, May 02, 2001 9:36 AM
> Subject: RE: Current Day!
>
>
> Hi L
>
> Thanks. Version 7.02 end of day version.
>
> I am also getting results such as 20001032 (Oct 32nd, 2000) when I
> should
> be getting 20001101 (Nov 1st,2000). Interesting eh?
>
> Steve
> -----Original Message-----
> From: owner-metastock@xxxxxxxxxxxxx
> [mailto:owner-metastock@xxxxxxxxxxxxx]On Behalf Of Lionel Issen
> Sent: 02 May 2001 14:52
> To: metastock@xxxxxxxxxxxxx
> Subject: Re: Current Day!
>
>
> Steve:
> This is an excellent concise method.
>
> What version are you using?
>
> Lionel Issen
> lissen@xxxxxxxxx
> ----- Original Message -----
> From: Steve Brann
> To: metastock@xxxxxxxxxxxxx
> Sent: Wednesday, May 02, 2001 7:05 AM
> Subject: Current Day!
>
>
> Hi
>
> I use the following in my explorations to denote the date of
> the last
> price data in the format yyyymmdd;
>
> DayOfMonth()+(Month()*100)+(Year()*10000)
>
> However, this fails if the date is the first of the month such
> as
> March 1st 2001, instead of getting 20010301 I get 20010300!
>
> Has anyone else experienced this and if so is there a solution?
> By
> the way, using DayOfMonth() on its own produces 01.
>
> Thanks in advance
>
> Steve
>
=====
---
Allan Havemose, Ph.D.
havemose@xxxxxxxxxx
havemose@xxxxxxxxx
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
|