Am 09.09.2013 18:04, schrieb Allin Cottrell:
On Mon, 9 Sep 2013, Sven Schreiber wrote:
> At the end of the message I have a real-world data excerpt with all the
> realtime data for two periods, namely 2001m10 (aka 2001-10-01) and
> 2001m11 (aka 2001-11-01). For certain reasons I'm interested in the
> vintage of 2010-06-24, which means the following lines in this example
> (with realtime_start_date in the 3rd and realtime_end_date in the 4th
> col, see below):
>
> 2001-10-01 98.4253 20090327 20100624
> 2001-11-01 97.9427 20090327 20100624
>
> Inside my functions, I'm using the following join command (where
> strvin="2010-06-24":
> <hansl>
> # and also get the corresponding start dates to verify
> join @fpath startdates --tkey=observation_date --time="%Y-%m-%d" \
> --data=realtime_start_date --filter="realtime_end_date >= @strvin" \
> --aggr="seq:1"
> </hansl>
>
> Verbally, this should look for the vintage of 2010-06-24 (with a
> workaround: vintages whose validity did not end before the date
> 2010-06-24, and take the first of these), and then give me _not_ the
> value of the variable, but the date when this vintage was published.
>
> Now, gretl gives me the following output in the 'startdates' series:
> 2001:10 20090327
> 2001:11 20100625
>
> Notice that the first value gets the correct publication date (see
> above), but the second value is wrong; it is the publication date of the
> _following_ vintage, which after applying the filter in join should be
> the 2nd matching line, not the 1st one as requested per "seq:1". Or like
> I said before, it is as if gretl is partially filtering by ">" instead
> of ">=" suddenly.
>
> Or am I missing a bug in my own commands here?
Well, as stated above the "join" command doesn't work with the data given
below. Your filter
--filter="realtime_end_date >= 2010-06-04"
fails since the realtime_* columns are in numerical form, not YYYY-MM-DD.
Whoops, right, but in my actual code it was correct (so I just reported
a wrong format for 'strvin' above).
If I correct the filter to
--filter="realtime_end_date>=20100624"
I get the results you were expecting. Call your data rtdata.txt. Then the
following works OK:
... (correct results)
Hmm, interesting, so obviously something else must be different between
your setup and mine... Looks like further investigation is needed.
thanks,
sven