|
PureBytes Links
Trading Reference Links
|
Ken,
Thanks for the explanation of how dates are internally stored.
This explains why Metastock 1.03 shows the year date as 101!
Thanks,
Ron Stockstill
> -----Original Message-----
> From: owner-metastock@xxxxxxxxxxxxx
> [mailto:owner-metastock@xxxxxxxxxxxxx]On Behalf Of PD Manager
> Sent: Thursday, May 03, 2001 3:38 PM
> To: 'metastock@xxxxxxxxxxxxx'
> Subject: FW: Current Day!
>
>
> Jeff:
>
> As promised, I just tested our date routines again and they are indeed
> calculating correctly. The results you are seeing are definitely
> caused by
> the precision error inherent in single precision floating point numbers.
> Future versions of MetaStock *may* use double precision approximations for
> floating point numbers rather than single precision approximations. I am
> unable to give a specific time frame as to when this capability will be
> available.
>
> In the meantime, I could offer a suggestion that reflects what we
> had to do
> with MetaStock data files. Those files are also maintained in single
> precision numbers (once again to save disk storage space). The dates in
> those files are actually stored in 7 digits rather than the inaccurate 8.
> The format used for dates is YYYMMDD. Note that three digits are used for
> the year rather than four. The year is encoded as the number of
> years AFTER
> 1900. For example 001031 represents 10/31/1900. Likewise, 1011031
> represents 10/31/2001.
>
> A formula could be written as follows to produce this result:
>
> DOM:=DayOfMonth();
> MON:=Month();
> YR:=Year()-1900;
>
> DT := (YR * 10000) + (MON * 100) + DOM;
>
> The DT variable would now contain a date in the format YYYMMDD
> with the year
> representing the three digit value as described above.
>
> Ken Hunt
> Programming Manager
> Equis International
>
>
> -----Original Message-----
> From: PD Manager
> Sent: Thursday, May 03, 2001 12:32 PM
> To: 'metastock@xxxxxxxxxxxxx'
> Subject: RE: Current Day!
>
>
> Jeff:
>
> I will look into the accuracy of the date routines themselves. My initial
> impression is that the problem is caused once all of the year,
> month and day
> data is combined into a single value that exceeds 7 significant
> digits. All
> numbers in all indicators (whether they may be displayed as
> integers or not)
> are stored and manipulated as single-precision floating point numbers.
>
> If the date routines in themselves are in error, we will get them fixed.
>
> As I have said in posts to this list before, we are not trying to hide
> anything. I have always been completely honest with information.
> Obviously, Equis and the customers on this list do not always agree with
> regard to decisions that have been made, but I can honestly say
> that we have
> not knowingly provided misinformation nor have we tried to hide anything
> from anyone.
>
> Ken Hunt
> Programming Manager
> Equis International
>
>
> -----Original Message-----
> From: Jeff Haferman [mailto:haferman@xxxxxxxxxxxxxxxxxxxxxxx]
> Sent: Thursday, May 03, 2001 11:05 AM
> To: metastock@xxxxxxxxxxxxx
> Subject: Re: Current Day!
>
>
> 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
> >
>
|