9:46 a.m.
Allin,
I am teaching on these days a very basic course on forecasting.
A part of the course is about smoothing models so I was looking at
exponential smoothing and today I was also preparing a script about the
Brown models for linear and quadratic local trends.
I would like to report some small problems I found:
1- The exponential moving average exist only at the GUI but there is not
an equivalent command script for that. I had to prepare a user function.
2- When I finished to prepare a first version of this function I noticed
that it only worked for quarterly data ( I suppose monthly as well ) but
not for annual data. The problem was about the different behaviour of
the 'obs' function with annual data (I saw this in the manual for
'genr'). If you use, for example,
series s1 = (obs=1) ? y[1] : delta*y+ (1-delta)*s1(-1)
this will work for quarterly or monthly data, but not in the same way
for annual data. Finally I found a solution, but it implied that my
script grew up in 10 lines!
Don't you think that 'obs' should work in the same way, idependently of
the value of $pd?
3- Finally I saved my Brown function as a function package ( I uploaded
it to the server as well), but I see another small problem: my main
function returns a list and if one wants the package to work ok this
list is mandatory, but the dialog box says "Assign return value
(optional)". ¿is there any way to change this to 'required'?
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es
12:47 p.m.
On Fri, 12 Feb 2010, Ignacio Diaz-Emparanza wrote:
I am teaching on these days a very basic course on forecasting.
A part of the course is about smoothing models so I was looking at
exponential smoothing and today I was also preparing a script about the
Brown models for linear and quadratic local trends.
I would like to report some small problems I found:
1- The exponential moving average exist only at the GUI but there is not
an equivalent command script for that. I had to prepare a user function.
Yes, we should probably add a built-in function for that -- or
maybe extend the current movavg function to accept a fractional
second argument to produce an EMA?
2- When I finished to prepare a first version of this function I
noticed
that it only worked for quarterly data ( I suppose monthly as well ) but
not for annual data. The problem was about the different behaviour of
the 'obs' function with annual data (I saw this in the manual for
'genr'). If you use, for example,
series s1 = (obs=1) ? y[1] : delta*y+ (1-delta)*s1(-1)
this will work for quarterly or monthly data, but not in the same way
for annual data. Finally I found a solution, but it implied that my
script grew up in 10 lines!
Don't you think that 'obs' should work in the same way, idependently of
the value of $pd?
Hmm, what does the dataset look like? The following works
correctly here:
<script>
open data3-6
series y = Ct
series s1 = y[1]
scalar d = 0.5
s1 = (obs=1) ? y[1] : d*y+ (1-d)*s1(-1)
print y s1 -o
</script>
3- Finally I saved my Brown function as a function package ( I
uploaded it to the server as well), but I see another small
problem: my main function returns a list and if one wants the
package to work ok this list is mandatory, but the dialog box
says "Assign return value (optional)". ¿is there any way to
change this to 'required'?
What happens if the user doesn't assign the return value?
I suppose there may be many functions that don't do anything
useful (or even visible) if the return value is not assigned,
while others might print something of interest. Perhaps we should
add a field in the function package definition that indicates
whether or not there's any point in running the function without
assignment.
Allin.
1:18 p.m.
El vie, 12-02-2010 a las 12:47 -0500, Allin Cottrell escribió:
On Fri, 12 Feb 2010, Ignacio Diaz-Emparanza wrote:
> I am teaching on these days a very basic course on forecasting.
> A part of the course is about smoothing models so I was looking at
> exponential smoothing and today I was also preparing a script about the
> Brown models for linear and quadratic local trends.
>
> I would like to report some small problems I found:
>
> 1- The exponential moving average exist only at the GUI but there is not
> an equivalent command script for that. I had to prepare a user function.
Yes, we should probably add a built-in function for that -- or
maybe extend the current movavg function to accept a fractional
second argument to produce an EMA?
Yes, I expected this second alternative.
> 2- When I finished to prepare a first version of this function I noticed
> that it only worked for quarterly data ( I suppose monthly as well ) but
> not for annual data. The problem was about the different behaviour of
> the 'obs' function with annual data (I saw this in the manual for
> 'genr'). If you use, for example,
>
> series s1 = (obs=1) ? y[1] : delta*y+ (1-delta)*s1(-1)
>
> this will work for quarterly or monthly data, but not in the same way
> for annual data. Finally I found a solution, but it implied that my
> script grew up in 10 lines!
>
> Don't you think that 'obs' should work in the same way, idependently of
> the value of $pd?
Hmm, what does the dataset look like? The following works
correctly here:
<script>
open data3-6
series y = Ct
series s1 = y[1]
scalar d = 0.5
s1 = (obs=1) ? y[1] : d*y+ (1-d)*s1(-1)
print y s1 -o
</script>
Oh! you got it by accident. Try this other initial value for s1:
<script>
open data3-6
series y = Ct
series s1 = 0
scalar d = 0.5
s1 = (obs=1) ? y[1] : d*y+ (1-d)*s1(-1)
print y s1 -o
</script>
> 3- Finally I saved my Brown function as a function package ( I
> uploaded it to the server as well), but I see another small
> problem: my main function returns a list and if one wants the
> package to work ok this list is mandatory, but the dialog box
> says "Assign return value (optional)". ¿is there any way to
> change this to 'required'?
What happens if the user doesn't assign the return value?
I suppose internally gretl makes the calculus, but the user obtains
nothing.
I suppose there may be many functions that don't do anything
useful (or even visible) if the return value is not assigned,
while others might print something of interest. Perhaps we should
add a field in the function package definition that indicates
whether or not there's any point in running the function without
assignment.
Yes, this is a possibility.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es
1:28 p.m.
On Fri, 12 Feb 2010, Ignacio Diaz-Emparanza wrote:
El vie, 12-02-2010 a las 12:47 -0500, Allin Cottrell escribió:
> Hmm, what does the dataset look like? The following works
> correctly here:
>
> <script>
> open data3-6
> series y = Ct
> series s1 = y[1]
> scalar d = 0.5
> s1 = (obs=1) ? y[1] : d*y+ (1-d)*s1(-1)
> print y s1 -o
> </script>
Oh! you got it by accident. Try this other initial value for s1:
<script>
open data3-6
series y = Ct
series s1 = 0
scalar d = 0.5
s1 = (obs=1) ? y[1] : d*y+ (1-d)*s1(-1)
print y s1 -o
</script>
The output still looks OK to me, though maybe I'm missing
something. What output are you getting?
Allin.
1:39 p.m.
El vie, 12-02-2010 a las 13:28 -0500, Allin Cottrell escribió:
The output still looks OK to me, though maybe I'm missing
something. What output are you getting?
Allin.
<output>
...
? series y = Ct
Se ha generado la serie y (ID 3)
? series s1 = 0
Se ha generado la serie s1 (ID 4)
Se ha generado el escalar d = 0,5
? s1 = (obs=1) ? y[1] : d*y+ (1-d)*s1(-1)
Se ha reemplazado la serie s1 (ID 4)
? print y s1 -o
y s1
1959 7876 0,00
1960 7926 3963,00
1961 7954 5958,50
1962 8220 7089,25
1963 8434 7761,62
1964 8817 8289,31
1965 9257 8773,16
1966 9674 9223,58
...
<output>
If the behaviour was the same as for $pd>1, the first observation of s1
should be 7876. Here as obs=1 corresponds to year 1, it is false for all
the available data.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es
1:34 p.m.
Oh! you got it by accident. Try this other initial value for s1:
<script>
open data3-6
series y = Ct
series s1 = 0
scalar d = 0.5
s1 = (obs=1) ? y[1] : d*y+ (1-d)*s1(-1)
print y s1 -o
</script>
Sorry, I probably had to explain this a litle more.
With periodicity ($pd)> 1 (quarterly or monthly data,..)
y[1] is refering to the first observation of the series,
but with annual data it is refering to the observation of year '1'.
For example in data3-6.gdt the first value of series Ct is Ct(1959)
so if you want to put the initial value of s1, in the previous script,
to the first observation of Ct the command has to be:
s1 = (obs=1959) ? y[1] : d*y+ (1-d)*s1(-1)
and I think it should be better that the behaviour of the 'obs' function
be the same as with $pd>1, such that 'obs=1' points to the first
observation in the available data.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es
1:44 p.m.
On Fri, 12 Feb 2010, Ignacio Diaz-Emparanza wrote:
With periodicity ($pd)> 1 (quarterly or monthly data,..)
y[1] is refering to the first observation of the series,
but with annual data it is refering to the observation of year '1'.
Duh, sorry, I wasn't paying enough attention. I'll think about it,
but here's a quick work-around:
<script>
open data3-6
series y = Ct
series s1 = 0
scalar d = 0.5
scalar T = $nobs
loop t=1..T
s1[t] = (t==1) ? y[t] : d*y[t]+ (1-d)*s1[t-1]
endloop
print y s1 -o
</script>
Allin
1:49 p.m.
On Fri, 12 Feb 2010, Allin Cottrell wrote:
On Fri, 12 Feb 2010, Ignacio Diaz-Emparanza wrote:
> With periodicity ($pd)> 1 (quarterly or monthly data,..)
> y[1] is refering to the first observation of the series,
> but with annual data it is refering to the observation of year '1'.
Duh, sorry, I wasn't paying enough attention. I'll think about
it...
The difficulty is this: with quarterly or monthly data there's no
possible confusion between the alternate forms of identifying
observations: "obs=1975:4" versus "obs=3", for example. But with
annual data confusion is possible. But I'll consider it some more.
Allin
3:52 p.m.
New subject: comparisons against "obs" (was ema, obs and optional parameter)
On Fri, 12 Feb 2010, Allin Cottrell wrote:
The difficulty is this: with quarterly or monthly data there's
no possible confusion between the alternate forms of identifying
observations: "obs=1975:4" versus "obs=3", for example. But with
annual data confusion is possible. But I'll consider it some
more.
I'm a little clearer on the issue now. Consider the string on the
right-hand side of "obs==". With quarterly data you can supply,
e.g., "1980:2" and gretl will translate this into an integer that
can be compared with the numerical value of "obs". Or you can
supply, say, "1" and gretl can make the comparison directly.
With annual data, the string representing a year is
indistinguishable from a string representing a general scalar. So
you can't reference observations by year in this context unless we
do the special thing of making the internal "obs" variable produce
the year instead of a 1-based index. And that's what we do right
now.
The downside of current practice is just what you discovered; the
upside is that "obs=<year>" works. In setting this up I was
thinking it would be more helpful in general to be able to
reference observations by year. For example, suppose you want a
dummy for 1974: then "d = (obs==1974)" will do it. But sometimes
you want to reference the extrema of the series, and then it's
easier to say "(obs==1)" than to find the starting year.
(Note that the expressions "Ct[1959]" and "Ct[1]" will both work
to get the first value of an annual series starting in 1959.
That's because we know that in the context "varname[string]" the
string must represent an observation: we look at 1959, see that
it's much too big to be a plain index value for an annual dataset,
and translate it.)
Anyway, I'm not sure what to do about this. Opinions welcome.
Allin
6:15 p.m.
New subject: comparisons against "obs" (was ema, obs and optional parameter)
Hi Allin,
Well, lately I have been working with JavaScript and Java, and one solution
that I think you could consider is to create an object like notation for
variables. For example, this case you could use:
obs.year==1974
obs==1 (or some other like obs.index)
This way the variables parser would clearly know what do return.
Hélio
On Fri, Feb 12, 2010 at 8:52 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Fri, 12 Feb 2010, Allin Cottrell wrote:
> The difficulty is this: with quarterly or monthly data there's
> no possible confusion between the alternate forms of identifying
> observations: "obs=1975:4" versus "obs=3", for example. But
with
> annual data confusion is possible. But I'll consider it some
> more.
I'm a little clearer on the issue now. Consider the string on the
right-hand side of "obs==". With quarterly data you can supply,
e.g., "1980:2" and gretl will translate this into an integer that
can be compared with the numerical value of "obs". Or you can
supply, say, "1" and gretl can make the comparison directly.
With annual data, the string representing a year is
indistinguishable from a string representing a general scalar. So
you can't reference observations by year in this context unless we
do the special thing of making the internal "obs" variable produce
the year instead of a 1-based index. And that's what we do right
now.
The downside of current practice is just what you discovered; the
upside is that "obs=<year>" works. In setting this up I was
thinking it would be more helpful in general to be able to
reference observations by year. For example, suppose you want a
dummy for 1974: then "d = (obs==1974)" will do it. But sometimes
you want to reference the extrema of the series, and then it's
easier to say "(obs==1)" than to find the starting year.
(Note that the expressions "Ct[1959]" and "Ct[1]" will both work
to get the first value of an annual series starting in 1959.
That's because we know that in the context "varname[string]" the
string must represent an observation: we look at 1959, see that
it's much too big to be a plain index value for an annual dataset,
and translate it.)
Anyway, I'm not sure what to do about this. Opinions welcome.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
8:09 a.m.
New subject: comparisons against "obs" (was ema, obs and optional parameter)
Allin Cottrell schrieb:
On Fri, 12 Feb 2010, Allin Cottrell wrote:
With annual data, the string representing a year is
indistinguishable from a string representing a general scalar. So
you can't reference observations by year in this context unless we
do the special thing of making the internal "obs" variable produce
the year instead of a 1-based index. And that's what we do right
now.
...
Anyway, I'm not sure what to do about this. Opinions welcome.
Starting with two caveats: I haven't followed this thread closely. And
not sure if what I'm saying is helpful. But here goes:
I think this is another example where the "sloppy" attitude of gretl
towards strings bites back. Because gretl is trying to accomodate a lot
of different usages (in a sense, trying to be "too user-friendly"), in a
script it's often not totally clear if a number literal is actually a
number or a camouflaged string literal. I venture the hypothesis that
life would actually be easier in the medium run if the user were
required to properly distinguish between the two. (Meaning that string
literals would always have to be properly indicated by quotes or
somesuch.) The confusing situation of @i and $i (where i is a loop index
variable) looks like another incarnation of this problem.
I'm wondering if for gretl 2.0 (or gretl 3000, or whatever) fundamental
design issues like this should be changed? Well maybe it's not feasible,
I don't know.
thanks,
sven
4:57 a.m.
El vie, 12-02-2010 a las 13:44 -0500, Allin Cottrell escribió:
On Fri, 12 Feb 2010, Ignacio Diaz-Emparanza wrote:
> With periodicity ($pd)> 1 (quarterly or monthly data,..)
> y[1] is refering to the first observation of the series,
> but with annual data it is refering to the observation of year '1'.
Duh, sorry, I wasn't paying enough attention. I'll think about it,
but here's a quick work-around:
<script>
open data3-6
series y = Ct
series s1 = 0
scalar d = 0.5
scalar T = $nobs
loop t=1..T
s1[t] = (t==1) ? y[t] : d*y[t]+ (1-d)*s1[t-1]
endloop
print y s1 -o
</script>
Allin
Oh, yes it works ! I did not try with 't' because I thought it was an
alias of 'obs', given the explanation in the function reference:
<quotation>
obs
Output: series
Returns a series of consecutive integers, setting 1 at the start of the
dataset. Note that the result is invariant to subsampling. This function
is especially useful with time-series datasets. Note: you can write t
instead of obs with the same effect.
See also obsnum.
</quotation>
This definition does not seems to be totally correct given the different
behaviour of 'obs' for annual data.
I agree with Sven in that sometimes it is not clear if we are treating
with a number or with a string.
I also agre with Helio's suggestion of separating the string (obs.year)
and the number (obs) of each observation entry. I was thinking that to
have a notation consistent for all the periodicities It would be better
to use 'obs.date' to note the string of the date and 'obs' for the
integer index, but now I see that 't' is already working always as
integer entry, so the solution may be:
1- to define "obs.date" as (only) the string of the date and leaving
'obs' as it is now (to avoid backward incompatibilities, and deprecate
in the future), or
2- as 'obs' works as 'obs.date' for annual data, and for monthly or
seasonal data is already detected as string when writing the date label,
we don't need a new function, we only need that a litle paragraph about
the different behaviour of the 't' function be added to the 'genr' entry
in the manual. (But yes, Sven, we are maintaining the mixture of strings
and numbers in 'obs' in this case)
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es
12:38 p.m.
El lun, 15-02-2010 a las 10:57 +0100, Ignacio Diaz-Emparanza escribió:
El vie, 12-02-2010 a las 13:44 -0500, Allin Cottrell escribió:
> On Fri, 12 Feb 2010, Ignacio Diaz-Emparanza wrote:
>
> > With periodicity ($pd)> 1 (quarterly or monthly data,..)
> > y[1] is refering to the first observation of the series,
> > but with annual data it is refering to the observation of year '1'.
>
> Duh, sorry, I wasn't paying enough attention. I'll think about it,
> but here's a quick work-around:
>
> <script>
> open data3-6
> series y = Ct
> series s1 = 0
> scalar d = 0.5
> scalar T = $nobs
> loop t=1..T
> s1[t] = (t==1) ? y[t] : d*y[t]+ (1-d)*s1[t-1]
> endloop
> print y s1 -o
> </script>
>
> Allin
Oh, yes it works ! I did not try with 't' because I thought it was an
alias of 'obs', given the explanation in the function reference:
Sorry I am seeing I was absolutely confused about that. I didn't notice
that you were using a loop in 't'. In general in genr commands really
't' is an alias of 'obs'. So the problem persists also with 't'.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es
4:40 p.m.
On Mon, 15 Feb 2010, Ignacio Diaz-Emparanza wrote:
El lun, 15-02-2010 a las 10:57 +0100, Ignacio Diaz-Emparanza
escribió:
> El vie, 12-02-2010 a las 13:44 -0500, Allin Cottrell escribió:
> > On Fri, 12 Feb 2010, Ignacio Diaz-Emparanza wrote:
> >
> > > With periodicity ($pd)> 1 (quarterly or monthly data,..)
> > > y[1] is refering to the first observation of the series,
> > > but with annual data it is refering to the observation of year
'1'.
> >
> > Duh, sorry, I wasn't paying enough attention. I'll think about it,
> > but here's a quick work-around:
> >
> > <script>
> > open data3-6
> > series y = Ct
> > series s1 = 0
> > scalar d = 0.5
> > scalar T = $nobs
> > loop t=1..T
> > s1[t] = (t==1) ? y[t] : d*y[t]+ (1-d)*s1[t-1]
> > endloop
> > print y s1 -o
> > </script>
>
> Oh, yes it works ! I did not try with 't' because I thought it was an
> alias of 'obs', given the explanation in the function reference:
Sorry I am seeing I was absolutely confused about that. I didn't notice
that you were using a loop in 't'. In general in genr commands really
't' is an alias of 'obs'. So the problem persists also with 't'.
OK, I think I have a solution. As you suggested originally, we'll
make "obs" consistent, such that it always gives a series
containing the 1-based index of the observations, regardless of
the periodicity of the data.
This means that, e.g., "(obs==1970)" will not work to pick out the
observation for 1970 in an annual time series. But if you want to
do that you can use the function obsnum(), as in
series d70 = (obs==obsnum(1970))? 1 : 0
(I had forgotten about obsnum, but it's clearly the tool for the
job here.)
Allin.
3:48 a.m.
El lun, 15-02-2010 a las 16:40 -0500, Allin Cottrell escribió:
OK, I think I have a solution. As you suggested originally,
we'll
make "obs" consistent, such that it always gives a series
containing the 1-based index of the observations, regardless of
the periodicity of the data.
OK.
This means that, e.g., "(obs==1970)" will not work to pick
out the
observation for 1970 in an annual time series. But if you want to
do that you can use the function obsnum(), as in
series d70 = (obs==obsnum(1970))? 1 : 0
(I had forgotten about obsnum, but it's clearly the tool for the
job here.)
This will do the things much more clear for the user, I think.
But it is another backward incompatible change, so please remember, if
possible, to put a warning for the case of someone uses the old format,
and update the manual. Thank you.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es
4 p.m.
On Tue, 16 Feb 2010, Ignacio Diaz-Emparanza wrote:
El lun, 15-02-2010 a las 16:40 -0500, Allin Cottrell escribió:
> OK, I think I have a solution. As you suggested originally, we'll
> make "obs" consistent, such that it always gives a series
> containing the 1-based index of the observations, regardless of
> the periodicity of the data.
>
OK.
> This means that, e.g., "(obs==1970)" will not work to pick out the
> observation for 1970 in an annual time series. But if you want to
> do that you can use the function obsnum(), as in
>
> series d70 = (obs==obsnum(1970))? 1 : 0
>
> (I had forgotten about obsnum, but it's clearly the tool for the
> job here.)
This will do the things much more clear for the user, I think.
But it is another backward incompatible change, so please remember, if
possible, to put a warning for the case of someone uses the old format,
and update the manual. Thank you.
The manual is now updated, but it's not possible to issue a
warning, I'm afraid. When the user types, e.g., "1980" after "=="
in a genr expression, we don't know what he/she intends to compare
it against, and whether the comparison make sense.
Allin.
5:47 a.m.
El mar, 16-02-2010 a las 16:00 -0500, Allin Cottrell escribió:
The manual is now updated, but it's not possible to issue a
warning, I'm afraid. When the user types, e.g., "1980" after
"=="
in a genr expression, we don't know what he/she intends to compare
it against, and whether the comparison make sense.
Allin.
I see that. But I see this is because you have only solved "my problem"
changing the behaviour of 'obs' for annual data. But the things are not
so clear for the user, because the paragraph below (extracted from the
'genr' manual entry) describes 3 or 4 different uses of the 'obs'
function:
"The special variable obs serves as an index of the observations. For
instance genr dum =(obs=15) will generate a dummy variable that has
value 1 for observation 15, 0 otherwise. You can also use this variable
to pick out particular observations by date or name. For example, genr d
= (obs>1986:4), genr d = (obs>"2008/04/01"), or genr d =
(obs="CA"). If
daily dates or observation labels are used in this context, they should
be enclosed in double quotes. Quarterly and monthly dates (with a colon)
may be used unquoted. Note that in the case of annual time series data,
the year is not distinguishable syntactically from a plain integer;
therefore if you wish to compare observations against obs by year you
must use the function obsnum to convert the year to a 1-based index
value, as in genr d = (obs>obsnum(1986))."
I think it would be more clear if 'obs' were used only for 1-base
periods. So the user should use 'obsnum' for all the other
possibilities:
genr d = (obs>1986:4) --> genr d = (obs>obsnum(1986:4))
genr d = (obs>"2008/04/01") -- genr d = (obs>obsnum(2008/04/01))
genr d = (obs="CA") --> genr d = (obs=obsnum(CA))
I know this imply more backward-incompatibilities than the current
state, because in the three cases at left side above, gretl will produce
an error, but may be easier to display a warning in them ¿isn't it?
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es
7:57 a.m.
Ignacio Diaz-Emparanza schrieb:
I know this imply more backward-incompatibilities than the current
state, because in the three cases at left side above, gretl will produce
an error, but may be easier to display a warning in them ¿isn't it?
Zwei Seelen wohnen, ach! in meiner Brust (Goethe's Faust; Two souls,
alas! reside within my breast)
While I'm all for a cleanup along Ignacio's lines (and maybe more, as I
mentioned before), I'm also against script-breaking changes, as you
know. These changes seem to be quite disruptive.
AFAIK there is a general idea floating around to have a release at some
point with a lot of backward incompatibilities, and of course also a lot
of cleanups. Jack started a wiki page about it. Maybe it's time to make
some concrete plans for gretl 2.0 or whatever it will be called? Like
for the next gretl conference, or 02/02 next year...
cheers,
sven
9:55 a.m.
On Wed, 17 Feb 2010, Sven Schreiber wrote:
Ignacio Diaz-Emparanza schrieb:
> I know this imply more backward-incompatibilities than the current
> state, because in the three cases at left side above, gretl will produce
> an error, but may be easier to display a warning in them ¿isn't it?
[This in regard to requiring use of the obsnum() function in
comparing dates or observation labels against the "obs" index.]
Zwei Seelen wohnen, ach! in meiner Brust (Goethe's Faust; Two
souls,
alas! reside within my breast)
While I'm all for a cleanup along Ignacio's lines (and maybe more, as I
mentioned before), I'm also against script-breaking changes, as you
know. These changes seem to be quite disruptive.
I agree. What we have at the moment is, in effect, "implicit
obsnum() conversion" for syntactical elements that can be
recognized unambiguously as candidates for such conversion. My
suggestion would be:
(a) re-word the manual (and rewrite any packaged scripts that use
this implicit conversion) to use obsnum() explicitly, for the sake
of clarity as Ignacio suggests, but
(b) do not actually remove the implicit conversion, so that old
scripts are not broken. (I'm not aware of any actual problems
generated by the implicit conversion, other than a certain lack of
clarity.)
AFAIK there is a general idea floating around to have a release
at some point with a lot of backward incompatibilities, and of
course also a lot of cleanups. Jack started a wiki page about
it. Maybe it's time to make some concrete plans for gretl 2.0 or
whatever it will be called? Like for the next gretl conference,
or 02/02 next year...
OK by me.
Allin.
5:14 a.m.
El mié, 17-02-2010 a las 09:55 -0500, Allin Cottrell escribió:
> While I'm all for a cleanup along Ignacio's lines (and
maybe more, as I
> mentioned before), I'm also against script-breaking changes, as you
> know. These changes seem to be quite disruptive.
I agree. What we have at the moment is, in effect, "implicit
obsnum() conversion" for syntactical elements that can be
recognized unambiguously as candidates for such conversion. My
suggestion would be:
(a) re-word the manual (and rewrite any packaged scripts that use
this implicit conversion) to use obsnum() explicitly, for the sake
of clarity as Ignacio suggests, but
(b) do not actually remove the implicit conversion, so that old
scripts are not broken. (I'm not aware of any actual problems
generated by the implicit conversion, other than a certain lack of
clarity.)
Ok, that is perfect !
> AFAIK there is a general idea floating around to have a release
> at some point with a lot of backward incompatibilities, and of
> course also a lot of cleanups. Jack started a wiki page about
> it. Maybe it's time to make some concrete plans for gretl 2.0 or
> whatever it will be called? Like for the next gretl conference,
> or 02/02 next year...
OK by me.
I will have a look at this list in the wiki page, and send some
comments.
BTW, Jack, will it be possible to have the second gretl conference at
Ancona? You should decide that soon, because in case you prefer not to
do it in Ancona in 2011, I think the Polish people, or may be others,
could be interested in organizing it.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es
6:54 a.m.
New subject: Graph and zoom
I have discovered an small bug in the zoom of the graphs and other
problem that I don't know whether it is a bug or not.
Through File/databases/database server
connect and import from "Banco de España", chapter 24, the series
BE241503, Paro registrado, (unemployment).
1- Right click on the series and select "time series plot" (yes we were
that bad in 2009 and now we are worse). If you move the cursor over the
lines in the graph, the coordinates do not appear at the left-bottom
corner and right clicking on the graph the option "zoom" does not
appear. Close the graph and restrict the sample to 1979:04-2009:05 (362
obs), the coordinates appear in the left-bottom corner and the zoom is
accesible by right-clicking. In fact the limit for this behaviour in
this series is 362 obs. If you select 363 the things are the same as in
the full sample. Is this a bug or a feature? (I don't know)
2- Assume you are with less than 363 obs., for example, 1979:04-2009:05,
The Y-axis has an scale that goes from 1e+06 to 4e+06, but if you move
the cursor over the series the coordinates that appear at the
left-bottom corner show the X correctly but the Y divided by 1e+06.
3- If, with the same sample, yo try to do a zoom over a region of the
graph, gretl tries to show the graph over a region with the Y
coordinates divided by 1e+06 as well, so it is imposible to see the
data.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es
9:56 p.m.
New subject: Graph and zoom
On Thu, 18 Feb 2010, Ignacio Diaz-Emparanza wrote:
I have discovered an small bug in the zoom of the graphs and other
problem that I don't know whether it is a bug or not.
Through File/databases/database server
connect and import from "Banco de España", chapter 24, the series
BE241503, Paro registrado, (unemployment).
1- Right click on the series and select "time series plot" (yes
we were that bad in 2009 and now we are worse). If you move the
cursor over the lines in the graph, the coordinates do not
appear at the left-bottom corner and right clicking on the graph
the option "zoom" does not appear...
I haven't had time to dive into the code at this point, but I have
tried displaying this graph (using current CVS, on Linux, in both
English and Spanish) and I can't reproduce the problem you
describe. Was this on Linux or Windows? Is the graph displayed
directly from the database listing? (I tried that, and also
importing the series then doing the graph, and couldn't provoke a
problem in either case.)
Allin.
5:03 a.m.
New subject: Graph and zoom
Allin Cottrell schrieb:
On Thu, 18 Feb 2010, Ignacio Diaz-Emparanza wrote:
> I have discovered an small bug in the zoom of the graphs and other
> problem that I don't know whether it is a bug or not.
>
> Through File/databases/database server
> connect and import from "Banco de España", chapter 24, the series
> BE241503, Paro registrado, (unemployment).
>
> 1- Right click on the series and select "time series plot" (yes
> we were that bad in 2009 and now we are worse). If you move the
> cursor over the lines in the graph, the coordinates do not
> appear at the left-bottom corner and right clicking on the graph
> the option "zoom" does not appear...
I haven't had time to dive into the code at this point, but I have
tried displaying this graph (using current CVS, on Linux, in both
English and Spanish) and I can't reproduce the problem you
describe. Was this on Linux or Windows? Is the graph displayed
directly from the database listing? (I tried that, and also
importing the series then doing the graph, and couldn't provoke a
problem in either case.)
I have no problems either, but this is probably not another datapoint,
because this is also on Linux with Cvs.
OT: I wasn't really aware of all those databases and how easy it is to
import them, very cool!
-sven
6:32 a.m.
New subject: Graph and zoom
El vie, 19-02-2010 a las 11:03 +0100, Sven Schreiber escribió:
Allin Cottrell schrieb:
> On Thu, 18 Feb 2010, Ignacio Diaz-Emparanza wrote:
>
>> I have discovered an small bug in the zoom of the graphs and other
>> problem that I don't know whether it is a bug or not.
>>
>> Through File/databases/database server
>> connect and import from "Banco de España", chapter 24, the series
>> BE241503, Paro registrado, (unemployment).
>>
>> 1- Right click on the series and select "time series plot" (yes
>> we were that bad in 2009 and now we are worse). If you move the
>> cursor over the lines in the graph, the coordinates do not
>> appear at the left-bottom corner and right clicking on the graph
>> the option "zoom" does not appear...
>
> I haven't had time to dive into the code at this point, but I have
> tried displaying this graph (using current CVS, on Linux, in both
> English and Spanish) and I can't reproduce the problem you
> describe. Was this on Linux or Windows? Is the graph displayed
> directly from the database listing? (I tried that, and also
> importing the series then doing the graph, and couldn't provoke a
> problem in either case.)
>
I have no problems either, but this is probably not another datapoint,
because this is also on Linux with Cvs.
This was with gretl from two or three days ago CVS on Ubuntu Linux 9.10,
but I have just removed completely and installed again gretl from
current CVS and the problem persists (in Spanish and English gretl). So
I suppose may be a problem with my version of Gnuplot. It is version
4.2.5-2
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es
11:33 a.m.
New subject: Graph and zoom
On Fri, 19 Feb 2010, Ignacio Diaz-Emparanza wrote:
El vie, 19-02-2010 a las 11:03 +0100, Sven Schreiber escribió:
> Allin Cottrell schrieb:
> > On Thu, 18 Feb 2010, Ignacio Diaz-Emparanza wrote:
> >
> >> I have discovered an small bug in the zoom of the graphs and other
> >> problem that I don't know whether it is a bug or not.
> >>
> >> Through File/databases/database server
> >> connect and import from "Banco de España", chapter 24, the
series
> >> BE241503, Paro registrado, (unemployment).
> >>
> >> 1- Right click on the series and select "time series plot" (yes
> >> we were that bad in 2009 and now we are worse). If you move the
> >> cursor over the lines in the graph, the coordinates do not
> >> appear at the left-bottom corner and right clicking on the graph
> >> the option "zoom" does not appear...
> >
> > I haven't had time to dive into the code at this point, but I have
> > tried displaying this graph (using current CVS, on Linux, in both
> > English and Spanish) and I can't reproduce the problem you
> > describe...
>
> I have no problems either, but this is probably not another datapoint,
> because this is also on Linux with Cvs.
This was with gretl from two or three days ago CVS on Ubuntu Linux 9.10,
but I have just removed completely and installed again gretl from
current CVS and the problem persists (in Spanish and English gretl). So
I suppose may be a problem with my version of Gnuplot. It is version
4.2.5-2
Ah, I'll look into that. But if it works for you, I'd recommend
using the gnuplot binary at
http://gretl.sourceforge.net/gnuplot_for_gretl.html
Allin.
2:48 p.m.
New subject: Graph and zoom
El vie, 19-02-2010 a las 11:33 -0500, Allin Cottrell escribió:
Ah, I'll look into that. But if it works for you, I'd
recommend
using the gnuplot binary at
http://gretl.sourceforge.net/gnuplot_for_gretl.html
Allin.
I have just installed from the binary, and it works perfectly !!
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es
8:38 a.m.
I just want to let everyone know that I would like to volunteer in
advance for the 3rd or the 4th one to take place at the TOBB
University of Economics and Technology in Ankara :-)
Cheers
Talha
On Thu, Feb 18, 2010 at 12:14 PM, Ignacio Diaz-Emparanza
<ignacio.diaz-emparanza(a)ehu.es> wrote:
El mié, 17-02-2010 a las 09:55 -0500, Allin Cottrell escribió:
> > While I'm all for a cleanup along Ignacio's lines (and maybe more, as I
> > mentioned before), I'm also against script-breaking changes, as you
> > know. These changes seem to be quite disruptive.
>
> I agree. What we have at the moment is, in effect, "implicit
> obsnum() conversion" for syntactical elements that can be
> recognized unambiguously as candidates for such conversion. My
> suggestion would be:
>
> (a) re-word the manual (and rewrite any packaged scripts that use
> this implicit conversion) to use obsnum() explicitly, for the sake
> of clarity as Ignacio suggests, but
>
> (b) do not actually remove the implicit conversion, so that old
> scripts are not broken. (I'm not aware of any actual problems
> generated by the implicit conversion, other than a certain lack of
> clarity.)
Ok, that is perfect !
>
> > AFAIK there is a general idea floating around to have a release
> > at some point with a lot of backward incompatibilities, and of
> > course also a lot of cleanups. Jack started a wiki page about
> > it. Maybe it's time to make some concrete plans for gretl 2.0 or
> > whatever it will be called? Like for the next gretl conference,
> > or 02/02 next year...
>
> OK by me.
I will have a look at this list in the wiki page, and send some
comments.
BTW, Jack, will it be possible to have the second gretl conference at
Ancona? You should decide that soon, because in case you prefer not to
do it in Ancona in 2011, I think the Polish people, or may be others,
could be interested in organizing it.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.ea3.ehu.es
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
“Remember not only to say the right thing in the right place, but far
more difficult still, to leave unsaid the wrong thing at the tempting
moment.” - Benjamin Franklin (1706-1790)
--
1:09 p.m.
On Thu, 18 Feb 2010, Ignacio Diaz-Emparanza wrote:
BTW, Jack, will it be possible to have the second gretl conference
at
Ancona? You should decide that soon, because in case you prefer not to
do it in Ancona in 2011, I think the Polish people, or may be others,
could be interested in organizing it.
I was thinking about it. I think Ancona could be feasibile, but if there
are other candidates, like Torun, shifting Ancona to 2013 would be ok too.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
5327
days inactive
5334
days old
27 comments
6 participants
participants (6)
-
Allin Cottrell -
Hélio Guilherme -
Ignacio Diaz-Emparanza -
Riccardo (Jack) Lucchetti -
Sven Schreiber -
Talha Yalta