Thanks for the prompt reply!
Am 19.08.2013 21:14, schrieb Allin Cottrell:
On Mon, 19 Aug 2013, Sven Schreiber wrote:
>
> 1) I had to transform the "observation_date" column to match the monthly
> frequency in the gretl workfile: Alfred uses the first day of the month to
> indicate that month, like "1980-02-01" for February 1980. So I chopped off
> the trailing "-01" part of that column to get gretl-compatible monthly
date
> strings.
No need for that. Use the option --time="%Y-%m-%d" to set the appropriate
time format. (See the current CVS User's Guide.)
Ah ok -- I knew that option to specify the input format, but I didn't
know that gretl would then accept the recognized daily dates as monthly
date labels. Very good, it works. Would it even work with quarterly
frequency? (I will find out myself eventually....)
> 2) The above command still produces an error, namely:
> "join: missing string in filtering"
> I thought it has to do with the dot "." (which indicates NA in Alfred's
text
> file output, with Alfred's XLS files it's "#NV"), perhaps it
wasn't
> recognized by gretl/join as a string constant.
Ah, there's an interesting "gotcha" here. The field "." in
delimited-text
data input is mapped to NA by gretl (as in fact intended by Alfred), so
such observations of realtime_end_date are treated as missing, not as the
string literal ".". Hence the error message about a "missing string".
One
way around that problem would be to introduce a further filtering option
such as
I'm wondering whether gretl isn't perhaps doing "too much too early"
with the input file contents in the context of the join command. After
all, the values that are going to go into the gretl workfile are only in
the 'varname' column. The other columns are "only" used for filtering
and matching, so maybe they should be left as is? (With the further
exception of the column specified by --tkey, I guess)
--filter=missing(right-hand-colname)
Yes perhaps.
In the meantime one can replace "." in the input by a dummy string that
doesn't map to NA for gretl, e.g. "x" then do
--filter="realtime_end_date==x"
(But, agreed, it's not nice to have to pre-process the input.)
It works for now -- thanks!
Cheers,
sven