|
PureBytes Links
Trading Reference Links
|
Where?
----------
> From: Peter Gialames <investor@xxxxxxxxxxxxx>
> To: metastock@xxxxxxxxxxxxx
> Subject: RE: Current Day!
> Date: Thursday, May 03, 2001 11:34 AM
>
> 256Meg of memory - $43
>
> Equis rational that memory would be a bottleneck for double precision -
> PRICELESS!
>
> Just one mans 2¢
>
> -----Original Message-----
> From: owner-metastock@xxxxxxxxxxxxx
> [mailto:owner-metastock@xxxxxxxxxxxxx]On Behalf Of PD Manager
> Sent: Thursday, May 03, 2001 10:58 AM
> To: 'metastock@xxxxxxxxxxxxx'
> Subject: RE: Current Day!
>
>
> 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
>
|