|
PureBytes Links
Trading Reference Links
|
Ken,
Your response is really a red herring... the issue *really* isn't
single versus double precision numbers. The issue is that you seem
to have buggy date routines. I'm sure you can fix the date routines
*without* resorting to double precision...
Jeff
PD Manager 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
>
|