|
PureBytes Links
Trading Reference Links
|
Ok Kent, but is it so important Metastock would not run easily on a 64 MB
Ram machine anymore ?
256 MB are so cheap nowadays and isn't this TA software purpose about making
money ?
I'm a little lost by the kind of argument, sorry.
Alain.
----- Original Message -----
From: "PD Manager" <pdmanager@xxxxxxxxxxxxxxxxx>
To: <metastock@xxxxxxxxxxxxx>
Sent: Thursday, May 03, 2001 11:41 PM
Subject: RE: Current Day!
> 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/
|