Re: [Gretl-devel] Midas and join (or append)
Am 11.01.2018 um 22:44 schrieb Allin Cottrell:
On Thu, 11 Jan 2018, Riccardo (Jack) Lucchetti wrote:
> On Thu, 11 Jan 2018, Sven Schreiber wrote:
>> or perhaps the 'append' command is better suited than
join here? So
> I vote for join. IMO, the join command is kind of a relatively unknown
> gem that we have and I think your proposal, if implemented, will make
> it quite popular among people who work with time series datasets.
I agree that it would be nice to take the opportunity to raise the
profile of "join".
1) How do we actually implement this?
The other option would be to extend the "join" code itself
to handle
compaction on the fly. In a sense this would be cleaner but I'm pretty
sure it would be more complicated; "join" is already quite complicated.
Not sure if I understand all the ramifications; in principle I've
thought that the compaction would always come at the very end of what
join does, which would then seem relatively straightforward. EXCEPT:
given that AFAIK join may read inputs line by line instead of
variable-by-variable this of course makes it complex. Is this the reason
for a difficult implementation?
[> 2) How do we "package" whatever we implement for users?]
That leaves the "packaging" question: in principle whatever
we come up
with could be presented as as a "join" option even if the internals are
closer to "append".
I believe that any real solution would also have to cover the real-time
data aspect, because forecasting in real time is going to be an
important application of mixed-frequency data. At first glance this
would suggest join, since there is an entire chapter on it for real-time
data.
OTOH I don't think it would be a problem if a two-stage approach were to
be officially recommended:
1) Do what you need to do with join to get your high-frequency gretl
dataset. This becomes a temporary dataset.
2) Merge this temp data into your low-frequency dataset -- if this stage
is going to be called 'join' or 'append' doesn't matter all that
much.
This would seem to me clean enough to deal with real time data.
my 2c (haven't read that expression in a long time)
sven