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

RE: Current Day!



PureBytes Links

Trading Reference Links

Why in the world would you use a float for date, Ken?
Since MStk [at least 6.52] uses Visual C++, why not something compatible
with time.h?

I'm sure Dick Cheney would agree that "It's time for that ancient CompuTrac
format to go!"

Bob

> -----Original Message-----
> From: owner-metastock@xxxxxxxxxxxxx
> [mailto:owner-metastock@xxxxxxxxxxxxx]On Behalf Of PD Manager
> Sent: Thursday, May 03, 2001 1: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
> >
>