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

RE: Current Day!



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