11:54 a.m.
The last release of gretl has changed the way the diff command works. Up to
version 2018c whenever a series and its first difference were defined,
extending the sample and defining for a second time the series and ist
first difference produced two new series that filled the new sample.
This is no more the case in the new gretl version. As it can be seen in the
attached script, invoking the diff command after extending the sample and
defining the series for a second time, does not result in a new series in
differences but in the old (shorter) one.
If instead of invoking the diff command an instruction such as
d_x = x- x(-1)
is used, the result is a differenced series that fills the whole sample.
The attached file shows the different results from the two approaches
sketched above.
My question is, is this a feature or a bug?
Best regards,
Javier Sansa
12:11 p.m.
On Mon, 14 Jan 2019, Javier Sansa wrote:
The last release of gretl has changed the way the diff command works.
Up to
version 2018c whenever a series and its first difference were defined,
extending the sample and defining for a second time the series and ist
first difference produced two new series that filled the new sample.
This is no more the case in the new gretl version. As it can be seen in the
attached script, invoking the diff command after extending the sample and
defining the series for a second time, does not result in a new series in
differences but in the old (shorter) one.
If instead of invoking the diff command an instruction such as
d_x = x- x(-1)
is used, the result is a differenced series that fills the whole sample.
The attached file shows the different results from the two approaches
sketched above.
My question is, is this a feature or a bug?
Clearly, a bug. Thanks for spotting this.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
2:16 p.m.
On Mon, 14 Jan 2019, Javier Sansa wrote:
The last release of gretl has changed the way the diff command works.
Up to
version 2018c whenever a series and its first difference were defined,
extending the sample and defining for a second time the series and ist
first difference produced two new series that filled the new sample.
This is no more the case in the new gretl version. As it can be seen in the
attached script, invoking the diff command after extending the sample and
defining the series for a second time, does not result in a new series in
differences but in the old (shorter) one.
If instead of invoking the diff command an instruction such as
d_x = x- x(-1)
is used, the result is a differenced series that fills the whole sample.
True. Using the diff() function produces the same result as your
formula above, but the diff command is not doing the right thing in
respect of a lengthened sample range. We'll figure out what the
problem is.
Allin Cottrell
2:46 p.m.
On Mon, 14 Jan 2019, Allin Cottrell wrote:
On Mon, 14 Jan 2019, Javier Sansa wrote:
> The last release of gretl has changed the way the diff command works. Up to
> version 2018c whenever a series and its first difference were defined,
> extending the sample and defining for a second time the series and ist
> first difference produced two new series that filled the new sample.
>
> This is no more the case in the new gretl version. As it can be seen in the
> attached script, invoking the diff command after extending the sample and
> defining the series for a second time, does not result in a new series in
> differences but in the old (shorter) one.
>
> If instead of invoking the diff command an instruction such as
>
> d_x = x- x(-1)
>
> is used, the result is a differenced series that fills the whole sample.
True. Using the diff() function produces the same result as your formula
above, but the diff command is not doing the right thing in respect of a
lengthened sample range. We'll figure out what the problem is.
It's now fixed in git. Snapshots will follow before long. This was
subtle fallout from the internal redefinition of "NA" since 2018c.
Allin
3:54 p.m.
Am 14.01.2019 um 15:46 schrieb Allin Cottrell:
On Mon, 14 Jan 2019, Allin Cottrell wrote:
> On Mon, 14 Jan 2019, Javier Sansa wrote:
>> d_x = x- x(-1)
>>
>> is used, the result is a differenced series that fills the whole sample.
>
> True. Using the diff() function produces the same result as your
> formula above, but the diff command is not doing the right thing in
> respect of a lengthened sample range. We'll figure out what the
> problem is.
It's now fixed in git. Snapshots will follow before long. This was
subtle fallout from the internal redefinition of "NA" since 2018c.
I'm glad that a new version wasn't already released before this fix, but
the two recent bugs together are really problematic IMHO, because they
affect general usage and no special niche case. So I'm now quite firmly
in favor of a new release.
thanks,
sven
4:04 p.m.
On Mon, 14 Jan 2019, Sven Schreiber wrote:
Am 14.01.2019 um 15:46 schrieb Allin Cottrell:
> On Mon, 14 Jan 2019, Allin Cottrell wrote:
>
>> On Mon, 14 Jan 2019, Javier Sansa wrote:
>>> d_x = x- x(-1)
>>>
>>> is used, the result is a differenced series that fills the whole sample.
>>
>> True. Using the diff() function produces the same result as your formula
>> above, but the diff command is not doing the right thing in respect of a
>> lengthened sample range. We'll figure out what the problem is.
>
> It's now fixed in git. Snapshots will follow before long. This was subtle
> fallout from the internal redefinition of "NA" since 2018c.
>
I'm glad that a new version wasn't already released before this fix, but the
two recent bugs together are really problematic IMHO, because they affect
general usage and no special niche case. So I'm now quite firmly in favor of
a new release.
I agree. If anyone wants to update translations, please go ahead. I
will aim to put out 2019a by the end of this week.
Allin
5:10 p.m.
On Mon, 14 Jan 2019, Allin Cottrell wrote:
On Mon, 14 Jan 2019, Sven Schreiber wrote:
>
> I'm glad that a new version wasn't already released before this fix, but
> the two recent bugs together are really problematic IMHO, because they
> affect general usage and no special niche case. So I'm now quite firmly in
> favor of a new release.
I agree. If anyone wants to update translations, please go ahead. I will aim
to put out 2019a by the end of this week.
That's good to know.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
5:53 a.m.
Glad to to about the 2019 release. However, we have been waiting for the
SVECM interface for so long, should we be expecting it this time around?
Regard
Timmy J.O
On Mon, Jan 14, 2019, 6:11 PM Riccardo (Jack) Lucchetti <
r.lucchetti(a)univpm.it wrote:
On Mon, 14 Jan 2019, Allin Cottrell wrote:
> On Mon, 14 Jan 2019, Sven Schreiber wrote:
>>
>> I'm glad that a new version wasn't already released before this fix,
but
>> the two recent bugs together are really problematic IMHO, because they
>> affect general usage and no special niche case. So I'm now quite firmly
in
>> favor of a new release.
>
> I agree. If anyone wants to update translations, please go ahead. I will
aim
> to put out 2019a by the end of this week.
That's good to know.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
6:50 a.m.
On Tue, 15 Jan 2019, Olasehinde Timmy wrote:
Glad to to about the 2019 release. However, we have been waiting for
the
SVECM interface for so long, should we be expecting it this time around?
I'm afraid not. This is a bug-fix release that must be out as soon as
possible. Neither Sven nor I were able to devote time to the SVECM GUI
interface. Note, however, that you can handle SVECM just fine from the
scripting interface, which is what I believe you should do anyway for
serious work.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
9:49 a.m.
Am 15.01.2019 um 07:50 schrieb Riccardo (Jack) Lucchetti:
On Tue, 15 Jan 2019, Olasehinde Timmy wrote:
> Glad to to about the 2019 release. However, we have been waiting for the
> SVECM interface for so long, should we be expecting it this time around?
I'm afraid not. This is a bug-fix release that must be out as soon as
possible. Neither Sven nor I were able to devote time to the SVECM GUI
interface.
Jack, I'm afraid I have to correct you on two accounts ;-)
First, the release and upgrade of the SVAR addon is not tied to the
gretl release cycle. That's why there's the "search for addons" item in
the help menu. But it's true there hasn't been an SVAR update in the
meantime.
Secondly, in late November / early December I actually developed a
prototype GUI for the SVEC case. However, the problem is that the
function package infrastructure in gretl so far only allows a single GUI
for a package, and the standard SVAR GUI is already overcrowded. One
idea was to turn the SVEC GUI into a formally separate package, but
there have been technical problems which prevented the SVEC_GUI package
to really use the SVAR.gfn backend.
So that's the status quo right now, more development thought about the
package infrastructure is needed.
cheers,
sven
9:58 a.m.
On Mon, 14 Jan 2019, Riccardo (Jack) Lucchetti wrote:
On Mon, 14 Jan 2019, Allin Cottrell wrote:
> On Mon, 14 Jan 2019, Sven Schreiber wrote:
>>
>> I'm glad that a new version wasn't already released before this fix, but
>> the two recent bugs together are really problematic IMHO, because they
>> affect general usage and no special niche case. So I'm now quite firmly in
>> favor of a new release.
>
> I agree. If anyone wants to update translations, please go ahead. I will
> aim to put out 2019a by the end of this week.
That's good to know.
Uhm, there's something else we need to fix before release: the deseas()
function. Example:
<hansl>
open bjg.gdt
x = deseas(lg)
</hansl>
This fails with current git. It should be an easy fix, since the x12
plugin works ok on its own, but evidently something goes wrong if you go
through the deseas() function. OTOH, the TRAMO/SEATS plugin works ok, so
<hansl>
x = deseas(lg, T)
</hansl>
seems to be ok.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
4:07 p.m.
On Tue, 15 Jan 2019, Riccardo (Jack) Lucchetti wrote:
On Mon, 14 Jan 2019, Riccardo (Jack) Lucchetti wrote:
> On Mon, 14 Jan 2019, Allin Cottrell wrote:
>
>> On Mon, 14 Jan 2019, Sven Schreiber wrote:
>>>
>>> I'm glad that a new version wasn't already released before this fix,
but
>>> the two recent bugs together are really problematic IMHO, because they
>>> affect general usage and no special niche case. So I'm now quite firmly
>>> in favor of a new release.
>>
>> I agree. If anyone wants to update translations, please go ahead. I will
>> aim to put out 2019a by the end of this week.
>
> That's good to know.
Uhm, there's something else we need to fix before release: the deseas()
function. Example:
<hansl>
open bjg.gdt
x = deseas(lg)
</hansl>
This fails with current git. It should be an easy fix, since the x12 plugin
works ok on its own, but evidently something goes wrong if you go through the
deseas() function. OTOH, the TRAMO/SEATS plugin works ok, so
<hansl>
x = deseas(lg, T)
</hansl>
seems to be ok.
That's now fixed in git.
Allin
7:46 a.m.
On Tue, 15 Jan 2019, Allin Cottrell wrote:
That's now fixed in git.
Thanks. While we're at it, we may want to slightly revisit the behaviour
of the TRAMO/SEATS backend for deseas(): if the automatic analysis finds
no seasonality, then the seasonally adjusted series is simply not created
and deseas() spits an error. Example:
<hansl>
open AWM18
catch series c = deseas(YER, T)
err = $error
printf "error %d: %s\n", err, errmsg(err)
</hansl>
gives
<output>
? catch series c = deseas(YER, T)
/home/jack/.gretl/tramo/graph/series/safin.t: No such file or directory
? err = $error
Generated scalar err = 11
? printf "error %d: %s\n", err, errmsg(err)
error 11: Error attempting to open file
</output>
I guess that in this case we could just fill the seasnoally-adjusted
series with the original values and issue a warning, but I'd rather ask
you guys for your opinion.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
8:43 p.m.
Am 16.01.2019 um 08:46 schrieb Riccardo (Jack) Lucchetti:
On Tue, 15 Jan 2019, Allin Cottrell wrote:
> That's now fixed in git.
Thanks. While we're at it, we may want to slightly revisit the
behaviour of the TRAMO/SEATS backend for deseas(): if the automatic
analysis finds no seasonality, then the seasonally adjusted series is
simply not created and deseas() spits an error. Example:
<hansl>
open AWM18
catch series c = deseas(YER, T)
err = $error
printf "error %d: %s\n", err, errmsg(err)
</hansl>
gives
<output>
? catch series c = deseas(YER, T)
/home/jack/.gretl/tramo/graph/series/safin.t: No such file or directory
? err = $error
Generated scalar err = 11
? printf "error %d: %s\n", err, errmsg(err)
error 11: Error attempting to open file
</output>
I guess that in this case we could just fill the seasnoally-adjusted
series with the original values and issue a warning, but I'd rather
ask you guys for your opinion.
Hm, silently returning "no action" when action is wanted wouldn't seem
right.
my 2c,
sven
9:08 p.m.
On Wed, 16 Jan 2019, Sven Schreiber wrote:
Am 16.01.2019 um 08:46 schrieb Riccardo (Jack) Lucchetti:
> On Tue, 15 Jan 2019, Allin Cottrell wrote:
>
>> That's now fixed in git.
>
> Thanks. While we're at it, we may want to slightly revisit the behaviour of
> the TRAMO/SEATS backend for deseas(): if the automatic analysis finds no
> seasonality, then the seasonally adjusted series is simply not created and
> deseas() spits an error. Example:
>
> <hansl>
> open AWM18
> catch series c = deseas(YER, T)
> err = $error
> printf "error %d: %s\n", err, errmsg(err)
> </hansl>
>
> gives
>
> <output>
> ? catch series c = deseas(YER, T)
> /home/jack/.gretl/tramo/graph/series/safin.t: No such file or directory
> ? err = $error
> Generated scalar err = 11
> ? printf "error %d: %s\n", err, errmsg(err)
> error 11: Error attempting to open file
> </output>
>
> I guess that in this case we could just fill the seasnoally-adjusted series
> with the original values and issue a warning, but I'd rather ask you guys
> for your opinion.
Hm, silently returning "no action" when action is wanted wouldn't seem
right.
Agreed, in general. But the case Jack is talking about is one where no
action is _required_, so far as SEATS can tell. (The series exhibits
no seasonality.)
Allin
9:41 a.m.
Am 16.01.2019 um 22:08 schrieb Allin Cottrell:
On Wed, 16 Jan 2019, Sven Schreiber wrote:
> Am 16.01.2019 um 08:46 schrieb Riccardo (Jack) Lucchetti:
>> behaviour of the TRAMO/SEATS backend for deseas(): if the
automatic
>> analysis finds no seasonality, then the seasonally adjusted series is
>> simply not created and deseas() spits an error.
>>
>> I guess that in this case we could just fill the seasnoally-adjusted
>> series with the original values and issue a warning, but I'd rather
>> ask you guys for your opinion.
>
> Hm, silently returning "no action" when action is wanted wouldn't seem
> right.
Agreed, in general. But the case Jack is talking about is one where no
action is _required_, so far as SEATS can tell. (The series exhibits no
seasonality.)
Right, I should have read more carefully.
thanks,
sven
1919
days inactive
1922
days old
15 comments
5 participants
participants (5)
-
Allin Cottrell -
Javier Sansa -
Olasehinde Timmy -
Riccardo (Jack) Lucchetti -
Sven Schreiber