[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Current Day!



PureBytes Links

Trading Reference Links

Ups ... my fingers got ahead of my brain :)

There memory consumption difference is probably about 700k, due to
open, high, low, close, volume, oi and date/time.

Argument still valid, though.

Allan
--- Allan Havemose <havemose@xxxxxxxxx> wrote:
> 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/


=====
---
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/