|
PureBytes Links
Trading Reference Links
|
Ken,
Obviously, it's time. What are you guys running MS on? My Excel burns
through equations and file handling on a far more complex scale than
anything Metastock does. Worries about memory have nothing to do with this
situation. Haven't you read on the list about those of us who convert years
of price data for use in Excel? I am beginning to suspect that your
programmer is missing something. The little Calculator program that comes
with Windows correctly performs all of the basic math operations that
Metastock can't. By the way, Calculator is a whopping 270 bytes. Not
kilobytes.
Don't get me wrong, Ken. I appreciate the tough job you have with us
malcontents, and I like Metastock. I have all upgrades since 6.5, but I only
use it to do simple price plotting and a few primitive indicators. There is
no way that I am going to risk my financial life on a program that can't do
the elementary math that a $5 calculator can do. That means no Explorations,
System Tests, Advisors, or anything which could be contaminated by the math
core.
Let me try another path here. Your company touts all of these neat
little features which rely on an accurate math core. Now, MS is adding more
of all sorts of new Performance Systems and add-ins written by people
considered experts in their field. And personally, I like them, I think they
are a great addition to Metastock. However, when people start losing big
money because of faulty math execution and features which are prominently
advertised in your brochures, the legal ramifications will terminate your
company. Believe it. This is the USA. No disclaimer about 'trading risk'
will avert liability caused by an inaccurate program being sold as an
accurate program.
So here is a friendly suggestion: First, order out for pizzas and cokes,
because no one should be going home until a serious bug that has existed for
over 3 years is fixed. Put the patch up on the web site. No CDs.
And second, get some new intellect in the programming department. Obviously,
there have been some leaps in technology that have been missed.
Waiting for the patch,
Corey
----- Original Message -----
From: "PD Manager" <pdmanager@xxxxxxxxxxxxxxxxx>
To: <metastock@xxxxxxxxxxxxx>
Sent: Thursday, May 03, 2001 7:58 AM
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
>
>
|