|
PureBytes Links
Trading Reference Links
|
------------------------------------------------------------------------
You cannot reply to this message via email because you have chosen not
to disclose your email address to the group.
To reply: http://groups.yahoo.com/group/equismetastock/post?act=reply&messageNum=6162
------------------------------------------------------------------------
Hi Gordon
> Thanks to you both for responding to my request for help on creating a
> Date for an expression in the Explorer.
> This certainly gets me along the right path - thank you - but from the
> Gif file attached you will see that when I ran an Explorer for your
> joint responses I get the correct date sometimes (within the last 65
> days) and sometimes a date which is outside the 65 days and indeed
> sometimes into 2004! The Date Column on the attached gif is from Roy's
> code and the Month and Day are from Joe J.'s - they both agree thank
> goodness!
There are at least two causes for your problem, and there may be others that
I haven't thought of.
I think the first and biggest problem relates to the method MS uses to store
numbers. When the day is multiplied by 1,000,000 we are just asking for
trouble. I think what is happening (I can't prove but I'm sure I'm right) is
that the addition process is introducing some fraction which is getting
rounded up to create a year that is 1 higher than it should be. This
accounts for the 2004 for some issues, and some will no doubt return 2003
instead of 2002 for a few others. Even after my fix you will need to be
alert for this.
One solution that appears at first glance to be successful is to truncate
the year down to two digits. This allows both multipliers to be reduced by a
factor of 100 thus greatly reducing the chance of an error. This solution
has problems of its own in that it requires the use of Frac() which can also
cause tiny errors - the very problem we are trying to get rid of. I think
I've got that covered by using Int() after Frac() (inner functions are
processed first), and then creating a deliberate error so that the 2 digit
year will have a surplus rather than missing fraction. Int() will restore
the year to the correct 2 digit value (I think). Just how you expand this
back to 4 digits I'm not sure but it will depend on what software you use
for further processing.
I found that a number of thinly traded issues reported years of 1999 and
even further back. In most cases I'm sure that this applies to issues that
are only traded once a month or so. If I was you I would use a cutoff date
in the filter so that any issue with less bars than a specified number since
a specified date would be excluded. This should be quite simple to
construct.
Make sure your exploration covers more periods than your lookback period.
Using LLV(C,65) should ensure that you have no problems but it doesn't hurt
to stipulate 100, 200 or whatever. I seldom use less than 400 for anything,
and even this is marginal (as far as accuracy is concerned) for some signals
using exponential moving averages.
Here is the modified code for the data column.
D:=ValueWhen(1,LLV(C,65)=C,DayOfMonth());
M:=ValueWhen(1,LLV(C,65)=C,Month());
Y:=ValueWhen(1,LLV(C,65)=C,Year());
D*10000+M*100+Int(Frac(Y/100)*100.01);
> I recall there was some discussion on locking into the correct dates in
> the dim and murky past. Do you guys have any further idea why I am
> getting erratic dates. I use the dd/mm/yyyy date inversion and my
> database is Australasian.
That will have to suffice until you come up with further problems. Check
your results carefully.
Regards
Roy
To unsubscribe from this group, send an email to:
equismetastock-unsubscribe@xxxxxxxxxxxxxxx
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
|