|
PureBytes Links
Trading Reference Links
|
I have to jump in here and agree. I followed the thread about 6-8 months ago
where someone brought up discrepancies in calculations. First, Equis denied
and skirted the problem. Whoever found the discrepancies took it a step
further. He did the calculations on a calculator, Excel, Tradestation, and
one other product. Each of those calculations yielded the exact same
result...only Metastock differed. Someone else who was a programmer jumped
in the thread indicating it was obvious that Metastock was using single
precision. Equis again beat around the bush but finally admitted it, using
the same lame excuse about doubling the size of the program. Some of the
list participants who were programmers questioned the validity of that
estimate.
I have a hard time understanding Equis's rational. It appears they are in
essence saying, We don't want to force anyone to spend $50-$100 for more
memory, so lets give incorrect results that could cost thousands in
erroneous trades. It's a fact of (computer) life, if you want more function,
it takes more resource. Every software vendor I have purchased software
from has, at some point, has drawn a line in the sand for a upcoming release
(won't support an old operating system, resource requirements have been
increased, etc). I can't see why Equis won't do the same, as long as they
stabilize the current version so people who choose not to upgrade will have
a useable product.
Supposedly, Equis is working on a totally revamped version of Metastock
(8.0?). Hopefully they will correct some of the current flaws and
shortcomings (precision problems, multiple security testing, and formula
language). If they do, Metastock will be a dynamite product.
Allan Wade
Phoenix, AZ
email: allanwade@xxxxxxxx
-----Original Message-----
From: owner-metastock@xxxxxxxxxxxxx [mailto:owner-metastock@xxxxxxxxxxxxx]
On Behalf Of Peter Gialames
Sent: Thursday, May 03, 2001 9:34 AM
To: metastock@xxxxxxxxxxxxx
Subject: RE: Current Day!
256Meg of memory - $43
Equis rational that memory would be a bottleneck for double precision -
PRICELESS!
Just one mans 2¢
-----Original Message-----
From: owner-metastock@xxxxxxxxxxxxx
[mailto:owner-metastock@xxxxxxxxxxxxx]On Behalf Of PD Manager
Sent: Thursday, May 03, 2001 10:58 AM
To: 'metastock@xxxxxxxxxxxxx'
Subject: RE: Current Day!
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
|