|
PureBytes Links
Trading Reference Links
|
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
>
|