|
PureBytes Links
Trading Reference Links
|
Right on!
Either the programming team isn't too good or higher management doesn't
understand which way is up as concerns trading software.
Lionel Issen
lissen@xxxxxxxxx
----- Original Message -----
From: "Allan Havemose" <havemose@xxxxxxxxx>
To: <metastock@xxxxxxxxxxxxx>
Sent: Thursday, May 03, 2001 3:10 PM
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/
|