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

Re: Current Day!



PureBytes Links

Trading Reference Links


Lionel :

I fully agree they just have to do what MS finally
did with Windows when they did build Windows2000
prof (after NT4).

Theo Lockefeer.


----- Original Message -----
From: "Lionel Issen" <lissen@xxxxxxxxx>
To: <metastock@xxxxxxxxxxxxx>
Sent: Thursday, May 03, 2001 10:09 PM
Subject: Re: Current Day!


> Peter:
>
> right on.
>
> I've said several times that Equis should write a new program from the
start
> instead of cutting and patching.
>
> Lionel Issen
> lissen@xxxxxxxxx
> ----- Original Message -----
> From: "Peter Gialames" <investor@xxxxxxxxxxxxx>
> To: <metastock@xxxxxxxxxxxxx>
> Sent: Thursday, May 03, 2001 11:34 AM
> 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
>
>
>
>