From svetosch@gmx.net Thu Jan  5 10:08:48 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] getting errors with pvalue-function 
Date: Thu, 05 Jan 2006 16:09:50 +0100
Message-ID: <43BD36BE.80601@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3499649903569918796=="

--===============3499649903569918796==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,
I stumbled over a problem with the pvalue-function in gretl, I suspect it could be related to the
fact that the German decimal separator is the comma, but see for yourself:
(This is about gretl 1.5.0 on a German Windows 2000.)

If I execute the exact command given on p.14 of the command reference in the following two-liner,

<script>
nulldata 10
genr p2 = pvalue(X, 3, 5.67)
</script>

I get the following error output:

<error>
gretl-Version 1.5.0
Aktuelle Session: 2006/01/05 15:57
? nulldata 10
periodicity: 1, maxobs: 10,
observations range: 1-10
? genr p2 = pvalue(X, 3, 5.67)
Syntax-Fehler in Befehlszeile

Error executing script: halting
> genr p2 = pvalue(X, 3, 5.67)
</error>

The same thing happens if I type 5,67 instead of 5.67.

Workaround: if instead I modify the script as follows,

<script>
nulldata 10
scalar x = 5.67
genr p2 = pvalue(X, 3, x)
</script>

then everything seems ok. (Ok also with a comma as in "scalar x = 5,67")

Any ideas, or better workarounds?
Thanks,
Sven


--===============3499649903569918796==--


From svetosch@gmx.net Thu Jan  5 10:30:30 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] binomial pvalue-function broken?
Date: Thu, 05 Jan 2006 16:31:31 +0100
Message-ID: <43BD3BD3.4040707@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2018922049767584073=="

--===============2018922049767584073==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi again,
here's another problem with the pvalue-function. This time the problem only (?) applies to the
binomial variant and thus looks different from the one in my previous post. But again, maybe some
underlying comma-vs.-period-as-decimal-and/or-list-separator issues?

The following little script demonstrates the first part of the problem:
<script>
nulldata 10
pvalue B 1 1 0
genr prob = pvalue(B, 1, 1, 0)
</script>

This gives me the following error output; note that the pvalue-command works fine, while the
pvalue-function fails:

<output>
...
? pvalue B 1 1 0

Binomial (p = 1, n = 1):
 Prob(x > 0) = 1
? genr prob = pvalue(B, 1, 1, 0)
Syntax-Fehler in Befehlszeile

Error executing script: halting
> genr prob = pvalue(B, 1, 1, 0)
</output>

And then there are cases where there are no error messages, but the result of the pvalue-function is
clearly wrong (in contrast to the output of the pvalue-command). Consider this script:

<script>
nulldata 10
scalar p = 0,5
scalar n = 2
scalar x = 1
pvalue B p n x
genr prob = pvalue(B, p, n, x)
</script>

which produces:
<output>
...
? pvalue B p n x

Binomial (p = 0,5, n = 2):
 Prob(x > 1) = 0,25
? genr prob = pvalue(B, p, n, x)
Generiert skalar prob (ID 5) = 0
</output>

I'd also be interested in a quick workaround, since I want to access the function return value for
teaching. The correct output from the pvalue-command doesn't help me there.

Tia for hints and suggestions,
Sven

--===============2018922049767584073==--


From svetosch@gmx.net Thu Jan  5 10:57:24 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] binomial pvalue-function broken?
Date: Thu, 05 Jan 2006 16:58:23 +0100
Message-ID: <43BD421F.6070107@gmx.net>
In-Reply-To: 43BD3BD3.4040707@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2328926607506738931=="

--===============2328926607506738931==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Sven Schreiber schrieb:
> Hi again,
> here's another problem with the pvalue-function. This time the problem only (?) applies to the
> binomial variant and thus looks different from the one in my previous post. But again, maybe some
> underlying comma-vs.-period-as-decimal-and/or-list-separator issues?
> 

Yes indeed: Not using the local decimal separator (Preferences-General, uncheck checkbox, and
restart) solves all my reported problems. (after replacing commas with periods where necessary, of
course)

So that's a workaround, and not too bad. In the medium term it would be good if gretl could use an
argument separator which is not used as a decimal separator somewhere in the world (semicolon?). If
that's feasible while maintaining some backward compatibility, I don't know.

Cheers,
Sven



--===============2328926607506738931==--


From cottrell@wfu.edu Thu Jan  5 13:26:29 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] binomial pvalue-function broken?
Date: Thu, 05 Jan 2006 13:26:29 -0500
Message-ID: <Pine.LNX.4.64.0601051318530.13229@ricardo.ecn.wfu.edu>
In-Reply-To: 43BD421F.6070107@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8880067936120236370=="

--===============8880067936120236370==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, 5 Jan 2006, Sven Schreiber wrote:

> Yes indeed: Not using the local decimal separator 
> (Preferences-General, uncheck checkbox, and restart) solves all my 
> reported problems. (after replacing commas with periods where 
> necessary, of course)
>
> So that's a workaround, and not too bad. In the medium term it 
> would be good if gretl could use an argument separator which is 
> not used as a decimal separator somewhere in the world 
> (semicolon?). If that's feasible while maintaining some backward 
> compatibility, I don't know.

Thanks for tracking down the problem.  I'll see if I can come up 
with something to solve this.  Here's an initial thought.  Right 
now, all the spaces are squeezed out of "genr" formulas in an early 
stage of processing, because white space carries no meaning in that 
context.  What if we made spaces following commas significant, when 
the decimal separator is a comma?  That is, in such locales you 
could write, e.g., "(1,5, 2,3)" and have it read as "one-point-five, 
two-point-three".

Allin Cottrell

--===============8880067936120236370==--


From jack@deanovell.unian.it Thu Jan  5 14:00:36 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] binomial pvalue-function broken?
Date: Thu, 05 Jan 2006 20:00:42 +0100
Message-ID: <Pine.LNX.4.44.0601051955110.12209-100000@ec-4.econ.univpm.it>
In-Reply-To: Pine.LNX.4.64.0601051318530.13229@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5370692910833266016=="

--===============5370692910833266016==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Thu, 5 Jan 2006, Allin Cottrell wrote:

> On Thu, 5 Jan 2006, Sven Schreiber wrote:
>
> > Yes indeed: Not using the local decimal separator
> > (Preferences-General, uncheck checkbox, and restart) solves all my
> > reported problems. (after replacing commas with periods where
> > necessary, of course)
> >
> > So that's a workaround, and not too bad. In the medium term it
> > would be good if gretl could use an argument separator which is
> > not used as a decimal separator somewhere in the world
> > (semicolon?). If that's feasible while maintaining some backward
> > compatibility, I don't know.
>
> Thanks for tracking down the problem.  I'll see if I can come up
> with something to solve this.  Here's an initial thought.  Right
> now, all the spaces are squeezed out of "genr" formulas in an early
> stage of processing, because white space carries no meaning in that
> context.  What if we made spaces following commas significant, when
> the decimal separator is a comma?  That is, in such locales you
> could write, e.g., "(1,5, 2,3)" and have it read as "one-point-five,
> two-point-three".

My humble opinion is that any decimal seprator other than "." is EVIL;
being in a country where the traditional decimal separator is "," and "."
is reserved for thousands, I can tell you that the potential for confusion
is immense, to the point of making the CSV format nearly useless. If we
allow commas as separators in scripts depending on the locale setting,
portability becomes a nightmare.


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============5370692910833266016==--


From cottrell@wfu.edu Thu Jan  5 14:51:20 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] binomial pvalue-function broken?
Date: Thu, 05 Jan 2006 14:51:19 -0500
Message-ID: <Pine.LNX.4.64.0601051443170.13229@ricardo.ecn.wfu.edu>
In-Reply-To: Pine.LNX.4.44.0601051955110.12209-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2947411645505384849=="

--===============2947411645505384849==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, 5 Jan 2006, jack wrote:

> My humble opinion is that any decimal seprator other than "." is 
> EVIL; being in a country where the traditional decimal separator 
> is "," and "." is reserved for thousands, I can tell you that the 
> potential for confusion is immense, to the point of making the CSV 
> format nearly useless. If we allow commas as separators in scripts 
> depending on the locale setting, portability becomes a nightmare.

I tend to agree with this.  I think it's OK to display results using 
',' as decimal separator but we should standardize on '.' for script 
input.

Part of Sven's point, though, was that even when he used '.', 
gretl's localization screwed him up.

Here's idea number 2.  We rigorously enforce the use of '.' as 
decimal separator for "genr" and friends, and I work on ensuring 
that -- even if the "locale decimal separator" option is selected in 
gretl -- within the genr context ',' is always treated as an 
argument separator and never as decimal separator.

This would have to be made clear in the manual too.

Allin Cottrell

--===============2947411645505384849==--


From cottrell@wfu.edu Thu Jan  5 15:28:50 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] pvalue function and decimal separator
Date: Thu, 05 Jan 2006 15:28:49 -0500
Message-ID: <Pine.LNX.4.64.0601051525120.13229@ricardo.ecn.wfu.edu>
In-Reply-To: 43BD421F.6070107@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7253695071763784122=="

--===============7253695071763784122==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, 5 Jan 2006, Sven Schreiber wrote:

> So that's a workaround, and not too bad. In the medium term it 
> would be good if gretl could use an argument separator which is 
> not used as a decimal separator somewhere in the world 
> (semicolon?). If that's feasible while maintaining some backward 
> compatibility, I don't know.

I think this issue is fixed in gretl CVS (and the current Windows 
snapshot).  It's advisable to use '.' for the decimal separator with 
the genr command, but gretl will try to spot a decimal ',' and 
replace it with '.' internally.

Allin Cottrell


--===============7253695071763784122==--


From f_bresson@yahoo.fr Thu Jan  5 17:22:25 2006
From: Florent Bresson <f_bresson@yahoo.fr>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] importing data
Date: Thu, 05 Jan 2006 23:22:20 +0100
Message-ID: <20060105222220.36680.qmail@web26803.mail.ukl.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0733325969344724055=="

--===============0733325969344724055==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I really have problems to import data in gretl. I red
the manual and respected the folowing contraint for
CSV files
- NA string for missing values (I also tried with
blank cells and single dots)
- header with no more than height characterters
- no number in the headers, no space
- no header for the column of observations code
I tries with different data files, with xls and dta
files. Gretl always reply that he can't open the file.
So what's the problem ?


=09

=09
	=09
___________________________________________________________________________=20
Nouveau : t=C3=A9l=C3=A9phonez moins cher avec Yahoo! Messenger ! D=C3=A9couv=
ez les tarifs exceptionnels pour appeler la France et l'international.
T=C3=A9l=C3=A9chargez sur http://fr.messenger.yahoo.com


--===============0733325969344724055==--


From cottrell@wfu.edu Thu Jan  5 20:58:36 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] comma as decimal separator: clarification
Date: Thu, 05 Jan 2006 20:58:35 -0500
Message-ID: <Pine.LNX.4.64.0601052029500.16728@ricardo.ecn.wfu.edu>
In-Reply-To: Pine.LNX.4.64.0601051318530.13229@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2375381796249208235=="

--===============2375381796249208235==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

I've just clarified this in my own mind, so I'll make a brief 
posting here, and try to add something along these lines in the 
manual soon.

1. In computing the value returned by a "genr" formula, by design 
gretl forces all numeric strings into the "C" numeric locale, where 
'.' is the decimal separator, for internal manipulation.  However, 
this was not done with full consistency, with the results that Sven 
noted.  I think this is now consistent.

2. As part of the "pre-processing" of a genr string, two things are 
done: (a) all spaces are squeezed out; and (b) if the current locale 
has ',' as decimal deparator, all commas that appear between two 
digits are replaced by '.'s.  For the most part this works OK.  For 
example (user input on the left, processed version on the right):

genr x = 0,5        -> genr x=0.5
genr x = 0,25 * 0,3 -> genr x=0.25*0.3

3. But the case Sven noted did not work:

genr x = pvalue(X, 3, 5.67) -> genr x = pvalue(X,3.5.67)

The pre-processed string contains a syntax error.

4. I've now modified the space-squeezing routine: a space that 
immediately follows a comma is not removed.  Thus, when the rule 
"replace commas between digits with '.'" is applied, it should not 
break things like these pvalue arguments:

genr x = pvalue(X, 3, 5.67) -> genr x=pvalue(X, 3, 5.67)
genr x = pvalue(X, 3, 5,67) -> genr x=pvalue(X, 3, 5.67)

5. So this should be the situation: (a) Regardless of locale, you 
should be able to use '.' as decimal separator in genr formulae; (b) 
if you use ',' as decimal separator this should be OK too, with the 
qualification that you have to make sure to leave a space after an
argument-separating comma in the case of numeric arguments, as in 
the pvalue function.

If anyone spots any remaining problems in this area, please let me 
know.

Allin Cottrell





--===============2375381796249208235==--


From svetosch@gmx.net Fri Jan  6 04:27:02 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] importing data
Date: Fri, 06 Jan 2006 10:27:58 +0100
Message-ID: <43BE381E.2080001@gmx.net>
In-Reply-To: 20060105222220.36680.qmail@web26803.mail.ukl.yahoo.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7449653436133759303=="

--===============7449653436133759303==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Florent Bresson schrieb:
> I really have problems to import data in gretl. I red
> the manual and respected the folowing contraint for
> CSV files
> - NA string for missing values (I also tried with
> blank cells and single dots)
> - header with no more than height characterters
> - no number in the headers, no space
> - no header for the column of observations code
> I tries with different data files, with xls and dta
> files. Gretl always reply that he can't open the file.
> So what's the problem ?

Could you include a small example file to reproduce your problem?

--===============7449653436133759303==--


From jack@deanovell.unian.it Fri Jan  6 04:28:35 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] comma as decimal separator: clarification
Date: Fri, 06 Jan 2006 10:28:42 +0100
Message-ID: <Pine.LNX.4.44.0601061004210.15208-100000@ec-4.econ.univpm.it>
In-Reply-To: Pine.LNX.4.64.0601052029500.16728@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7809694527267456556=="

--===============7809694527267456556==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Thu, 5 Jan 2006, Allin Cottrell wrote:

> 5. So this should be the situation: (a) Regardless of locale, you
> should be able to use '.' as decimal separator in genr formulae; (b)
> if you use ',' as decimal separator this should be OK too, with the
> qualification that you have to make sure to leave a space after an
> argument-separating comma in the case of numeric arguments, as in
> the pvalue function.
>
> If anyone spots any remaining problems in this area, please let me
> know.

Sorry everyone to be a spoilsport, but I am rather against the new setup.
If we allow locale-dependent decimal separators in scripts, then a syntax
like

genr y = 0,5*x

becomes legal. Now imagine the previous line is buried in a 200-line
script. Then, anyone using the script in a "decimal point" locale sees
the script not working. Chances are, they conclude gretl is broken.

For now it's totally hypothetic to assume that anyone would want to run a
gretl script without checking it beforehand, but hopefully he possibility
of setting up a repository of gretl recipes based on scripts is not
unrealistic for the future. In this situation, we CANNOT ask casual users
to scan scripts file in the hunt for commas.

Spreadsheets can OUTPUT figures according to locale, and you can write
formulas according to locale (in fact you have to), but the internal
reprsentation of the formula is unique, so the same, say, xls file
automagically displays commas in Italy and points in the UK. But this
works because the user doesn't have access to the internal representation
of the data.

In the case of script, I see no easy way out of this. The simplest thing
that comes to my mind now is some sort of filter that examines the script
before running it, automatic replacing "decimal commas" (but not
"separator commas") with points. Such a scheme would introduce great
complication and great potential for ambiguity.

OTOH, what do we gain by allowing locale-dependent decimal separators? If
you ask me, very little, too little. But this is open source, right? So,
I'm all for democracy (except whatever Allin decides is OK -- 1st
Marxist sovereign in history). What do others think?


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============7809694527267456556==--


From svetosch@gmx.net Fri Jan  6 04:43:57 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] comma as decimal separator: clarification
Date: Fri, 06 Jan 2006 10:45:01 +0100
Message-ID: <43BE3C1D.6070002@gmx.net>
In-Reply-To: Pine.LNX.4.64.0601052029500.16728@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5384478011229562081=="

--===============5384478011229562081==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:


> 
> 5. So this should be the situation: (a) Regardless of locale, you should
> be able to use '.' as decimal separator in genr formulae; (b) if you use
> ',' as decimal separator this should be OK too, with the qualification
> that you have to make sure to leave a space after an
> argument-separating comma in the case of numeric arguments, as in the
> pvalue function.
> 

I also view (a) as essential, thanks for addressing this problem so quickly. However, with  respect
to (b), Jack's and your point are very valid, double definitions of commas as two types of
separators could become very difficult to handle. For example, isn't it ok to write "2." in many
languages for floating-point-two? But "2," couldn't be allowed. It probably becomes pretty messy
quickly.

So maybe gretl should simply drop locale support in scripts. Personally as a user, I wouldn't really
mind, and it seems to me that all (?) programming languages do that.

That way there's more time for developers to work on econometric features instead ;-)

Just imho of course.
Cheers,
Sven

--===============5384478011229562081==--


From svetosch@gmx.net Fri Jan  6 06:13:50 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Re: importing data
Date: Fri, 06 Jan 2006 12:14:53 +0100
Message-ID: <43BE512D.9030006@gmx.net>
In-Reply-To: 20060106105309.54586.qmail@web26803.mail.ukl.yahoo.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5385635553556192736=="

--===============5385635553556192736==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

[btw, you've only replied to me, not to the list]

Florent Bresson schrieb:
> I send you a small csv file as exemple. It is tab
> delimited and commas are used for decimals. The csv
> has been produced with OpenOffice 2. Thanks for the
> help
> 

Well the import works for me... When commas are used for decimals, I think you need to enable
locale-setting (Preferences - General, obvious checkbox), and answer correctly to the import dialogs.

Another thing: It seems you have panel data. The way the csv file is imported, the panel structure
is screwed up, but I believe the error is with the input format, not with gretl. But I don't have
experience with that, so you need somebody else to help you with that.

good luck,
sven

--===============5385635553556192736==--


From f_bresson@yahoo.fr Fri Jan  6 07:40:17 2006
From: Florent Bresson <f_bresson@yahoo.fr>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Re: importing data
Date: Fri, 06 Jan 2006 13:40:12 +0100
Message-ID: <20060106124012.38744.qmail@web26807.mail.ukl.yahoo.com>
In-Reply-To: 43BE512D.9030006@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6851077062123199089=="

--===============6851077062123199089==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

It's strange but I found the reason of my problems.
The data that I tried to open was on a different
partition of my hard drive. When I copy the file on
the same partition as gretl, it works fine. Do oberve
the same phenomenon ?


--- Sven Schreiber <svetosch(a)gmx.net> a =C3=A9crit :

> [btw, you've only replied to me, not to the list]
>=20
> Florent Bresson schrieb:
> > I send you a small csv file as exemple. It is tab
> > delimited and commas are used for decimals. The
> csv
> > has been produced with OpenOffice 2. Thanks for
> the
> > help
> >=20
>=20
> Well the import works for me... When commas are used
> for decimals, I think you need to enable
> locale-setting (Preferences - General, obvious
> checkbox), and answer correctly to the import
> dialogs.
>=20
> Another thing: It seems you have panel data. The way
> the csv file is imported, the panel structure
> is screwed up, but I believe the error is with the
> input format, not with gretl. But I don't have
> experience with that, so you need somebody else to
> help you with that.
>=20
> good luck,
> sven
>=20



=09
=09
	=09
___________________________________________________________________________=20
Nouveau : t=C3=A9l=C3=A9phonez moins cher avec Yahoo! Messenger. Appelez le m=
onde entier =C3=A0 partir de 0,012 =C2=80/minute !=20
T=C3=A9l=C3=A9chargez sur http://fr.messenger.yahoo.com


--===============6851077062123199089==--


From f_bresson@yahoo.fr Fri Jan  6 08:01:49 2006
From: Florent Bresson <f_bresson@yahoo.fr>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Re: importing data
Date: Fri, 06 Jan 2006 14:01:48 +0100
Message-ID: <20060106130148.71340.qmail@web26808.mail.ukl.yahoo.com>
In-Reply-To: 43BE512D.9030006@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2144180118371762841=="

--===============2144180118371762841==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

In fact, it is not a question of partition. I have
found the solution. The problem was with the the
directory in which the file was located. The directory
was called "bases de donn=C3=A9es". I changed it into
"bases de donnees" and it works perfectly. The problem
was with the character "=C3=A9". It would be a good idea to
correct this in the next version of gretl

Florent Bresson


=09

=09
	=09
___________________________________________________________________________=20
Nouveau : t=C3=A9l=C3=A9phonez moins cher avec Yahoo! Messenger ! D=C3=A9couv=
ez les tarifs exceptionnels pour appeler la France et l'international.
T=C3=A9l=C3=A9chargez sur http://fr.messenger.yahoo.com


--===============2144180118371762841==--


From cottrell@wfu.edu Fri Jan  6 13:49:54 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] comma as decimal separator: clarification
Date: Fri, 06 Jan 2006 13:49:54 -0500
Message-ID: <Pine.LNX.4.64.0601061344330.26834@ricardo.ecn.wfu.edu>
In-Reply-To: Pine.LNX.4.44.0601061004210.15208-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3994863493182265074=="

--===============3994863493182265074==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Fri, 6 Jan 2006, jack wrote:

> Sorry everyone to be a spoilsport, but I am rather against the new 
> setup. If we allow locale-dependent decimal separators in scripts, 
> then a syntax like
>
> genr y = 0,5*x
>
> becomes legal. Now imagine the previous line is buried in a 
> 200-line script. Then, anyone using the script in a "decimal 
> point" locale sees the script not working. Chances are, they 
> conclude gretl is broken.

I've thought about a few more scenarios in relation to "genr" since 
my last posting, and I'm now inclined to agree -- there is too great 
a possibility of screw-ups.  I'll adjust genr so that it rejects 
commas other than when used as argument-separators, regardless of 
locale.

Allin Cottrell


--===============3994863493182265074==--


From cottrell@wfu.edu Fri Jan  6 14:04:26 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Re: importing data
Date: Fri, 06 Jan 2006 14:04:25 -0500
Message-ID: <Pine.LNX.4.64.0601061352530.26834@ricardo.ecn.wfu.edu>
In-Reply-To: 20060106130148.71340.qmail@web26808.mail.ukl.yahoo.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6733008910744705150=="

--===============6733008910744705150==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Fri, 6 Jan 2006, Florent Bresson wrote:

> In fact, it is not a question of partition. I have found the 
> solution. The problem was with the the directory in which the file 
> was located. The directory was called "bases de données". I 
> changed it into "bases de donnees" and it works perfectly. The 
> problem was with the character "é". It would be a good idea to 
> correct this in the next version of gretl

This is quite a ticklish issue.  Can you tell us, please, what 
version of gretl you're using, on what platform, and what your 
"locale" setting is (on Linux you can get that by running 
/usr/bin/locale)?  Thanks.

Allin Cottrell

--===============6733008910744705150==--


From cottrell@wfu.edu Fri Jan  6 16:09:08 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Re: importing data
Date: Fri, 06 Jan 2006 16:09:08 -0500
Message-ID: <Pine.LNX.4.64.0601061601160.26834@ricardo.ecn.wfu.edu>
In-Reply-To: 20060106130148.71340.qmail@web26808.mail.ukl.yahoo.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0816544597087036092=="

--===============0816544597087036092==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Fri, 6 Jan 2006, Florent Bresson wrote:

> In fact, it is not a question of partition. I have
> found the solution. The problem was with the the
> directory in which the file was located. The directory
> was called "bases de données". I changed it into
> "bases de donnees" and it works perfectly. The problem
> was with the character "é". It would be a good idea to
> correct this in the next version of gretl

Further info: I have tested with gretl 1.5.0 on Linux, using the 
locale en_US.ISO8859-1.  I'm able to open files files in a directory 
named "bases de données" OK.

I did discover one problem, however: when you open a CSV file, you 
get an auxiliary window with a report on the reading of the file. 
In the case of files located in "bases de données" this window came 
up blank, with an error message on the console saying that the text 
did not validate as utf8.  That's because the filename was being 
presented to GTK in the locale encoding.  This is now fixed in CVS.

Allin Cottrell

--===============0816544597087036092==--


From Ignacio.Diaz-Emparanza@ehu.es Sat Jan  7 06:01:05 2006
From: Ignacio =?utf-8?q?D=C3=ADaz-Emparanza?= <Ignacio.Diaz-Emparanza@ehu.es>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] comma as decimal separator: clarification
Date: Sat, 07 Jan 2006 12:00:51 +0100
Message-ID: <200601071200.52049.Ignacio.Diaz-Emparanza@ehu.es>
In-Reply-To: Pine.LNX.4.64.0601061344330.26834@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4444078101622890111=="

--===============4444078101622890111==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

El Viernes, 6 de Enero de 2006 19:49, Allin Cottrell escribió:
> On Fri, 6 Jan 2006, jack wrote:
> > Sorry everyone to be a spoilsport, but I am rather against the new
> > setup. If we allow locale-dependent decimal separators in scripts,
> > then a syntax like
> >
> > genr y = 0,5*x
> >
> > becomes legal. Now imagine the previous line is buried in a
> > 200-line script. Then, anyone using the script in a "decimal
> > point" locale sees the script not working. Chances are, they
> > conclude gretl is broken.
>
> I've thought about a few more scenarios in relation to "genr" since
> my last posting, and I'm now inclined to agree -- there is too great
> a possibility of screw-ups.  I'll adjust genr so that it rejects
> commas other than when used as argument-separators, regardless of
> locale.

Only for clarification with respect to the Spanish language: normally we use 
commas as decimal separators and points for thousands, but even the RAE 
(Royal Academy of Spanish Language) allows the "international use" of the 
point as decimal separator (suggesting in this case to use micro-spaces to 
separate thousands). So we have no much problem in using the decimal points 
in genr. In fact, in the statistics and econometrics fields we are very 
accostumed to use them.

-- 
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
http://www.bl.ehu.es/~etpdihei/


--===============4444078101622890111==--


From f_bresson@yahoo.fr Mon Jan  9 06:28:48 2006
From: Florent Bresson <f_bresson@yahoo.fr>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Re :importing data
Date: Mon, 09 Jan 2006 12:28:37 +0100
Message-ID: <20060109112837.78531.qmail@web26801.mail.ukl.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5145813043726830217=="

--===============5145813043726830217==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I'm using the 1.5.0 version on windows XP.

Florent Bresson

On Fri, 6 Jan 2006, Florent Bresson wrote:

> In fact, it is not a question of partition. I have
found the=20
> solution. The problem was with the the directory in
which the file=20
> was located. The directory was called "bases de
donn=C3=A9es". I=20
> changed it into "bases de donnees" and it works
perfectly. The=20
> problem was with the character "=C3=A9". It would be a
good idea to=20
> correct this in the next version of gretl

This is quite a ticklish issue.  Can you tell us,
please, what=20
version of gretl you're using, on what platform, and
what your=20
"locale" setting is (on Linux you can get that by
running=20
/usr/bin/locale)?  Thanks.

Allin Cottrell


=09

=09
	=09
___________________________________________________________________________=20
Nouveau : t=C3=A9l=C3=A9phonez moins cher avec Yahoo! Messenger ! D=C3=A9couv=
ez les tarifs exceptionnels pour appeler la France et l'international.
T=C3=A9l=C3=A9chargez sur http://fr.messenger.yahoo.com


--===============5145813043726830217==--


From zemlys@gmail.com Mon Jan  9 08:57:48 2006
From: Vaidotas Zemlys <zemlys@gmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] compiling 1.5.0 on Ubuntu Breezy fails
Date: Mon, 09 Jan 2006 15:57:42 +0200
Message-ID: <1136815063.9619.39.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5044361393464377351=="

--===============5044361393464377351==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,

I tried compiling gretl 1.5.0 on Ubuntu Breezy, and it failed:

make[1]: Entering directory `/home/mpiktas/src/gretl-1.5.0/cli'
mkdir .deps
gcc -c -g -O2 -I.. -I.. -I../lib/src  -DLOCALEDIR=
\"/usr/local/share/locale\" -DHAVE_CONFIG_H gretlcli.c
gcc -g -O2 -I.. -I.. -I../lib/src  -DLOCALEDIR=\"/usr/local/share/locale
\" -DHAVE_CONFIG_H -MM gretlcli.c > .deps/gretlcli.d
gcc -c -g -O2 -I.. -I.. -I../lib/src  -DLOCALEDIR=
\"/usr/local/share/locale\" -DHAVE_CONFIG_H complete.c
gcc -g -O2 -I.. -I.. -I../lib/src  -DLOCALEDIR=\"/usr/local/share/locale
\" -DHAVE_CONFIG_H -MM complete.c > .deps/complete.d
../libtool --mode=link gcc -o gretlcli gretlcli.o
complete.o ../lib/libgretl-1.0.la -lreadline -ltermcap
mkdir .libs
gcc -o .libs/gretlcli gretlcli.o
complete.o  ../lib/.libs/libgretl-1.0.so -L/usr/lib -llapack
-lblas /usr/lib/libgfortran.so -L/usr/local/lib /usr/lib/libxml2.so -ldl
-lz -lm /usr/lib/libglib-2.0.so /usr/lib/libgmp.so -lreadline -ltermcap
-Wl,--rpath -Wl,/usr/local/lib
../lib/.libs/libgretl-1.0.so: undefined reference to `e_wsfe'
../lib/.libs/libgretl-1.0.so: undefined reference to `s_cmp'
../lib/.libs/libgretl-1.0.so: undefined reference to `do_fio'
../lib/.libs/libgretl-1.0.so: undefined reference to `s_cat'
../lib/.libs/libgretl-1.0.so: undefined reference to `s_stop'
../lib/.libs/libgretl-1.0.so: undefined reference to `s_wsfe'
../lib/.libs/libgretl-1.0.so: undefined reference to `s_copy'
collect2: ld returned 1 exit status
make[1]: *** [gretlcli] Error 1
make[1]: Leaving directory `/home/mpiktas/src/gretl-1.5.0/cli'
make: *** [cli] Error 2

Any ideas? ./configure did not find any problems. If aditional
information is needed, feel free to ask.

Vaidotas Zemlys


--===============5044361393464377351==--


From zemlys@gmail.com Mon Jan  9 11:28:37 2006
From: Vaidotas Zemlys <zemlys@gmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Re: compiling 1.5.0 on Ubuntu Breezy fails
Date: Mon, 09 Jan 2006 18:28:32 +0200
Message-ID: <fcb463950601090828u14c5bdabp3f4505f4ce4aa483@mail.gmail.com>
In-Reply-To: 1136815063.9619.39.camel@localhost.localdomain
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1325395292576569233=="

--===============1325395292576569233==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,

On 1/9/06, Vaidotas Zemlys <zemlys(a)gmail.com> wrote:
> Hi,
>
> I tried compiling gretl 1.5.0 on Ubuntu Breezy, and it failed:
>
> <..skipped>
>

I googled a bit about such problems, and found out that it is
something related to blas and lapack not finding some functions (I am
not an expert, so I can not explain clearer). I fixed the problem, by
adding -lg2c to LAPACK_LIBS in Makefile, residing in lib directory.
Then everything went ok. I only had to fiddle a bit, for syntax
highlighting to work. Copied by hand gretl.lang file to apropriate
location, also copied mime information and it started working for now.

Vaidotas Zemlys


--===============1325395292576569233==--


From cottrell@wfu.edu Mon Jan  9 12:19:58 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Re: compiling 1.5.0 on Ubuntu Breezy fails
Date: Mon, 09 Jan 2006 12:19:58 -0500
Message-ID: <Pine.LNX.4.64.0601091217560.29870@ricardo.ecn.wfu.edu>
In-Reply-To: fcb463950601090828u14c5bdabp3f4505f4ce4aa483@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9098055824266835672=="

--===============9098055824266835672==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Mon, 9 Jan 2006, Vaidotas Zemlys wrote:

>> I tried compiling gretl 1.5.0 on Ubuntu Breezy, and it failed:
>>
>> <..skipped>
>>
>
> I googled a bit about such problems, and found out that it is
> something related to blas and lapack not finding some functions (I am
> not an expert, so I can not explain clearer). I fixed the problem, by
> adding -lg2c to LAPACK_LIBS in Makefile, residing in lib directory.
> Then everything went ok. I only had to fiddle a bit, for syntax
> highlighting to work. Copied by hand gretl.lang file to apropriate
> location, also copied mime information and it started working for now.

Thanks for the follow-up.  I was going to suggest that the problem 
seemed to be a missing link to libf2c or libg2c.  I'll try to 
investigate what's going on with configure.

Allin Cottrell

--===============9098055824266835672==--


From zemlys@gmail.com Tue Jan 10 02:41:41 2006
From: Vaidotas Zemlys <zemlys@gmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Re: compiling 1.5.0 on Ubuntu Breezy fails
Date: Tue, 10 Jan 2006 09:41:34 +0200
Message-ID: <1136878894.9025.3.camel@localhost.localdomain>
In-Reply-To: Pine.LNX.4.64.0601091217560.29870@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6531816478279896178=="

--===============6531816478279896178==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Pr, 2006 01 09 12:19 -0500, Allin Cottrell rašė:
> On Mon, 9 Jan 2006, Vaidotas Zemlys wrote:
> 
> >> I tried compiling gretl 1.5.0 on Ubuntu Breezy, and it failed:
> >>
> >> <..skipped>
> >>
> >
> > I googled a bit about such problems, and found out that it is
> > something related to blas and lapack not finding some functions (I am
> > not an expert, so I can not explain clearer). I fixed the problem, by
> > adding -lg2c to LAPACK_LIBS in Makefile, residing in lib directory.
> > Then everything went ok. I only had to fiddle a bit, for syntax
> > highlighting to work. Copied by hand gretl.lang file to apropriate
> > location, also copied mime information and it started working for now.
> 
> Thanks for the follow-up.  I was going to suggest that the problem 
> seemed to be a missing link to libf2c or libg2c.  I'll try to 
> investigate what's going on with configure.
> 

Since I did not find gretl's debian package maintainer complaints about
compiling (and gretl 1.5.0 is in debian unstable), I suspect that this
maybe the issue with Ubuntu Breezy. So this problem will probably
disappear, with new Ubuntu release, which will be in April.

Vaidotas Zemlys



--===============6531816478279896178==--


From svetosch@gmx.net Tue Jan 10 12:52:23 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] questions about translation details
Date: Tue, 10 Jan 2006 18:53:24 +0100
Message-ID: <43C3F494.6030508@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8807306927962666820=="

--===============8807306927962666820==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Ok, I have just done my first cvs commit (de.po) to see whether from that minute on gretl will stop
working ;-)

No seriously, before I can translate larger chunks I have some questions, because I very much
realize that I am a novice at program translation.

1) actually unrelated to translation: could it be that some menu shortcuts are doubly defined in
English gretl? Like "user's guide" and "check for updates" both receiving the u-shortcut in the help
window. (I presume lower or uppercase is irrelevant, right?)

2) Speaking about menu shortcuts, what letter to choose for menu shortcuts in the translations? Is
there a rule, or am I free to choose whatever I like? (Related info: It seems that in the existing
translation in some cases there is a shortcut in English, but not in the corresponding German string.)

3) Is it really necessary to "translate" menu separators appearing as strings? Or could they even be
marked as not requiring translation in the sources?

4) To test out the effect of the changes without building myself, are the changes automatically
included in the windows snapshot http://ricardo.ecn.wfu.edu/pub/gretl/gretl_install.exe? At what
interval is the snapshot brought up to date?

5) In the de.po file it says something about project id gretl 1.3.0.1, which sounds outdated.
Something I can/should change?

Thanks much for your help,
cheers, Sven

--===============8807306927962666820==--


From cottrell@wfu.edu Tue Jan 10 23:03:59 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] questions about translation details
Date: Tue, 10 Jan 2006 23:03:58 -0500
Message-ID: <Pine.LNX.4.64.0601102253050.9273@ricardo.ecn.wfu.edu>
In-Reply-To: 43C3F494.6030508@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8829202614880094372=="

--===============8829202614880094372==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, 10 Jan 2006, Sven Schreiber wrote:

> Ok, I have just done my first cvs commit (de.po) to see whether 
> from that minute on gretl will stop working ;-)

Looks good so far!

> 1) actually unrelated to translation: could it be that some menu 
> shortcuts are doubly defined in English gretl? Like "user's guide" 
> and "check for updates" both receiving the u-shortcut in the help 
> window. (I presume lower or uppercase is irrelevant, right?)

Quite possible.  I'll try checking that.

> 2) Speaking about menu shortcuts, what letter to choose for menu 
> shortcuts in the translations? Is there a rule, or am I free to 
> choose whatever I like?

If there's a rule, I'm not aware of it -- other than, try to choose 
the most standard option (used in most other software), if there is 
any standard option for the menu item in question.

> 3) Is it really necessary to "translate" menu separators appearing 
> as strings? Or could they even be marked as not requiring 
> translation in the sources?

Yes, that seems stupid.  I'll see if I can fix it.

> 4) To test out the effect of the changes without building myself, 
> are the changes automatically included in the windows snapshot 
> http://ricardo.ecn.wfu.edu/pub/gretl/gretl_install.exe? At what 
> interval is the snapshot brought up to date?

Yes, .po changes automatically go into the snapshot. As for the 
timing of updates, this is somewhat irregular.  Basically it's 
matter of: Is there something new that is worthwhile, or a 
significant bugfix?  (If yes, then make a snapshot.)  Is there 
something experimental going on in CVS which is liable to produce a 
broken binary?  (If yes, then don't make a snapshot.)

Right now there is experimental stuff going on (we're adding the 
facility to define and manipulate matrices), but I don't think any
existing functionality is broken so I'll make a new Windows 
snapshot tomorrow, Jan 11.

> 5) In the de.po file it says something about project id gretl 
> 1.3.0.1, which sounds outdated. Something I can/should change?

Yes, I believe you're free to change that identifier to "1.5.0".

Thanks for your work on this!

Allin Cottrell

--===============8829202614880094372==--


From masa4u@gmail.com Tue Jan 10 23:12:46 2006
From: Seung Hun Han <masa4u@gmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Convergence is not met
Date: Wed, 11 Jan 2006 13:12:43 +0900
Message-ID: <4357bb540601102012h3e121512v3a13616669fa0733@mail.gmail.com>
Content-Type: multipart/mixed; boundary="===============6706625926640114831=="

--===============6706625926640114831==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGRpdj53aGVuIGkgZXN0aW1hdGUgdGhlIGdhcmNoIHBhcmFtZXRlciBvZiBjaiBzdG9jayBwcmlj
ZSBkdXJpbmcgMSB5ZWFyIGRhdGEgdXNpbmcgZ3JldGwgYW5kIFIuPC9kaXY+CjxkaXY+Jm5ic3A7
PC9kaXY+CjxkaXY+CjxkaXY+SU4gR251LVIuPC9kaXY+CjxkaXY+Jmd0OyBnYXJjaCh4LGMoMSwx
KSk8L2Rpdj4KPHA+Jm5ic3A7KioqKiogRVNUSU1BVElPTiBXSVRIIEFOQUxZVElDQUwgR1JBRElF
TlQgKioqKio8L3A+CjxwPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSSZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBJTklUSUFMIFgoSSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgRChJKTwvcD4KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgMC4zODkyNTlFLTAzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAu
MTAwRSswMTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAwLjUwMDAwMEUtMDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMC4xMDBFKzAxPGJyPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuNTAwMDAw
RS0wMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwLjEwMEUrMDE8L3A+CjxwPiZuYnNwOyZuYnNw
OyZuYnNwOyBJVCZuYnNwOyZuYnNwOyBORiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBGJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJFTERGJm5i
c3A7Jm5ic3A7Jm5ic3A7IFBSRUxERiZuYnNwOyZuYnNwOyZuYnNwOyBSRUxEWCZuYnNwOyZuYnNw
OyBTVFBQQVImbmJzcDsmbmJzcDsgRCpTVEVQJm5ic3A7Jm5ic3A7IE5QUkVMREY8L3A+CjxwPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwJm5ic3A7Jm5ic3A7Jm5ic3A7IDEgLTAuODMwRSswMzxi
cj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyA4IC0wLjgzMEUr
MDMmbmJzcDsgMC40M0UtMDYmbmJzcDsgMC45NUUtMDYmbmJzcDsgMC4xRS0wNCZuYnNwOyAwLjhF
KzA5Jm5ic3A7IDAuMUUtMDUmbmJzcDsgMC4zNkUrMDM8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IDImbmJzcDsmbmJzcDsgMTggLTAuODMxRSswMyZuYnNwOyAwLjEzRS0wMiZuYnNwOyAwLjIy
RS0wMiZuYnNwOyAwLjVFKzAwJm5ic3A7IDAuMkUrMDEmbmJzcDsgMC4xRSswMCZuYnNwOyAwLjIw
RSswMDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMyZuYnNwOyZuYnNwOyAyMSAtMC44MzVF
KzAzJm5ic3A7IDAuNDhFLTAyCiZuYnNwOyAwLjQzRS0wMiZuYnNwOyAwLjdFKzAwJm5ic3A7IDAu
MUUrMDEmbmJzcDsgMC40RSswMCZuYnNwOyAwLjYzRS0wMTxicj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgNCZuYnNwOyZuYnNwOyAyMyAtMC44MzZFKzAzJm5ic3A7IDAuMTlFLTAyJm5ic3A7IDAu
MTNFLTAyJm5ic3A7IDAuNEUtMDEmbmJzcDsgMC4yRSswMSZuYnNwOyAwLjRFLTAxJm5ic3A7IDAu
ODBFLTAxPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA1Jm5ic3A7Jm5ic3A7IDI2IC0wLjgz
OUUrMDMmbmJzcDsgMC4yN0UtMDImbmJzcDsgMC4zMUUtMDImbmJzcDsgMC45RS0wMSZuYnNwOyAw
LjJFKzAxJm5ic3A7IDAuMUUrMDAmbmJzcDsgMC4xM0UrMDE8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IDYmbmJzcDsmbmJzcDsgMjcgLQowLjgzOUUrMDMmbmJzcDsgMC44OEUtMDMmbmJzcDsg
MC4yNkUtMDImbmJzcDsgMC44RS0wMSZuYnNwOyAwLjJFKzAxJm5ic3A7IDAuMUUrMDAmbmJzcDsg
MC4zMUUrMDA8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDcmbmJzcDsmbmJzcDsgMzYgLTAu
ODQwRSswMyZuYnNwOyAwLjUwRS0wMyZuYnNwOyAwLjEyRS0wMiZuYnNwOyAwLjZFLTA1Jm5ic3A7
IDAuNEUrMDEmbmJzcDsgMC44RS0wNSZuYnNwOyAwLjc0RS0wMjxicj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgOCZuYnNwOyZuYnNwOyAzNyAtMC44NDBFKzAzJm5ic3A7IDAuMjlFLTA0Jm5ic3A7
IDAuMjhFLTA0Jm5ic3A7IDAuNUUtMDUmbmJzcDsgMC4yRSswMSZuYnNwOyAwLjhFLTA1CiZuYnNw
OyAwLjM3RS0wMjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOSZuYnNwOyZuYnNwOyAzOCAt
MC44NDBFKzAzJm5ic3A7IDAuMzZFLTA2Jm5ic3A7IDAuMThFLTA1Jm5ic3A7IDAuNUUtMDUmbmJz
cDsgMC4yRSswMSZuYnNwOyAwLjhFLTA1Jm5ic3A7IDAuMzVFLTAyPGJyPiZuYnNwOyZuYnNwOyZu
YnNwOyAxMCZuYnNwOyZuYnNwOyA0NiAtMC44NDFFKzAzJm5ic3A7IDAuMTFFLTAyJm5ic3A7IDAu
MTlFLTAyJm5ic3A7IDAuNUUtMDEmbmJzcDsgMC44RSswMCZuYnNwOyAwLjdFLTAxJm5ic3A7IDAu
MzVFLTAyPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAxMSZuYnNwOyZuYnNwOyA0OCAtMC44NDNFKzAz
Jm5ic3A7IDAuMjJFLTAyJm5ic3A7IDAuMjJFLTAyCiZuYnNwOyAwLjRFLTAxJm5ic3A7IDAuOUUr
MDAmbmJzcDsgMC43RS0wMSZuYnNwOyAwLjE1RS0wMTxicj4mbmJzcDsmbmJzcDsmbmJzcDsgMTIm
bmJzcDsmbmJzcDsgNTAgLTAuODQ2RSswMyZuYnNwOyAwLjQxRS0wMiZuYnNwOyAwLjQ2RS0wMiZu
YnNwOyAwLjdFLTAxJm5ic3A7IDAuMUUrMDEmbmJzcDsgMC4xRSswMCZuYnNwOyAwLjczRS0wMTxi
cj4mbmJzcDsmbmJzcDsmbmJzcDsgMTMmbmJzcDsmbmJzcDsgNTIgLTAuODQ3RSswMyZuYnNwOyAw
LjE0RS0wMiZuYnNwOyAwLjE5RS0wMiZuYnNwOyAwLjJFLTAxJm5ic3A7IDAuMkUrMDEmbmJzcDsg
MC41RS0wMSZuYnNwOyAwLjExRS0wMTxicj4mbmJzcDsmbmJzcDsmbmJzcDsgMTQmbmJzcDsmbmJz
cDsgNTMgLTAuODQ4RSswMwombmJzcDsgMC4xNEUtMDImbmJzcDsgMC4xNkUtMDImbmJzcDsgMC4y
RS0wMSZuYnNwOyAwLjJFKzAxJm5ic3A7IDAuNUUtMDEmbmJzcDsgMC4xMEUtMDE8YnI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7IDE1Jm5ic3A7Jm5ic3A7IDU1IC0wLjg0OUUrMDMmbmJzcDsgMC4yM0UtMDMm
bmJzcDsgMC4yOUUtMDMmbmJzcDsgMC4zRS0wMiZuYnNwOyAwLjJFKzAxJm5ic3A7IDAuNUUtMDIm
bmJzcDsgMC41N0UtMDI8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDE2Jm5ic3A7Jm5ic3A7IDU4IC0w
Ljg0OUUrMDMmbmJzcDsgMC45MEUtMDMmbmJzcDsgMC4xNUUtMDImbmJzcDsgMC4yRS0wMSZuYnNw
OyAwLjFFKzAxJm5ic3A7IDAuM0UtMDEmbmJzcDsgMC42N0UtMDIKPGJyPiZuYnNwOyZuYnNwOyZu
YnNwOyAxNyZuYnNwOyZuYnNwOyA2MCAtMC44NDlFKzAzJm5ic3A7IDAuNTVFLTA0Jm5ic3A7IDAu
MTNFLTAzJm5ic3A7IDAuNEUtMDImbmJzcDsgMC4xRSswMSZuYnNwOyAwLjFFLTAxJm5ic3A7IDAu
MjdFLTAzPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAxOCZuYnNwOyZuYnNwOyA2MiAtMC44NDlFKzAz
Jm5ic3A7IDAuMjRFLTA1Jm5ic3A7IDAuNTdFLTA1Jm5ic3A7IDAuOEUtMDMmbmJzcDsgMC44RSsw
MCZuYnNwOyAwLjJFLTAyJm5ic3A7IDAuOTFFLTA1PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAxOSZu
YnNwOyZuYnNwOyA2NCAtMC44NDlFKzAzJm5ic3A7IDAuMTFFLTA2Jm5ic3A7IDAuMjBFLTA1Jm5i
c3A7IDAuM0UtMDMKJm5ic3A7IDAuMUUrMDEmbmJzcDsgMC43RS0wMyZuYnNwOyAwLjMwRS0wNTxi
cj4mbmJzcDsmbmJzcDsmbmJzcDsgMjAmbmJzcDsmbmJzcDsgNjUgLTAuODQ5RSswMyZuYnNwOyAw
LjIzRS0wNiZuYnNwOyAwLjM4RS0wNiZuYnNwOyAwLjFFLTAzJm5ic3A7IDAuOUUrMDAmbmJzcDsg
MC4zRS0wMyZuYnNwOyAwLjY5RS0wNjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgMjEmbmJzcDsmbmJz
cDsgNzggLTAuODQ5RSswMyAtMC4yMEUtMTImbmJzcDsgMC40OEUtMTMmbmJzcDsgMC4xRS0xMyZu
YnNwOyAwLjJFKzA2Jm5ic3A7IDAuMkUtMTMmbmJzcDsgMC4yM0UtMDY8L3A+CjxwPiZuYnNwOyoq
KioqIEZBTFNFIENPTlZFUkdFTkNFICoqKioqPC9wPgo8cD4mbmJzcDtGVU5DVElPTiZuYnNwOyZu
YnNwOyZuYnNwOyAtMC44NDk0ODlFKzAzJm5ic3A7Jm5ic3A7IFJFTERYJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuMTE0RS0xMzxicj4mbmJzcDtGVU5DLiBFVkFM
UyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA3OCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHUkFELiBFVkFMUyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyAyMTxicj4mbmJzcDtQUkVMREYmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgMC40NzdFLTEzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5QUkVMREYm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMC4yMzFFLTA2PC9wPgo8cD4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgSSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGSU5BTCBYKEkp
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEQoSSkmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRyhJKTwvcD4KPHA+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsgMC4xNjc1NzBFLTA1
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuMTAwRSswMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAwLjE4OEUrMDQ8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDImbmJzcDsmbmJzcDsmbmJz
cDsgMC42MzAzOTlFLTAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuMTAwRSswMSZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyAwLjExM0UrMDE8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMm
bmJzcDsmbmJzcDsmbmJzcDsgMC45NDQ3MDdFKzAwJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAu
MTAwRSswMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwLjM2NEUrMDA8L3A+CjxwPjxicj5DYWxs
Ojxicj5nYXJjaCh4ID0geCwgb3JkZXIgPSBjKDEsIDEpKTwvcD4KPHA+Q29lZmZpY2llbnQocyk6
PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhMCZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhMSZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBiMTxicj4xLjY3NmUtMDYmbmJzcDsgNi4zMDRl
LTAyJm5ic3A7IDkuNDQ3ZS0wMTwvcD4KPHA+V2FybmluZyBtZXNzYWdlOjxicj5OQU5zLi4uIGlu
OiBzcXJ0KHByZWQkZSk8YnI+PC9wPgo8cD5idXQgaW4gZ3JldGw8L3A+CjxwPlRoZSBjb252ZXJn
ZW5jZSBjcml0ZXJpb24gd2FzIG5vdCBtZXQuPC9wPgo8cD5pIHJlYWQgcHJldmlvdXMgYXJ0aWNs
ZSAnY29udmVyZ2VuY2UgaXMgbm90IG1ldCcmbmJzcDsgYW5kIGkga25vdyB0d28gYXNzaXN0ZW5j
ZS48L3A+CjxwPmZpcnN0LiBJbmNsdWRlaW5nIHN1aXRhYmxlIGluZGVwZWRlbnQgdmFyaWFibGUu
Li48YnI+Jm5ic3A7IGJ1dCBpIGp1c3Qgd2FudCBhbmFseXNpcyBvbmx5IDI0NSBkYXRhIDxicj5z
ZWNvbmQgLiB0cmFuc2ZvbWF0aW9uPGJyPiZuYnNwOyB0aGlzIGRhdGEgYWxyZWFkeSBsb2ctZGlm
ZnJlbnRpYWwgdHJhbnNmb3JtYXRpb24uIGhvdyBjYW4gaSBzYXcgYSByZXN1bHQuIG5vdCBhZGp1
c3QgaW5jbHVkZWluZyB2YXJpYWJsZS4gCjwvcD4KPHA+dGhhbmsgdSBmb3IgcmVhZGluZyBteSBk
dW1iIG1haWwuIGkgd2FpdCB5b3Ugd2FydGggYW5zd2VyLi4uIF5eOzwvcD4KPHA+Jm5ic3A7PC9w
Pgo8cD4mbmJzcDs8L3A+CjxwPiZuYnNwOzwvcD4KPHA+Jm5ic3A7PC9wPgo8cD4mbmJzcDs8L3A+
CjxwPiZuYnNwOzwvcD48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4K
PGRpdj4KPHA+Jmx0Oz94bWwgdmVyc2lvbj0mcXVvdDsxLjAmcXVvdDsgZW5jb2Rpbmc9JnF1b3Q7
VVRGLTgmcXVvdDs/Jmd0Ozxicj4mbHQ7IURPQ1RZUEUgZ3JldGxkYXRhIFNZU1RFTSAmcXVvdDtn
cmV0bGRhdGEuZHRkJnF1b3Q7Jmd0OzwvcD4KPHA+Jmx0O2dyZXRsZGF0YSBuYW1lPSZxdW90O0NK
JnF1b3Q7IGZyZXF1ZW5jeT0mcXVvdDsxJnF1b3Q7IHN0YXJ0b2JzPSZxdW90OzEmcXVvdDsgZW5k
b2JzPSZxdW90OzI0NyZxdW90OyB0eXBlPSZxdW90O2Nyb3NzLXNlY3Rpb24mcXVvdDsmZ3Q7PGJy
PiZsdDt2YXJpYWJsZXMgY291bnQ9JnF1b3Q7MyZxdW90OyZndDs8YnI+Jmx0O3ZhcmlhYmxlIG5h
bWU9JnF1b3Q7cHJpY2UmcXVvdDsKPGJyPiZuYnNwO2xhYmVsPSZxdW90O1N0b2NrIFByaWNlJnF1
b3Q7PGJyPiZuYnNwO2Rpc3BsYXluYW1lPSZxdW90O1N0b2NrIFByaWNlJnF1b3Q7PGJyPi8mZ3Q7
PGJyPiZsdDt2YXJpYWJsZSBuYW1lPSZxdW90O1JldHVybiZxdW90Ozxicj4mbmJzcDtsYWJlbD0m
cXVvdDtSZXR1cm4mcXVvdDs8YnI+Jm5ic3A7ZGlzcGxheW5hbWU9JnF1b3Q7UmV0dXJuJnF1b3Q7
PGJyPi8mZ3Q7PGJyPiZsdDt2YXJpYWJsZSBuYW1lPSZxdW90O3gmcXVvdDsKPGJyPiZuYnNwO2xh
YmVsPSZxdW90O3g9b2JzJnF1b3Q7PGJyPi8mZ3Q7PGJyPiZsdDsvdmFyaWFibGVzJmd0Ozxicj4m
bHQ7b2JzZXJ2YXRpb25zIGNvdW50PSZxdW90OzI0NyZxdW90OyBsYWJlbHM9JnF1b3Q7ZmFsc2Um
cXVvdDsmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NjgzMDAgLTAuMDIyMjA3IDEgJmx0Oy9vYnMmZ3Q7PGJy
PiZsdDtvYnMmZ3Q7NjY4MDAgMC4wMDg5NDIgMiAmbHQ7L29icyZndDs8YnI+CiZsdDtvYnMmZ3Q7
Njc0MDAgLTAuMDA3NDQ2IDMgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NjY5MDAgMC4wMDc0
NDYgNCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs2NzQwMCAwLjAwNDQ0MSA1ICZsdDsvb2Jz
Jmd0Ozxicj4mbHQ7b2JzJmd0OzY3NzAwIC0wLjAxMDM5NCA2ICZsdDsvb2JzJmd0Ozxicj4mbHQ7
b2JzJmd0OzY3MDAwIDAuMDAwMDAwIDcgJmx0Oy9vYnMmZ3Q7PGJyPgombHQ7b2JzJmd0OzY3MDAw
IC0wLjAwMjk5MCA4ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY2ODAwIC0wLjAxNjYwNCA5
ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY1NzAwIC0wLjAwMTUyMyAxMCAmbHQ7L29icyZn
dDs8YnI+Jmx0O29icyZndDs2NTYwMCAwLjAwMDAwMCAxMSAmbHQ7L29icyZndDs8YnI+Jmx0O29i
cyZndDs2NTYwMCAtMC4wMDQ1ODQgMTIgJmx0Oy9vYnMmZ3Q7Cjxicj4mbHQ7b2JzJmd0OzY1MzAw
IDAuMDE4MjEwIDEzICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY2NTAwIDAuMDA0NTAxIDE0
ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY2ODAwIC0wLjAxMjA0OCAxNSAmbHQ7L29icyZn
dDs8YnI+Jmx0O29icyZndDs2NjAwMCAtMC4wMDc2MDUgMTYgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtv
YnMmZ3Q7NjU1MDAgMC4wMDAwMDAgMTcgJmx0Oy9vYnMmZ3Q7Cjxicj4mbHQ7b2JzJmd0OzY1NTAw
IC0wLjAwNDU5MSAxOCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs2NTIwMCAwLjAwMDAwMCAx
OSAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs2NTIwMCAtMC4wMDMwNzIgMjAgJmx0Oy9vYnMm
Z3Q7PGJyPiZsdDtvYnMmZ3Q7NjUwMDAgMC4wMTIyMzMgMjEgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtv
YnMmZ3Q7NjU4MDAgMC4wMTM1ODUgMjIgJmx0Oy9vYnMmZ3Q7Cjxicj4mbHQ7b2JzJmd0OzY2NzAw
IC0wLjAxNjYyOSAyMyAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs2NTYwMCAtMC4wMDkxODgg
MjQgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NjUwMDAgMC4wMDc2NjMgMjUgJmx0Oy9vYnMm
Z3Q7PGJyPiZsdDtvYnMmZ3Q7NjU1MDAgMC4wMDAwMDAgMjYgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtv
YnMmZ3Q7NjU1MDAgMC4wNDYyNDIgMjcgJmx0Oy9vYnMmZ3Q7Cjxicj4mbHQ7b2JzJmd0OzY4NjAw
IDAuMDE1OTA4IDI4ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY5NzAwIDAuMDE3MDcwIDI5
ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzcwOTAwIDAuMDAwMDAwIDMwICZsdDsvb2JzJmd0
Ozxicj4mbHQ7b2JzJmd0OzcwOTAwIDAuMDAwMDAwIDMxICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2Jz
Jmd0OzcwOTAwIDAuMDA4NDI3IDMyICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs3MTUwMCAw
LjAxNjY0NCAzMyAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs3MjcwMCAwLjAyNTc5OSAzNCAm
bHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs3NDYwMCAwLjAwNjY4MCAzNSAmbHQ7L29icyZndDs8
YnI+Jmx0O29icyZndDs3NTEwMCAtMC4wMDI2NjcgMzYgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMm
Z3Q7NzQ5MDAgMC4wNDMxMTYgMzcgJmx0Oy9vYnMmZ3Q7Cjxicj4mbHQ7b2JzJmd0Ozc4MjAwIC0w
LjAxMjg3MCAzOCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs3NzIwMCAwLjAxMDMwOSAzOSAm
bHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs3ODAwMCAtMC4wMTE2MDYgNDAgJmx0Oy9vYnMmZ3Q7
PGJyPiZsdDtvYnMmZ3Q7NzcxMDAgLTAuMDM2OTkyIDQxICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2Jz
Jmd0Ozc0MzAwIDAuMDI2NTYyIDQyICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs3NjMwMCAt
MC4wMTk4NTUgNDMgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzQ4MDAgLTAuMDA0MDE5IDQ0
ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0Ozc0NTAwIC0wLjAwNjczNCA0NSAmbHQ7L29icyZn
dDs8YnI+Jmx0O29icyZndDs3NDAwMCAtMC4wMDQwNjIgNDYgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtv
YnMmZ3Q7NzM3MDAgLTAuMDMzMTA2IDQ3ICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs3MTMw
MCAtMC4wMTU1NDggNDggJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzAyMDAgMC4wMTEzMzIg
NDkgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzEwMDAgMC4wMjUwMzYgNTAgJmx0Oy9vYnMm
Z3Q7PGJyPiZsdDtvYnMmZ3Q7NzI4MDAgLTAuMDA0MTI5IDUxICZsdDsvb2JzJmd0Ozxicj4mbHQ7
b2JzJmd0OzcyNTAwIC0wLjAyMDkwNyA1MiAmbHQ7L29icyZndDsKPGJyPiZsdDtvYnMmZ3Q7NzEw
MDAgMC4wMTY3NjAgNTMgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzIyMDAgLTAuMDIzODI3
IDU0ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzcwNTAwIC0wLjAxMTQxMiA1NSAmbHQ7L29i
cyZndDs8YnI+Jmx0O29icyZndDs2OTcwMCAtMC4wMTI5OTcgNTYgJmx0Oy9vYnMmZ3Q7PGJyPiZs
dDtvYnMmZ3Q7Njg4MDAgLTAuMDE5MDc2IDU3ICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs2
NzUwMCAwLjAyMTk3OSA1OCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs2OTAwMCAwLjAwMTQ0
OCA1OSAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs2OTEwMCAwLjAzMTM0MiA2MCAmbHQ7L29i
cyZndDs8YnI+Jmx0O29icyZndDs3MTMwMCAtMC4wMDk4NjYgNjEgJmx0Oy9vYnMmZ3Q7PGJyPiZs
dDtvYnMmZ3Q7NzA2MDAgLTAuMDE1NzAzIDYyICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs2
OTUwMCAtMC4wMDcyMjAgNjMgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NjkwMDAgLTAuMDEw
MTk3IDY0ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY4MzAwIDAuMDEwMTk3IDY1ICZsdDsv
b2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY5MDAwIDAuMDI5OTgxIDY2ICZsdDsvb2JzJmd0Ozxicj4m
bHQ7b2JzJmd0OzcxMTAwIDAuMDE2NzM3IDY3ICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs3
MjMwMCAwLjAwMDAwMCA2OCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs3MjMwMCAtMC4wMDI3
NzAgNjkgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzIxMDAgLTAuMDA2OTU5IDcwICZsdDsv
b2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzcxNjAwIDAuMDAwMDAwIDcxICZsdDsvb2JzJmd0Ozxicj4m
bHQ7b2JzJmd0OzcxNjAwIC0wLjAxMTIzNiA3MiAmbHQ7L29icyZndDsKPGJyPiZsdDtvYnMmZ3Q7
NzA4MDAgMC4wMDAwMDAgNzMgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzA4MDAgLTAuMDEx
MzY0IDc0ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzcwMDAwIC0wLjAzNzg1MCA3NSAmbHQ7
L29icyZndDs8YnI+Jmx0O29icyZndDs2NzQwMCAwLjAyNDkxMCA3NiAmbHQ7L29icyZndDs8YnI+
Jmx0O29icyZndDs2OTEwMCAtMC4wMDg3MjEgNzcgJmx0Oy9vYnMmZ3Q7Cjxicj4mbHQ7b2JzJmd0
OzY4NTAwIC0wLjAxNzY3NCA3OCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs2NzMwMCAtMC4w
MTk1MDUgNzkgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NjYwMDAgMC4wMjk4NTMgODAgJmx0
Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NjgwMDAgMC4wMzc1MjIgODEgJmx0Oy9vYnMmZ3Q7PGJy
PiZsdDtvYnMmZ3Q7NzA2MDAgMC4wMDAwMDAgODIgJmx0Oy9vYnMmZ3Q7Cjxicj4mbHQ7b2JzJmd0
OzcwNjAwIDAuMDA3MDU3IDgzICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzcxMTAwIDAuMDE2
NzM3IDg0ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzcyMzAwIDAuMDA4MjY1IDg1ICZsdDsv
b2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzcyOTAwIDAuMDA2ODM1IDg2ICZsdDsvb2JzJmd0Ozxicj4m
bHQ7b2JzJmd0OzczNDAwIDAuMDAwMDAwIDg3ICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs3
MzQwMCAtMC4wMTIzMzcgODggJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzI1MDAgMC4wMDAw
MDAgODkgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzI1MDAgLTAuMDA4MzEwIDkwICZsdDsv
b2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzcxOTAwIDAuMDExMDY1IDkxICZsdDsvb2JzJmd0Ozxicj4m
bHQ7b2JzJmd0OzcyNzAwIDAuMDA0MTE4IDkyICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs3
MzAwMCAtMC4wMDI3NDMgOTMgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzI4MDAgLTAuMDEx
MDUwIDk0ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzcyMDAwIDAuMDA5Njc1IDk1ICZsdDsv
b2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzcyNzAwIDAuMDAwMDAwIDk2ICZsdDsvb2JzJmd0Ozxicj4m
bHQ7b2JzJmd0OzcyNzAwIDAuMDE1MDE3IDk3ICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs3
MzgwMCAtMC4wMzE2NjEgOTggJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzE1MDAgMC4wMTkz
OTEgOTkgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzI5MDAgMC4wMTQ5NzYgMTAwICZsdDsv
b2JzJmd0Ozxicj4mbHQ7b2JzJmd0Ozc0MDAwIC0wLjAxMjIzNyAxMDEgJmx0Oy9vYnMmZ3Q7PGJy
PiZsdDtvYnMmZ3Q7NzMxMDAgMC4wMjk2NTIgMTAyICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZn
dDs3NTMwMCAtMC4wMDM5OTIgMTAzICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0Ozc1MDAwIDAu
MDE3MTg1IDEwNCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs3NjMwMCAtMC4wMDI2MjUgMTA1
ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0Ozc2MTAwIC0wLjAwNjU5MiAxMDYgJmx0Oy9vYnMm
Z3Q7PGJyPiZsdDtvYnMmZ3Q7NzU2MDAgLTAuMDI2ODExIDEwNyAmbHQ7L29icyZndDsKPGJyPiZs
dDtvYnMmZ3Q7NzM2MDAgMC4wMDAwMDAgMTA4ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0Ozcz
NjAwIC0wLjAwODE4NiAxMDkgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzMwMDAgMC4wMjAz
NDAgMTEwICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0Ozc0NTAwIDAuMDAyNjgxIDExMSAmbHQ7
L29icyZndDs8YnI+Jmx0O29icyZndDs3NDcwMCAtMC4wMDk0MTUgMTEyICZsdDsvb2JzJmd0Owo8
YnI+Jmx0O29icyZndDs3NDAwMCAwLjAyNjY2OCAxMTMgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMm
Z3Q7NzYwMDAgMC4wMTQzNzAgMTE0ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0Ozc3MTAwIC0w
LjAwMTI5OCAxMTUgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzcwMDAgMC4wMDI1OTQgMTE2
ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0Ozc3MjAwIC0wLjAwMjU5NCAxMTcgJmx0Oy9vYnMm
Z3Q7Cjxicj4mbHQ7b2JzJmd0Ozc3MDAwIC0wLjAyNzY1MiAxMTggJmx0Oy9vYnMmZ3Q7PGJyPiZs
dDtvYnMmZ3Q7NzQ5MDAgLTAuMDAyNjc0IDExOSAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs3
NDcwMCAtMC4wMTA3NjcgMTIwICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzczOTAwIC0wLjAx
NjM3MSAxMjEgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzI3MDAgMC4wMDQxMTggMTIyICZs
dDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs3MzAwMCAtMC4wMDI3NDMgMTIzICZsdDsvb2JzJmd0
Ozxicj4mbHQ7b2JzJmd0OzcyODAwIDAuMDE0OTk3IDEyNCAmbHQ7L29icyZndDs8YnI+Jmx0O29i
cyZndDs3MzkwMCAtMC4wMTQ5OTcgMTI1ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzcyODAw
IC0wLjAxMTA1MCAxMjYgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzIwMDAgLTAuMDA5Nzcw
IDEyNyAmbHQ7L29icyZndDsKPGJyPiZsdDtvYnMmZ3Q7NzEzMDAgMC4wMDU1OTQgMTI4ICZsdDsv
b2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzcxNzAwIDAuMDE3OTY5IDEyOSAmbHQ7L29icyZndDs8YnI+
Jmx0O29icyZndDs3MzAwMCAtMC4wMDEzNzEgMTMwICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0
OzcyOTAwIDAuMDA4MTk3IDEzMSAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs3MzUwMCAwLjAy
Mjg2NiAxMzIgJmx0Oy9vYnMmZ3Q7Cjxicj4mbHQ7b2JzJmd0Ozc1MjAwIC0wLjAwNjY3MSAxMzMg
Jmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzQ3MDAgLTAuMDA5NDE1IDEzNCAmbHQ7L29icyZn
dDs8YnI+Jmx0O29icyZndDs3NDAwMCAtMC4wMTM2MDYgMTM1ICZsdDsvb2JzJmd0Ozxicj4mbHQ7
b2JzJmd0OzczMDAwIC0wLjAxNjU3NSAxMzYgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzE4
MDAgMC4wMDAwMDAgMTM3ICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs3MTgwMCAtMC4wMDY5
ODggMTM4ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzcxMzAwIDAuMDA4MzgwIDEzOSAmbHQ7
L29icyZndDs8YnI+Jmx0O29icyZndDs3MTkwMCAtMC4wMTU0MTcgMTQwICZsdDsvb2JzJmd0Ozxi
cj4mbHQ7b2JzJmd0OzcwODAwIC0wLjAyMjg1OCAxNDEgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMm
Z3Q7NjkyMDAgLTAuMDE0NTU2IDE0MiAmbHQ7L29icyZndDsKPGJyPiZsdDtvYnMmZ3Q7NjgyMDAg
MC4wMTE2NjIgMTQzICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY5MDAwIDAuMDAwMDAwIDE0
NCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs2OTAwMCAwLjAwNTc4MCAxNDUgJmx0Oy9vYnMm
Z3Q7PGJyPiZsdDtvYnMmZ3Q7Njk0MDAgMC4wMTI4ODUgMTQ2ICZsdDsvb2JzJmd0Ozxicj4mbHQ7
b2JzJmd0OzcwMzAwIC0wLjAxMDAwNyAxNDcgJmx0Oy9vYnMmZ3Q7Cjxicj4mbHQ7b2JzJmd0OzY5
NjAwIDAuMDAyODY5IDE0OCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs2OTgwMCAtMC4wMjE3
MjQgMTQ5ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY4MzAwIDAuMDA3Mjk0IDE1MCAmbHQ7
L29icyZndDs8YnI+Jmx0O29icyZndDs2ODgwMCAwLjAwMjkwMyAxNTEgJmx0Oy9vYnMmZ3Q7PGJy
PiZsdDtvYnMmZ3Q7NjkwMDAgLTAuMDAyOTAzIDE1MiAmbHQ7L29icyZndDsKPGJyPiZsdDtvYnMm
Z3Q7Njg4MDAgLTAuMDMwOTk5IDE1MyAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs2NjcwMCAt
MC4wMDc1MjQgMTU0ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY2MjAwIDAuMDIyNDA2IDE1
NSAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs2NzcwMCAtMC4wMjY5NDggMTU2ICZsdDsvb2Jz
Jmd0Ozxicj4mbHQ7b2JzJmd0OzY1OTAwIC0wLjAwMTUxOSAxNTcgJmx0Oy9vYnMmZ3Q7Cjxicj4m
bHQ7b2JzJmd0OzY1ODAwIDAuMDA0NTQ5IDE1OCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs2
NjEwMCAwLjA0MDAzNSAxNTkgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7Njg4MDAgMC4wMDI5
MDMgMTYwICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY5MDAwIC0wLjAxMzEyOSAxNjEgJmx0
Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NjgxMDAgMC4wMDU4NTcgMTYyICZsdDsvb2JzJmd0Owo8
YnI+Jmx0O29icyZndDs2ODUwMCAwLjAwMDAwMCAxNjMgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMm
Z3Q7Njg1MDAgMC4wMDU4MjIgMTY0ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY4OTAwIC0w
LjAwODc0NiAxNjUgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NjgzMDAgMC4wMTAxOTcgMTY2
ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY5MDAwIC0wLjAwODczNCAxNjcgJmx0Oy9vYnMm
Z3Q7Cjxicj4mbHQ7b2JzJmd0OzY4NDAwIDAuMDAwMDAwIDE2OCAmbHQ7L29icyZndDs8YnI+Jmx0
O29icyZndDs2ODQwMCAtMC4wMTQ3MjggMTY5ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY3
NDAwIDAuMDAyOTYzIDE3MCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs2NzYwMCAwLjAwNTkw
MCAxNzEgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NjgwMDAgMC4wMDg3ODUgMTcyICZsdDsv
b2JzJmd0Owo8YnI+Jmx0O29icyZndDs2ODYwMCAtMC4wMDU4NDggMTczICZsdDsvb2JzJmd0Ozxi
cj4mbHQ7b2JzJmd0OzY4MjAwIC0wLjAxMTgwMCAxNzQgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMm
Z3Q7Njc0MDAgMC4wMDU5MTcgMTc1ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzY3ODAwIC0w
LjAwNDQzNSAxNzYgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7Njc1MDAgMC4wMjQ4NzMgMTc3
ICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs2OTIwMCAwLjA0NjU4NiAxNzggJmx0Oy9vYnMm
Z3Q7PGJyPiZsdDtvYnMmZ3Q7NzI1MDAgMC4wMTY0MTYgMTc5ICZsdDsvb2JzJmd0Ozxicj4mbHQ7
b2JzJmd0OzczNzAwIDAuMDA0MDYyIDE4MCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs3NDAw
MCAwLjAwMTM1MCAxODEgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzQxMDAgMC4wMTYwNjUg
MTgyICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs3NTMwMCAtMC4wMDY2NjIgMTgzICZsdDsv
b2JzJmd0Ozxicj4mbHQ7b2JzJmd0Ozc0ODAwIDAuMDMwMjg1IDE4NCAmbHQ7L29icyZndDs8YnI+
Jmx0O29icyZndDs3NzEwMCAtMC4wMDEyOTggMTg1ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0
Ozc3MDAwIC0wLjAyNjMxNyAxODYgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzUwMDAgLTAu
MDA0MDA4IDE4NyAmbHQ7L29icyZndDsKPGJyPiZsdDtvYnMmZ3Q7NzQ3MDAgLTAuMDA2NzE2IDE4
OCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs3NDIwMCAtMC4wMDU0MDUgMTg5ICZsdDsvb2Jz
Jmd0Ozxicj4mbHQ7b2JzJmd0OzczODAwIDAuMDAyNzA2IDE5MCAmbHQ7L29icyZndDs8YnI+Jmx0
O29icyZndDs3NDAwMCAtMC4wMTQ5NzYgMTkxICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0Ozcy
OTAwIDAuMDE0OTc2IDE5MiAmbHQ7L29icyZndDsKPGJyPiZsdDtvYnMmZ3Q7NzQwMDAgMC4wMTIw
ODkgMTkzICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0Ozc0OTAwIC0wLjAwNjY5OCAxOTQgJmx0
Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7NzQ0MDAgMC4wMDQwMjQgMTk1ICZsdDsvb2JzJmd0Ozxi
cj4mbHQ7b2JzJmd0Ozc0NzAwIDAuMDA0MDA4IDE5NiAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZn
dDs3NTAwMCAtMC4wMjAyMDMgMTk3ICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29icyZndDs3MzUwMCAt
MC4wMDI3MjUgMTk4ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzczMzAwIDAuMDA2Nzk4IDE5
OSAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs3MzgwMCAwLjAzNzIzOCAyMDAgJmx0Oy9vYnMm
Z3Q7PGJyPiZsdDtvYnMmZ3Q7NzY2MDAgMC4wMjQ1MDIgMjAxICZsdDsvb2JzJmd0Ozxicj4mbHQ7
b2JzJmd0Ozc4NTAwIDAuMDQ5NzAwIDIwMiAmbHQ7L29icyZndDsKPGJyPiZsdDtvYnMmZ3Q7ODI1
MDAgMC4wMDAwMDAgMjAzICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzgyNTAwIC0wLjAzMDc3
MiAyMDQgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7ODAwMDAgMC4wMjQ2OTMgMjA1ICZsdDsv
b2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzgyMDAwIDAuMDE1NzI5IDIwNiAmbHQ7L29icyZndDs8YnI+
Jmx0O29icyZndDs4MzMwMCAwLjA3NzM2MSAyMDcgJmx0Oy9vYnMmZ3Q7Cjxicj4mbHQ7b2JzJmd0
OzkwMDAwIDAuMDA1NTQwIDIwOCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs5MDUwMCAwLjAx
NTM1MSAyMDkgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7OTE5MDAgLTAuMDA5ODQyIDIxMCAm
bHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs5MTAwMCAwLjAyNzEwMiAyMTEgJmx0Oy9vYnMmZ3Q7
PGJyPiZsdDtvYnMmZ3Q7OTM1MDAgMC4wMDEwNjkgMjEyICZsdDsvb2JzJmd0Owo8YnI+Jmx0O29i
cyZndDs5MzYwMCAwLjA2NjE0MCAyMTMgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7MTAwMDAw
IC0wLjAwNDAwOCAyMTQgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7OTk2MDAgMC4wMjM4MTEg
MjE1ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzEwMjAwMCAwLjA4NDU1NyAyMTYgJmx0Oy9v
YnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7MTExMDAwIC0wLjAxODE4MiAyMTcgJmx0Oy9vYnMmZ3Q7Cjxi
cj4mbHQ7b2JzJmd0OzEwOTAwMCAtMC4wMzczODggMjE4ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2Jz
Jmd0OzEwNTAwMCAtMC4wMjg5ODggMjE5ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzEwMjAw
MCAtMC4wMjk4NTMgMjIwICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0Ozk5MDAwIDAuMDQ0NDUy
IDIyMSAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDsxMDM1MDAgLTAuMDI0NDUxCiAyMjIgJmx0
Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7MTAxMDAwIC0wLjAzNTI2OCAyMjMgJmx0Oy9vYnMmZ3Q7
PGJyPiZsdDtvYnMmZ3Q7OTc1MDAgMC4wMjAzMDUgMjI0ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2Jz
Jmd0Ozk5NTAwIC0wLjAyNTQ0NyAyMjUgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7OTcwMDAg
LTAuMDIwODM0IDIyNiAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs5NTAwMCAKMC4wMTI1NTIg
MjI3ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0Ozk2MjAwIDAuMDMzNzI4IDIyOCAmbHQ7L29i
cyZndDs8YnI+Jmx0O29icyZndDs5OTUwMCAwLjAzNDU3MSAyMjkgJmx0Oy9vYnMmZ3Q7PGJyPiZs
dDtvYnMmZ3Q7MTAzMDAwIC0wLjAzOTYwOSAyMzAgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7
OTkwMDAgMC4wMzk2MDkgMjMxICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzEwMzAwMCAtCjAu
MDA5NzU2IDIzMiAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDsxMDIwMDAgLTAuMDI5ODUzIDIz
MyAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDs5OTAwMCAwLjAyOTg1MyAyMzQgJmx0Oy9vYnMm
Z3Q7PGJyPiZsdDtvYnMmZ3Q7MTAyMDAwIC0wLjAxOTgwMyAyMzUgJmx0Oy9vYnMmZ3Q7PGJyPiZs
dDtvYnMmZ3Q7MTAwMDAwIDAuMDAwMDAwIDIzNiAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDsx
MDAwMDAgCjAuMDI5NTU5IDIzNyAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDsxMDMwMDAgLTAu
MDE5NjA4IDIzOCAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDsxMDEwMDAgMC4wMDk4NTIgMjM5
ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzEwMjAwMCAwLjAxOTQxOCAyNDAgJmx0Oy9vYnMm
Z3Q7PGJyPiZsdDtvYnMmZ3Q7MTA0MDAwIC0wLjAwOTY2MiAyNDEgJmx0Oy9vYnMmZ3Q7PGJyPiZs
dDtvYnMmZ3Q7MTAzMDAwIAowLjAxNDQ1OCAyNDIgJmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7
MTA0NTAwIDAuMTA4NzA0IDI0MyAmbHQ7L29icyZndDs8YnI+Jmx0O29icyZndDsxMTY1MDAgMC4w
NDIwMjMgMjQ0ICZsdDsvb2JzJmd0Ozxicj4mbHQ7b2JzJmd0OzEyMTUwMCAwLjA0ODIwMiAyNDUg
Jmx0Oy9vYnMmZ3Q7PGJyPiZsdDtvYnMmZ3Q7MTI3NTAwIDAuMDMwODkwIDI0NiAmbHQ7L29icyZn
dDs8YnI+Jmx0O29icyZndDsxMzE1MDAgCjAuMDE4ODMzIDI0NyAmbHQ7L29icyZndDs8YnI+Jmx0
Oy9vYnNlcnZhdGlvbnMmZ3Q7PGJyPiZsdDsvZ3JldGxkYXRhJmd0Ozxicj48L3A+PC9kaXY+Cg==

--===============6706625926640114831==--


From cri@linux.it Wed Jan 11 13:34:45 2006
From: Cristian Rigamonti <cri@linux.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] questions about translation details
Date: Wed, 11 Jan 2006 19:34:27 +0100
Message-ID: <20060111183427.GA4110@pegasus>
In-Reply-To: Pine.LNX.4.64.0601102253050.9273@ricardo.ecn.wfu.edu
Content-Type: multipart/mixed; boundary="===============6460862754546984685=="

--===============6460862754546984685==
Content-Type: application/pgp-signature
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="signature.asc"
MIME-Version: 1.0

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC4xIChHTlUv
TGludXgpCgppRDhEQlFGRHhVK3pyU0FhZ1pRNlh3NFJBanEzQUo5MnBHYktIV2tzeDI0dnM1S044
NE9mcGRrQlR3Q2drQnNoCmFLd2NGeHc5ZzBiRlhyMWtwaGZMYnBNPQo9WjkrdgotLS0tLUVORCBQ
R1AgU0lHTkFUVVJFLS0tLS0K

--===============6460862754546984685==--


From jack@deanovell.unian.it Wed Jan 11 13:42:10 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Convergence is not met
Date: Wed, 11 Jan 2006 17:23:59 +0100
Message-ID: <Pine.LNX.4.44.0601111711060.31912-100000@ec-4.econ.univpm.it>
In-Reply-To: 4357bb540601102012h3e121512v3a13616669fa0733@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8977852751717154071=="

--===============8977852751717154071==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Wed, 11 Jan 2006, Seung Hun Han wrote:

> when i estimate the garch parameter of cj stock price during 1 year data
> using gretl and R.
>
>  IN Gnu-R.
> > garch(x,c(1,1))
>

... [snip] ...

Note here:

>  ***** FALSE CONVERGENCE *****
>
>  FUNCTION    -0.849489E+03   RELDX        0.114E-13
>  FUNC. EVALS      78         GRAD. EVALS      21
>  PRELDF       0.477E-13      NPRELDF      0.231E-06
>
>      I      FINAL X(I)        D(I)          G(I)
>
>      1    0.167570E-05     0.100E+01     0.188E+04
>      2    0.630399E-01     0.100E+01     0.113E+01
>      3    0.944707E+00     0.100E+01     0.364E+00
>

and here

> Warning message:
> NANs... in: sqrt(pred$e)

Note that the sum of the 2 garch parameters alpha and beta exceeds 1. In
these cases, the GARCH model is simply not appropriate (it must be said
that your sample is a bit small for garch estimation).

On the same data, Eviews gives:

C		0.001085	0.001262	0.860183	0.3897
C		3.01E-06	3.16E-06	0.953145	0.3405
ARCH(1)		0.056867	0.018513	3.071698	0.0021
GARCH(1)	0.946872	0.019763	47.91246	0.0000

and you have the same problem.

Laurent's ox package gives

 Maximum Likelihood Estimation (Std.Errors based on Second derivatives)
                  Coefficient  Std.Error  t-value  t-prob
Cst(M)               0.001329  0.0011434    1.163  0.2461
Cst(V)               0.016847   0.053572   0.3145  0.7534
ARCH(Alpha1)         0.062022   0.020664    3.001  0.0030
GARCH(Beta1)         0.945226   0.025128    37.62  0.0000

and you have the same problem again.

In circumstances such as these, gretl concludes there is no convergence.
Actually, after 3 iterations the gretl algorithm lands onto

Parameters and gradients at iter. 3
    0.078722 (-4.495820)
    0.006162 (150.511348)
    0.059888 (103.997100)
    0.940112 (122.291993)

and refuses to go further because following the optimisation algorithm
you'd go outside the admissible parameter space.

See also the thread on this same list about a month ago:

http://ricardo.ecn.wfu.edu/pipermail/gretl-users/2005-December/


Hope this helps,

Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============8977852751717154071==--


From masa4u@gmail.com Wed Jan 11 19:01:02 2006
From: Seung Hun Han <masa4u@gmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Re: Convergence is not met
Date: Thu, 12 Jan 2006 09:01:01 +0900
Message-ID: <4357bb540601111601o7c7240b8q1e2d0976de9e94cc@mail.gmail.com>
Content-Type: multipart/mixed; boundary="===============5660115839145490754=="

--===============5660115839145490754==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGRpdj5UaGFuayB1IGZvciBqYWNrJ3Mgd2FybXRobHkgcmVwbHkuPC9kaXY+CjxkaXY+Jm5ic3A7
PC9kaXY+CjxkaXY+SSBhbSBhIG5ldyB1c2VyIGluIGdyZXRsIGFuZCBhbHNvIGEgbmV3IGJhYnkg
aW4gdHNlcmllcy48L2Rpdj4KPGRpdj5QcmV2aW91cyBzYW1wbGUgZGF0YSB3YXMgZXhwYW5kZWQg
dmFyaWFuY2UgZnJvbSB0aW1lIHRvIHRpbWUgLiBTbyBJdCB3YXMgaGFyZCB0byBlc3RpbWF0ZSBn
YXJjaCBtb2RlbChpIGtub3cgbm93Li4gYWxwaGEgKyBiZXRhICZndDsgMSB0aGVuIGNvbnZlcmdl
bmNlIGlzIG5vdCBtZXQpLiBzbyZuYnNwO0kgZGVjaWRlZCB0byBpbmNsdWRlIG1vcmUgZGF0YSwg
YnV0IEkgZG9uJ3Qga25vdyBob3cgbWFueSBkYXRhIGlzIHJlcXVpcmVkIHRvIG1ha2UgcHJvcGVy
bHkgZ2FyY2ggbW9kZWwuCjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2Pkkgd2FzIHNlZW4g
YSBib29rIGZvciBmZXcgeWVhcnMgYWdvIGFib3V0IGFyaW1hIG1vZGVsLiB0aGlzIG1vZGVsIGlz
IHJlcXVpcmVkIGF0IGxlYXN0IDUwIGRhdGEuPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+
cTFdUGxlYXNlIHRlbGwgbWUgaG93IG1hbnkgZGF0YSBpcyByZXF1aWVyZWQgdG8gZXN0aW1hdGUg
Z2FyY2ggbW9kZWwuLi48L2Rpdj4KPGRpdj5qdXN0IGluY2x1ZGVpbmcgZGF0YSB1bnRpbCBhbHBo
YSArIGJldGEgJmx0OyAxID8/PC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+cV0gSW4gZ2Vu
ZXJhbHkgZXN0aW1hdGluZyBhIG1vZGVsLCA2MCUgZGF0YSBpcyBlc3RpbWF0ZSBtb2RlbCdzIGEg
cGFyYW1ldGVyIGFuZCA0MCUncyBkYXRhIGlzIGNvbmZpcm0gYSBtb2RlbCAuLiBlc3RpbWF0ZWQg
bW9kZWwgaXMgcHJvcGVybHkgZXN0aW1hdGVkLiBJIHRoaW5rLiBpbiB0aW1lIHNlcmllcyB0aGlz
IG1vZGVsIGNvbmZpcm1pbmcgbWV0aG9kIGlzIG5vdCBtZXQuLi4gCjwvZGl2Pgo8ZGl2PiZuYnNw
OzwvZGl2Pgo8ZGl2Pmkgd2lsbCB3YWl0aW5nIGZvciBtb3JlIHdhcm10aGx5IGFuc3dlciBhZ2Fp
bi4gPC9kaXY+Cg==

--===============5660115839145490754==--


From svetosch@gmx.net Wed Jan 11 19:22:47 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] questions about translation details
Date: Thu, 12 Jan 2006 01:22:33 +0100
Message-ID: <43C5A149.7030306@gmx.net>
In-Reply-To: Pine.LNX.4.64.0601102253050.9273@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2158011695695302392=="

--===============2158011695695302392==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:

> Right now there is experimental stuff going on (we're adding the
> facility to define and manipulate matrices), but I don't think any
> existing functionality is broken so I'll make a new Windows snapshot
> tomorrow, Jan 11.

Using it now, and being pleasantly surprised by the already included
Gini/Lorenz stuff - thanks very much! (btw, maybe the menu entry should
include Lorenz since it automatically produces the Lorenz curve -- for
example "Gini, Lorenz")

Some more questions related to the translation, focusing on the more
fundamental ones:

- Now that I have to think about it I realized that I'm a bit confused
by the menu structure in the main window, especially concerning the
triad data-sample-variable. What are the defining characteristics for
menu entries in each of those menus? For example, it would seem more
natural to look for modification of the "dataset structure" under the
"data" menu instead of "sample". (It could also be I'm misunderstanding
the scope of commands that modify the dataset structure.) There are also
other cases that I currently find misplaced, but maybe not anymore after
understanding the official point of view.

Thanks,
Sven

--===============2158011695695302392==--


From cottrell@wfu.edu Wed Jan 11 20:02:46 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] questions about translation details
Date: Wed, 11 Jan 2006 20:02:45 -0500
Message-ID: <Pine.LNX.4.64.0601111955480.16852@ricardo.ecn.wfu.edu>
In-Reply-To: 43C5A149.7030306@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0579953647200879127=="

--===============0579953647200879127==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, 12 Jan 2006, Sven Schreiber wrote:

> Using it now, and being pleasantly surprised by the already 
> included Gini/Lorenz stuff - thanks very much! (btw, maybe the 
> menu entry should include Lorenz since it automatically produces 
> the Lorenz curve -- for example "Gini, Lorenz")

I'll try to think of a better string for that menu item.

> - Now that I have to think about it I realized that I'm a bit 
> confused by the menu structure in the main window, especially 
> concerning the triad data-sample-variable. What are the defining 
> characteristics for menu entries in each of those menus? For 
> example, it would seem more natural to look for modification of 
> the "dataset structure" under the "data" menu instead of "sample".

You have a point.  I'm not totally clear on how all the specific 
menu items should best be distributed between the Data, Sample and 
Variable headings.  The layout has basically "just grown" to its 
current form, and I'd be glad to hear suggestions for 
rationalizing it.

Allin Cottrell


--===============0579953647200879127==--


From masa4u@gmail.com Thu Jan 12 07:48:02 2006
From: Seung Hun Han <masa4u@gmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] forecasting garch vol
Date: Thu, 12 Jan 2006 21:47:59 +0900
Message-ID: <4357bb540601120447j1e1f30bau2f94af0181d1d594@mail.gmail.com>
Content-Type: multipart/mixed; boundary="===============1972470759405857733=="

--===============1972470759405857733==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj48YSBocmVmPSJodHRwOi8vd3d3Lm1hdGh3b3Jrcy5jb20v
YWNjZXNzL2hlbHBkZXNrL2hlbHAvdG9vbGJveC9nYXJjaC9mb3JlY2FzdGluZzEwLmh0bWwjODEx
ODQiPmh0dHA6Ly93d3cubWF0aHdvcmtzLmNvbS9hY2Nlc3MvaGVscGRlc2svaGVscC90b29sYm94
L2dhcmNoL2ZvcmVjYXN0aW5nMTAuaHRtbCM4MTE4NDwvYT48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rp
dj4KPGRpdj50aGlzIGRhdGEgYWxzbyBpbiBncmV0bDwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8
ZGl2PnlvdSBzaG91bGQgZG8gaXQgPC9kaXY+CjxkaXY+b3BlbiBiLWc8L2Rpdj4KPGRpdj5nYXJj
aCAxIDE7IFk8L2Rpdj4KPGRpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5hbmQgaSBkb24ndCBr
bm93IGhvdyBkbyBpIGZvcmVjYXN0Li48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj5mb3Jl
Y2FzdGluZyBmdXR1cmUgdm9sYXRpbGl0eS4uLndpdGggbWF0aGxhYi48L2Rpdj48L2Rpdj4KPGRp
dj48Zm9udCBzaXplPSIyIj5JIGFtIGhhdmluZyB0cm91YmxlIGludGVycHJldGluZyB0aGUgb3V0
cHV0IG9mIGdhcmNocHJlZCxmb3IgZXhhbXBsZSw8L2ZvbnQ+PC9kaXY+CjxkaXY+Jm5ic3A7PC9k
aXY+CjxkaXY+c3BlYyA9IGdhcmNoc2V0KCdQJywxLCdRJywxLCdUb2xDb24nLDFlLTYpOzxicj5n
YXJjaGZpdChzcGVjLGJnKTs8YnI+W2NvZWZmLGVycm9ycyxMTEYsaW5ub3ZhdGlvbnMsc2lnbWFz
XSA9IGdhcmNoZml0KGJnKTs8YnI+W3NpZ21hRm9yZWNhc3QsbWVhbkZvcmVjYXN0XSZuYnNwOyA9
IGdhcmNocHJlZChjb2VmZixiZywxMCk7PGJyPjxicj5bc2lnbWFGb3JlY2FzdCxtZWFuRm9yZWNh
c3RdCjxicj48YnI+VkwgPSBjb2VmZi5LLygxLWNvZWZmLkFSQ0gtY29lZmYuR0FSQ0gpPGJyPjxi
cj5uZXd2YXIgPSBzcXJ0KFZMICsgKGNvZWZmLkFSQ0grY29lZmYuR0FSQ0gpXlsxIDIgMyA0IDUg
NiA3IDggOSAxMF0nKihzaWdtYXMoMTk3NCleMi1WTCkpPGJyPiZuYnNwOzwvZGl2Pgo8ZGl2PiUg
dGhpcyBlcXVhdGlvbiBpcyByZWZyZW5jZWQgT3B0aW9ucywgRnV0dXJlIGFuZCBvdGhlciBEZXJp
dmF0aXZlcyA2dGggcGFnZSA0NzIgZXF1YXRpb24gMTkuMTMoSk9ITiBDLiBIVUxMKTwvZGl2Pgo8
ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PnNpZ21hRm9yZWNhc3QgPTxicj48YnI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7IDAuMzgzNDxicj4mbmJzcDsmbmJzcDsmbmJzcDsgMC4zODk1PGJyPiZuYnNwOyZuYnNw
OyZuYnNwOyAwLjM5NTM8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuNDAwODxicj4mbmJzcDsmbmJz
cDsmbmJzcDsgMC40MDYwPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAwLjQxMTA8YnI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7IDAuNDE1Njxicj4mbmJzcDsmbmJzcDsmbmJzcDsgMC40MjAwPGJyPiZuYnNwOyZu
YnNwOyZuYnNwOyAwLjQyNDI8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuNDI4Mjxicj48YnI+Jmd0
OyZndDsgbmV3dmFyID0gc3FydChWTCArIChjb2VmZi5BUkNIK2NvZWZmLkdBUkNICikuXlsxIDIg
MyA0IDUgNiA3IDggOSAxMF0nKihzaWdtYXMoMTk3NCleMi1WTCkpPGJyPjxicj5uZXd2YXIgPTxi
cj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuMzQ3Nzxicj4mbmJzcDsmbmJzcDsmbmJzcDsgMC4z
NTU5PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAwLjM2Mzc8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAu
MzcxMDxicj4mbmJzcDsmbmJzcDsmbmJzcDsgMC4zNzc4PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAw
LjM4NDM8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAuMzkwNDxicj4mbmJzcDsmbmJzcDsmbmJzcDsg
MC4zOTYxPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAwLjQwMTY8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
IDAuNDA2Nzxicj48YnI+Jmd0OyZndDsgCjxicj4mbmJzcDs8L2Rpdj4KPGRpdj53aHkgdHdvIHJl
c3VsdCBpcyBkaWZmZXJlbnQuLiZuYnNwOyBhbmQgZHVyaW5nIDEwZGF5cyB2b2xhdGlsaXR5IGlz
IG1lYW4oc2lnbWFGb3JlY2FzdCApLiBpcyBjb3JyZWN0PzwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2
Pgo8ZGl2PmknbSBzdGlsbCBpbiBnYXJjaCB3b3JsZCAtXy07IGFueWJvZHkgaGVscCBtZS4uLiA8
L2Rpdj4K

--===============1972470759405857733==--


From svetosch@gmx.net Thu Jan 12 10:04:17 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] questions about translation details
Date: Thu, 12 Jan 2006 16:05:17 +0100
Message-ID: <43C6702D.6000208@gmx.net>
In-Reply-To: Pine.LNX.4.64.0601111955480.16852@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1471574369333537360=="

--===============1471574369333537360==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:

> You have a point.  I'm not totally clear on how all the specific menu
> items should best be distributed between the Data, Sample and Variable
> headings.  The layout has basically "just grown" to its current form,
> and I'd be glad to hear suggestions for rationalizing it.

Ok, here are my suggestions for the "evolution" of the menu structure, reshuffling some menu entries
between the "data", "sample", "variable" menus to hopefully make it more intuitive. (Of course,
sometimes it might be the case that I simply haven't understood what the respective command really
does... In those cases, please correct and enlighten me.)

I) "Data" menu: I interpret that as relating to the loaded dataset as a whole, so one may think of
renaming that to "Dataset" instead. Given that interpretation, the following items should be moved
elsewhere:
1. graph specified vars (-> "sample")
2. Multiple scatterplots (-> "sample")
3. everything from summary statistics to differences of variances should also go to "sample"

II) "Sample" menu: in my view, all commands that act on or modify data in the current sample range
(as opposed to the entire dataset) should come here. (see what was moved from "data" in I) Therefore
remove:
1. Dataset structure / compact data /expand data (-> "data(set)")
2. restructure panel / transpose data (also -> "data(set)")
[3. not sure about the missing-value and case marker things, don't know enough about them)

III) "Variable" menu: interpreted as variants of univariate analsis, so move:
1. find (-> "data(set)")
2. define new variable ( "data(set)")
[3. again not sure about the missing-value issue, why here _and_ in "sample"?)


So what do you guys think? Of course experienced users would have to adapt, but I would argue the
changes are relatively mild and make more sense in the longer run.

cheers,
sven

--===============1471574369333537360==--


From abervas@hotmail.com Thu Jan 12 14:53:39 2006
From: Arnaud Bervas <abervas@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] gmm
Date: Thu, 12 Jan 2006 19:53:37 +0000
Message-ID: <BAY104-F32E4B3C3A7EE152AD5CF5CBF270@phx.gbl>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3810270949630895083=="

--===============3810270949630895083==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

is it possible to make gmm estimation using gretl ?



--===============3810270949630895083==--


From cottrell@wfu.edu Thu Jan 12 17:47:25 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] problem:displaying lagged variables
Date: Thu, 12 Jan 2006 17:47:25 -0500
Message-ID: <Pine.LNX.4.64.0601121744080.22097@ricardo.ecn.wfu.edu>
In-Reply-To: BAY104-F143B308C4B73C7EB97BC60BF2B0@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2108907308061999061=="

--===============2108907308061999061==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Sat, 31 Dec 2005, Arnaud Bervas wrote:

> I had to re-install Gretl, but surprisingly, when I try to add a 
> lagged variable to the dataset, it's no longer displayed on the 
> main screen (as it used to be in my previous version). It appears 
> in the window "Model" for regressions though. There's no such a 
> problem for the first difference operator for intance. Does anyone 
> know how to get lagged variables visible just like the others ?

It seemed to me that displaying the names of lagged variables in the 
main window just cluttered up the screen for no good reason, so I 
made them "invisible" in current gretl.

But if people think that was a bad move, I can reinstate them.

Any other thoughts on this?

Allin Cottrell

--===============2108907308061999061==--


From jack@deanovell.unian.it Thu Jan 12 18:28:59 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] gmm
Date: Fri, 13 Jan 2006 00:28:57 +0100
Message-ID: <Pine.LNX.4.44.0601130021290.25712-100000@ec-4.econ.univpm.it>
In-Reply-To: BAY104-F32E4B3C3A7EE152AD5CF5CBF270@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6343435569476451425=="

--===============6343435569476451425==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Thu, 12 Jan 2006, Arnaud Bervas wrote:

> is it possible to make gmm estimation using gretl ?

Not yet.

That said, I have a question: what specifically do you need gmm for?
"Generic" GMM estimation is more a theoretical concept (ie something you
use to devise estimators an establish their properties) than an applied
one. The computational machinery behind the estimation of dynamic panel
data models is very different from what you need to estimate Euler
equations. In both cases, the theory says you use a GMM estimator; in
practice, the former is a slight generalisation of instrumental variables,
the latter requires heavy numerical optimisation. OLS is a GMM estimator
too, and gretl does that rather well :-)


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============6343435569476451425==--


From jack@deanovell.unian.it Thu Jan 12 18:39:36 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] problem:displaying lagged variables
Date: Fri, 13 Jan 2006 00:39:33 +0100
Message-ID: <Pine.LNX.4.44.0601130029510.25712-100000@ec-4.econ.univpm.it>
In-Reply-To: Pine.LNX.4.64.0601121744080.22097@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9102832025369214114=="

--===============9102832025369214114==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Thu, 12 Jan 2006, Allin Cottrell wrote:

> On Sat, 31 Dec 2005, Arnaud Bervas wrote:
>
> > I had to re-install Gretl, but surprisingly, when I try to add a
> > lagged variable to the dataset, it's no longer displayed on the
> > main screen (as it used to be in my previous version). It appears
> > in the window "Model" for regressions though. There's no such a
> > problem for the first difference operator for intance. Does anyone
> > know how to get lagged variables visible just like the others ?
>
> It seemed to me that displaying the names of lagged variables in the
> main window just cluttered up the screen for no good reason, so I
> made them "invisible" in current gretl.
>
> But if people think that was a bad move, I can reinstate them.
>
> Any other thoughts on this?

I vote for invisibility. I concede there might be a slight improvement in
the way we now diplay variables in the GUI by providing some sort of
graphical sign between the ID and the variable name, that tells you
visually if lags for those variables already exist, ie something like
(apologies for the poor ASCII art)

2 [ ] Foo	blah blah blah
3 [4] Bar	grunt
4 [ ] Baz	no description

Which means: Foo_1 doesn't exist yet, but Bar_4 does.

I suspect the improvement would be rather small, compared to the amount of
work on the GUI Allin would have to do (don't look at me, I wouldn't know
where to start, but someone with some GTK experience could lend a hand).
But I may be wrong. What do you think, guys?


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============9102832025369214114==--


From jack@deanovell.unian.it Thu Jan 12 18:55:52 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] questions about translation details
Date: Fri, 13 Jan 2006 00:55:49 +0100
Message-ID: <Pine.LNX.4.44.0601130045100.27206-100000@ec-4.econ.univpm.it>
In-Reply-To: 43C6702D.6000208@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1691168334712491347=="

--===============1691168334712491347==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Thu, 12 Jan 2006, Sven Schreiber wrote:

> I) "Data" menu: I interpret that as relating to the loaded dataset as a who=
le, so one may think of
> renaming that to "Dataset" instead. Given that interpretation, the followin=
g items should be moved
> elsewhere:
> 1. graph specified vars (-> "sample")
> 2. Multiple scatterplots (-> "sample")
> 3. everything from summary statistics to differences of variances should al=
so go to "sample"
>
> II) "Sample" menu: in my view, all commands that act on or modify data in t=
he current sample range
> (as opposed to the entire dataset) should come here. (see what was moved fr=
om "data" in I) Therefore
> remove:
> 1. Dataset structure / compact data /expand data (-> "data(set)")
> 2. restructure panel / transpose data (also -> "data(set)")
> [3. not sure about the missing-value and case marker things, don't know eno=
ugh about them)
>
> III) "Variable" menu: interpreted as variants of univariate analsis, so mov=
e:
> 1. find (-> "data(set)")
> 2. define new variable ( "data(set)")
> [3. again not sure about the missing-value issue, why here _and_ in "sample=
"?)
>
>
> So what do you guys think? Of course experienced users would have to adapt,=
 but I would argue the
> changes are relatively mild and make more sense in the longer run.

Makes sense to me, although the distinction you draw between "data" and
"sample" looks a bit fuzzy to me: following your logic, the whole
variable-generation machine should go under "sample".

And while we're at it, is the model menu to be left untouched? I mean, I
wouldn't mind an organisation like

OLS
-------------
Other least-squares estimators -> IV, Weighted, ...
-------------
Time series
-------------
Qualitative & limited dependent -> Logit, Probit, Tobit
-------------
Count data -> Only Poisson for now
-------------
System -> VARs could go in here
-------------
Other
-------------


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Universit=C3=A0 Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============1691168334712491347==--


From svetosch@gmx.net Fri Jan 13 05:16:13 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] questions about translation details
Date: Fri, 13 Jan 2006 11:17:03 +0100
Message-ID: <43C77E1F.5020107@gmx.net>
In-Reply-To: Pine.LNX.4.44.0601130045100.27206-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4215488886179910056=="

--===============4215488886179910056==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Thanks for your feedback!

jack schrieb:
> 
> 
> Makes sense to me, although the distinction you draw between "data" and
> "sample" looks a bit fuzzy to me: following your logic, the whole
> variable-generation machine should go under "sample".
>

I'd say that depends on whether the commands perform calculations only for the current sample range
or for the entire dataset range. I confess that I simply don't know which of these is true, and I
guess both variants have their virtues.

> And while we're at it, is the model menu to be left untouched? I mean, I
> wouldn't mind an organisation like

Surely there's room for further opimization within the menus, which I tend to view as independent
from rearranging items across menus, however.

> 
> OLS
> -------------
> Other least-squares estimators -> IV, Weighted, ...
> -------------
> Time series
> -------------
> Qualitative & limited dependent -> Logit, Probit, Tobit
> -------------
> Count data -> Only Poisson for now
> -------------
> System -> VARs could go in here
> -------------
> Other
> -------------

no strong opinion from me about this one, although it's probably better than the status quo... but
VARs are Time Series as well as Systems, so finding the best categories will sometimes be difficult.

cheers,
sven


--===============4215488886179910056==--


From paravantis@otenet.gr Fri Jan 13 19:49:26 2006
From: John Paravantis <paravantis@otenet.gr>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Re: Gretl-users Digest, Vol 21, Issue 9
Date: Sat, 14 Jan 2006 02:49:18 +0200
Message-ID: <43C84A8E.7030904@otenet.gr>
In-Reply-To: 200601131700.k0DH027g027058@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2439032718785644279=="

--===============2439032718785644279==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

BAD MOVE. I'd much rather have them readily apparent on the main screen.

How about offering the user an OPTION?

John Paravantis
University of Piraeus
Greece

>>I had to re-install Gretl, but surprisingly, when I try to add a 
>>lagged variable to the dataset, it's no longer displayed on the 
>>main screen (as it used to be in my previous version). It appears 
>>in the window "Model" for regressions though. There's no such a 
>>problem for the first difference operator for intance. Does anyone 
>>know how to get lagged variables visible just like the others ?
>>    
>>
>
>It seemed to me that displaying the names of lagged variables in the 
>main window just cluttered up the screen for no good reason, so I 
>made them "invisible" in current gretl.
>
>But if people think that was a bad move, I can reinstate them.
>
>Any other thoughts on this?
>
>Allin Cottrell
>  
>

--===============2439032718785644279==--


From cottrell@wfu.edu Fri Jan 13 20:09:10 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Re: Gretl-users Digest, Vol 21, Issue 9
Date: Fri, 13 Jan 2006 20:09:10 -0500
Message-ID: <Pine.LNX.4.64.0601132000051.28579@ricardo.ecn.wfu.edu>
In-Reply-To: 43C84A8E.7030904@otenet.gr
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1737446224074887382=="

--===============1737446224074887382==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Sat, 14 Jan 2006, John Paravantis wrote:

> BAD MOVE. I'd much rather have [lagged variables] readily apparent 
> on the main screen. How about offering the user an OPTION?

I'm not ruling that out, but could you (or anyone) explain why you 
want to see lags in the main screen?

With first differences, logs, or other transformations, the 
transformed variables should (obviously) be shown, because you might 
want to select them for graphing, summary statistics, or whatever.

With lags, on the other hand, I can't see any use for them other 
than as regressors (and they are visible OK in the dialog where you 
choose regressors).  Suppose you have a monthly dataset with several 
variables, of which you want to have available 12 lags apiece for 
regression purposes.  Showing dozens of such variables in the main 
window, it seems to me, is just filling the window with trash, 
making it harder to find variables you might actually want to 
examine individually.

Am I missing something here?

Allin Cottrell


--===============1737446224074887382==--


From jack@deanovell.unian.it Sat Jan 14 04:25:08 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Re: Gretl-users Digest, Vol 21, Issue 9
Date: Sat, 14 Jan 2006 10:25:07 +0100
Message-ID: <Pine.LNX.4.44.0601141012250.16813-100000@ec-4.econ.univpm.it>
In-Reply-To: Pine.LNX.4.64.0601132000051.28579@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6554641644946687580=="

--===============6554641644946687580==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Fri, 13 Jan 2006, Allin Cottrell wrote:

> On Sat, 14 Jan 2006, John Paravantis wrote:
>
> > BAD MOVE. I'd much rather have [lagged variables] readily apparent
> > on the main screen. How about offering the user an OPTION?
>
> I'm not ruling that out, but could you (or anyone) explain why you
> want to see lags in the main screen?
>
> With first differences, logs, or other transformations, the
> transformed variables should (obviously) be shown, because you might
> want to select them for graphing, summary statistics, or whatever.
>
> With lags, on the other hand, I can't see any use for them other
> than as regressors (and they are visible OK in the dialog where you
> choose regressors).  Suppose you have a monthly dataset with several
> variables, of which you want to have available 12 lags apiece for
> regression purposes.  Showing dozens of such variables in the main
> window, it seems to me, is just filling the window with trash,
> making it harder to find variables you might actually want to
> examine individually.
>
> Am I missing something here?

I agree with Allin. Actually, I'd go even further. If it were for me, I'd
even hide lags from the selection window you get when you estimate with
OLS, IV, VARs etc. (provided of course there's some way to include lags
in regressions interactively), because you have exacly the same problem,
possibly worse as the window is smaller.

Having used Linux exclusively for several years now, I have dim memories
of the way PcGive works, but I recall you have a very convenient way to
include a variable AND OPTIONALLY SOME LAGS in a regression interactively.
Lags get generated on the fly and discarded subsequently.  This, by the
way, is a much saner way to go: imagine I

1) define a variable z
2) generate n lags: now I have z_1, ..., z_n
3) change z

now you have the potential for something very misleading, cause z(-1) is
different from z_1.


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti




--===============6554641644946687580==--


From cottrell@wfu.edu Sat Jan 14 09:50:59 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Hide or show lagged variables?
Date: Sat, 14 Jan 2006 09:50:58 -0500
Message-ID: <Pine.LNX.4.64.0601140942240.32095@ricardo.ecn.wfu.edu>
In-Reply-To: Pine.LNX.4.44.0601141012250.16813-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4485121051949049362=="

--===============4485121051949049362==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Sat, 14 Jan 2006, jack wrote:

> I agree with Allin. Actually, I'd go even further. If it were for 
> me, I'd even hide lags from the selection window you get when you 
> estimate with OLS, IV, VARs etc. (provided of course there's some 
> way to include lags in regressions interactively), because you 
> have exacly the same problem, possibly worse as the window is 
> smaller.

Good point.  I've considered this, but haven't done anything about 
it yet because I had trouble envisaging exactly what the user 
interface would look like.

> Having used Linux exclusively for several years now, I have dim 
> memories of the way PcGive works, but I recall you have a very 
> convenient way to include a variable AND OPTIONALLY SOME LAGS in a 
> regression interactively. Lags get generated on the fly and 
> discarded subsequently.

Makes sense.  I too have a vague recollection of how PcGive does it,
but -- apart from the issue of gretl's regressor selection 
sub-window becoming overcrowded -- I feel that gretl's selector is 
easier to use.

Anyway, if anyone has any brilliant ideas regarding the ideal 
interface, please post them!

Allin Cottrell


--===============4485121051949049362==--


From cottrell@wfu.edu Sat Jan 14 10:19:48 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] menu layout (was questions about translation details)
Date: Sat, 14 Jan 2006 10:19:47 -0500
Message-ID: <Pine.LNX.4.64.0601140951510.32095@ricardo.ecn.wfu.edu>
In-Reply-To: 43C6702D.6000208@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2106827888689631097=="

--===============2106827888689631097==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, 12 Jan 2006, Sven Schreiber wrote:

> Ok, here are my suggestions for the "evolution" of the menu 
> structure, reshuffling some menu entries between the "data", 
> "sample", "variable" menus to hopefully make it more intuitive. 
> (Of course, sometimes it might be the case that I simply haven't 
> understood what the respective command really does... In those 
> cases, please correct and enlighten me.)

OK, this is useful.  You're forcing me to try to articulate the 
thinking behind the current layout.  Ideally, of course, a set of 
GUI menus should be "transparent" to the user without having 
to read about its rationale, but here goes:

"Data" menu: Basically contains "things you might want to do with 
more than one variable" -- other than constructing a model, which 
has its own menu branch.  Examples: graphing, summary statistics, 
etc.  Plus some things pertaining to the data set as a whole -- 
other than setting the sample range, which again has its own branch. 
Examples: edit values, read informative text, if any.

"Sample" menu: The core functionality here is setting the sample 
range in various ways.  Some other functions have been added here 
(e.g. set dataset structure, transpose data), and the location of 
these extra items may be debatable.

"Variable" menu: Fairly clear -- things you might want to do with a 
single variable.

A few more comments in the light of the above.

> I) "Data" menu: I interpret that as relating to the loaded dataset 
> as a whole, so one may think of renaming that to "Dataset" 
> instead.

As above, it's not just the dataset as a whole; it mostly pertains 
to subsets (selections) of variables.  You suggest the move:

> 1. graph specified vars (-> "sample")

I'll resist that.  The Sample menu is basically about resetting the 
sample, not performing operations on subsets of variables.

I can see a case for creating a "Dataset" menu branch, and putting 
all (and only) items dealing with the entire dataset (other than 
sampling?) in there (that would include some items that are 
currently under "Data" and a few that are currently under Sample, 
such as transpose).

That leaves a problem with the items that are currently under Data 
but that would not fall under the new "Dataset".  And I'd really 
prefer not to increase the total number of menu branches, if 
possible.  Hmmm.  I'll think about this some more.

Allin Cottrell

--===============2106827888689631097==--


From jack@deanovell.unian.it Sat Jan 14 16:01:55 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Hide or show lagged variables?
Date: Sat, 14 Jan 2006 22:01:57 +0100
Message-ID: <Pine.LNX.4.44.0601142145570.27309-100000@ec-4.econ.univpm.it>
In-Reply-To: Pine.LNX.4.64.0601140942240.32095@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3181004913595329173=="

--===============3181004913595329173==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Sat, 14 Jan 2006, Allin Cottrell wrote:

> Makes sense.  I too have a vague recollection of how PcGive does it,
> but -- apart from the issue of gretl's regressor selection
> sub-window becoming overcrowded -- I feel that gretl's selector is
> easier to use.
>
> Anyway, if anyone has any brilliant ideas regarding the ideal
> interface, please post them!

I have an idea, which may not be brilliant, but at least is new.
What if the user had the possibility of selecting lists together with
regressors[1]?

If someone stubbornly refused to use the console or scripts, we could have
a menu item like "Create list with lags" (possibly right-clickable). Then
the list containing the wanted lags appears as if it was a single series,
and it can be included in the regression.

Note that in this case it wouldn't be necessary even to create the lagged
vars themselves, since inclusion of such list in an estimation command
simply acts as a "placeholder", so gretl knows we want lagged values too.
As a side benefit, this would also solve the problem I mentioned in my
previous message on modifying a vatriable after the lags are generated.

Now, 2 questions:

a Does anyone like the idea?
b if(a==TRUE) {
	Would it be hard, Allin?
  }


[1] Brief note for the benefit of non-regulars: gretl has had lists for
some time now; maybe not everyone is aware of this, because there's no
list-related element in the GUI, but you can use lists in script like this

	list zlags = z(-1 to -4)

or even

	list zlags = lags(z,4)

and then do

	ols y const zlags

which would be equivalent to

	lags 4 z
	ols y const z_1 z_2 z_3 z_4

there's more to lists, but you can read the manual for that ;-)


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============3181004913595329173==--


From svetosch@gmx.net Sun Jan 15 17:46:33 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject:
 Re: [Gretl-users] menu layout (was questions about translation details)
Date: Sun, 15 Jan 2006 23:46:07 +0100
Message-ID: <43CAD0AF.5080200@gmx.net>
In-Reply-To: Pine.LNX.4.64.0601140951510.32095@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4969029239781738901=="

--===============4969029239781738901==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell wrote:

> "Data" menu: Basically contains "things you might want to do with more
> than one variable" -- other than constructing a model, which has its own
> menu branch.  Examples: graphing, summary statistics, etc.  Plus some
> things pertaining to the data set as a whole -- other than setting the
> sample range, which again has its own branch. Examples: edit values,
> read informative text, if any.

Ok I understand it better now: for example I realized that the
"data"-commands work with the currently selected sample and never (?)
with the entire dataset. Nevertheless, having things like "sort
variables" and "mahalanobis distances" in the same menu is a bit
difficult to understand.

Therefore I would at least suggest to group the commands together that
are related to dataset-management. (Right now there are some at the top
and some at the bottom.) As a result the "data" menu would have two main
blocks, one for management commands, and one for descriptive statistics
(loosely speaking).

> 
> "Sample" menu: The core functionality here is setting the sample range
> in various ways.  Some other functions have been added here (e.g. set
> dataset structure, transpose data), and the location of these extra
> items may be debatable.

Yes I would still argue that putting those in the data menu would be
better. After all, that was the starting point of my confusion.

>> 1. graph specified vars (-> "sample")
> 
> 
> I'll resist that.  The Sample menu is basically about resetting the
> sample, not performing operations on subsets of variables.

ok, makes sense now that I understand the purpose of the sample menu,
and provided the above changes are made.

> 
> I can see a case for creating a "Dataset" menu branch, and putting all
> (and only) items dealing with the entire dataset (other than sampling?)
> in there (that would include some items that are currently under "Data"
> and a few that are currently under Sample, such as transpose).
> 
> That leaves a problem with the items that are currently under Data but
> that would not fall under the new "Dataset".  And I'd really prefer not
> to increase the total number of menu branches, if possible.  Hmmm.  I'll
> think about this some more.

I agree that the menu should not grow beyond the 7 branches (+1 help).
That's why I suggested to divide the data menu into two groups. (On the
other hand, compared to the other menus the "session" menu is quite an
outlier with only 4 entries, one of which has a toolbar button, and then
the two save-variants. I could imagine subsuming that entire menu under
the "file"-menu, after all that's were files are opened and saved... but
hey, it's not my intention to turn the gretl menu structure upside down
and irritate all longtime and faithful gretl users! So maybe you
shouldn't follow my suggestions too literally ;-)

Whatever you decide, if there's going to be some cleanup, I'm glad.

cheers,
Sven




--===============4969029239781738901==--


From abervas@hotmail.com Mon Jan 16 14:18:34 2006
From: Arnaud Bervas <abervas@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] (no subject)
Date: Mon, 16 Jan 2006 19:18:26 +0000
Message-ID: <BAY104-F32A1C3462B19C0F0EBF04EBF1B0@phx.gbl>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0182351024819886016=="

--===============0182351024819886016==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Sure, but my question was rather for more general estimators than OLS or 
even 2SLS with instrumental variables. I didn't intend to run a dynamic 
panel regression with Arellano and Bond estimator though. Actually, I was 
wondering if it would be possible to estimate Euler equations derived from a 
CCAPM model for instance.I guess it's not possible to program the implied 
numerical optimization with Gretl in its current state.



--===============0182351024819886016==--


From abervas@hotmail.com Tue Jan 17 14:05:47 2006
From: Arnaud Bervas <abervas@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] gmm
Date: Tue, 17 Jan 2006 19:05:43 +0000
Message-ID: <BAY104-F15B651E275D4E863420360BF1A0@phx.gbl>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3451680319139331382=="

--===============3451680319139331382==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Sure, but my question was rather for more general estimators than OLS or
even 2SLS with instrumental variables. I didn't intend to run a dynamic
panel regression with Arellano and Bond estimator though. Actually, I was
wondering if it would be possible to estimate Euler equations derived from a
CCAPM model for instance.I guess it's not possible to program the implied
numerical optimization with Gretl in its current state.



--===============3451680319139331382==--


From paravantis@otenet.gr Wed Jan 18 03:23:10 2006
From: John Paravantis <paravantis@otenet.gr>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Re: Gretl-users Digest, Vol 21, Issue 10
Date: Wed, 18 Jan 2006 10:22:57 +0200
Message-ID: <43CDFAE1.5080508@otenet.gr>
In-Reply-To: 200601141700.k0EH03rn001043@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2006063442889223853=="

--===============2006063442889223853==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


>>BAD MOVE. I'd much rather have [lagged variables] readily apparent 
>>on the main screen. How about offering the user an OPTION?
>>    
>>
>
>I'm not ruling that out, but could you (or anyone) explain why you 
>want to see lags in the main screen?
>
>With first differences, logs, or other transformations, the 
>transformed variables should (obviously) be shown, because you might 
>want to select them for graphing, summary statistics, or whatever.
>
Oops, my mistake. I did NOT realize we were talking about LAGS. I was 
indeed refering to diffs, logs and other transformations -- with the 
importance they have in econometrics (especially time series analysis), 
clearly any such transformation should be readily apparent.

Here is another idea: how about showing available lags NEXT (i.e. to the 
right) of the variable in case? You could even utilize a special symbol 
such as a "-1", "-2" superscript/subscript to indicate that the 
corresponding lag has been computed and is available for use in a model. 
This WOULD I think be useful without cluttering the screen.

John Paravantis
University of Piraeus

--===============2006063442889223853==--


From svetosch@gmx.net Wed Jan 18 05:34:59 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Hide or show lagged variables?
Date: Wed, 18 Jan 2006 11:35:56 +0100
Message-ID: <43CE1A0C.4030508@gmx.net>
In-Reply-To: Pine.LNX.4.44.0601142145570.27309-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4080290725210773623=="

--===============4080290725210773623==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

jack schrieb:
> On Sat, 14 Jan 2006, Allin Cottrell wrote:
> 
>> Makes sense.  I too have a vague recollection of how PcGive does it,
>> but -- apart from the issue of gretl's regressor selection
>> sub-window becoming overcrowded -- I feel that gretl's selector is
>> easier to use.

In PcGive, you select a variable, alter (if change is needed) the number of lags in an entry field, 
and add the bunch to the list of regressors. (Afterwards you can delete individual intermediate lags 
or the contemporaneous original variable itself if you want to.)

The advantages over gretl are imho:
- needed lags are created on-the-fly
- less clutter/noise in the list of selectable variables

A slight disadvantage could be that if you only want some non-contiguous lags, it might be a little 
more click-work than in gretl.

Overall I think it's worth imitating.

I also think there is a slight problem with the current state of affairs; imagine you want to run a 
quasi-dynamic regression:
x_t = c + b y_{t-1} + u_t
(One reason for that formulation could be to avoid simultaneity bias that could arise when you 
include contemporaneous y_t instead.)

Doing that in gretl is possible, but since y_{t-1} is not visible in the main window, it might 
become slightly annoying to open the regression dialog, see that y_{t-1} does not yet exist, cancel 
the dialog, create y_{t-1}, go back to the dialog. Secondly, in this scenario you might want to 
graph x_t against y_{t-1}, which is difficult because lags are not selectable in the main window.

So the solution would be (I think): First adopt the on-the-fly lag creation, and thus tell the users 
that explicitly creating lags is normally unnecessary => no clutter in the main window. Second, make 
created lags visible again in the main window to have them easily available for graphing, see above.


> 
> If someone stubbornly refused to use the console or scripts, we could have
> a menu item like "Create list with lags" (possibly right-clickable). Then
> the list containing the wanted lags appears as if it was a single series,
> and it can be included in the regression.

This approach would become unnecessary after the above imitation of PcGive's behavior, wouldn't it?

Just my 2c
Cheers,
Sven

--===============4080290725210773623==--


From heliosoft@oninetspeed.pt Wed Jan 18 10:51:50 2006
From: HelioSoft de =?utf-8?q?H=C3=A9lio?= Guilherme <heliosoft@oninetspeed.pt>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Hide or show lagged variables?
Date: Wed, 18 Jan 2006 15:51:31 +0000
Message-ID: <43CE6403.4030106@oninetspeed.pt>
In-Reply-To: Pine.LNX.4.64.0601140942240.32095@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2140227048910678035=="

--===============2140227048910678035==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
I not familiar with the programming on GDK environment, but wouldn't
be possible to have the lags columns shrinked or hidden, for user
option to view and use? They could have yellow pop-ups with the names,
when mouse over them. If possible, everyone would be happy with this :).

- -----

To Allin,
I'm using this way to tell you that I am been sending emails directly
to you but no reply (marked as junk, maybe?). I have the portuguese
web pages ready to publish on the Gretl site, so, please reply to me
for me to send them. Thanks.

Sorry list member for using this resource.

Hélio Guilherme.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
 
iD8DBQFDzmQDHvesJJ5UqvkRAkp/AJ9HbpuD8nptGADEXqAm4L4lVPMgeACgowO7
JDBkDFXAZ8ar5RlHwcmma14=
=4ErT
-----END PGP SIGNATURE-----



--===============2140227048910678035==--


From arnaud.bervas@banque-france.fr Wed Jan 18 13:05:51 2006
From: arnaud.bervas@banque-france.fr
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] gmm
Date: Wed, 18 Jan 2006 19:05:43 +0100
Message-ID:
 <0BFD17B796FD8D498604AB3F446C7B2703E4B5FC@MS1101E4.intra.bdf.local>
Content-Type: multipart/mixed; boundary="===============8177730930190014859=="

--===============8177730930190014859==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4KPEhUTUw+PEhFQUQ+CjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11cy1hc2NpaSI+CjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2LjAw
LjI4MDAuMTUyOSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPgo8Qk9EWT4KPERJVj5TdXJlLCBidXQg
bXkgcXVlc3Rpb24gd2FzIHJhdGhlciBmb3IgbW9yZSBnZW5lcmFsIGVzdGltYXRvcnMgdGhhbiBP
TFMgCm9yPEJSPmV2ZW4gMlNMUyB3aXRoIGluc3RydW1lbnRhbCB2YXJpYWJsZXMuIEkgZGlkbid0
IGludGVuZCB0byBydW4gYSAKZHluYW1pYzxCUj5wYW5lbCByZWdyZXNzaW9uIHdpdGggQXJlbGxh
bm8gYW5kIEJvbmQgZXN0aW1hdG9yIHRob3VnaC4gQWN0dWFsbHksIEkgCndhczxCUj53b25kZXJp
bmcgaWYgaXQgd291bGQgYmUgcG9zc2libGUgdG8gZXN0aW1hdGUgRXVsZXIgZXF1YXRpb25zIGRl
cml2ZWQgCmZyb20gYTxCUj5DQ0FQTSBtb2RlbCBmb3IgaW5zdGFuY2UuSSBndWVzcyBpdCdzIG5v
dCBwb3NzaWJsZSB0byBwcm9ncmFtIHRoZSAKaW1wbGllZDxCUj5udW1lcmljYWwgb3B0aW1pemF0
aW9uIHdpdGggR3JldGwgaW4gaXRzIGN1cnJlbnQgCnN0YXRlLjxCUj48QlI+PC9ESVY+PHByZT4q
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKgpDZSBtZWwgZXN0IGEgbCdhdHRlbnRpb24gZXhjbHVzaXZlIGRlcyBkZXN0aW5hdGFpcmVz
IGRlc2lnbmVzLgpJbCBwZXV0IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs
bGVzLgpTaSB2b3VzIGxlIHJlY2V2ZXogcGFyIGVycmV1ciwgbWVyY2kgZCdlbiBpbmZvcm1lciBz
YW5zIGRlbGFpIGwnZXhwZWRpdGV1ci4KIApMZSBjb250ZW51IGRlIGNlIG1lbCBuZSBwb3VycmFp
dCBlbmdhZ2VyIGxhIHJlc3BvbnNhYmlsaXRlIGRlIGxhIEJhbnF1ZSBkZSBGcmFuY2UKcXVlIHMn
aWwgYSBldGUgZW1pcyBwYXIgdW5lIHBlcnNvbm5lIGR1bWVudCBoYWJpbGl0ZWUgYWdpc3NhbnQg
ZGFucyBsZSBzdHJpY3QKY2FkcmUgZGVzIGZvbmN0aW9ucyBhdXhxdWVsbGVzIGVsbGUgZXN0IGVt
cGxveWVlIGV0IGEgZGVzIGZpbnMgbm9uIGV0cmFuZ2VyZXMgYSBzZXMgYXR0cmlidXRpb25zLgoq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqCjwvcHJlPjwvQk9EWT48L0hUTUw+Cg==

--===============8177730930190014859==--


From jack@deanovell.unian.it Wed Jan 18 16:44:50 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] gmm
Date: Wed, 18 Jan 2006 22:44:51 +0100
Message-ID: <Pine.LNX.4.44.0601182236500.28524-100000@ec-4.econ.univpm.it>
In-Reply-To: BAY104-F15B651E275D4E863420360BF1A0@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0841418635824853298=="

--===============0841418635824853298==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Tue, 17 Jan 2006, Arnaud Bervas wrote:

> Sure, but my question was rather for more general estimators than OLS or
> even 2SLS with instrumental variables. I didn't intend to run a dynamic
> panel regression with Arellano and Bond estimator though. Actually, I was
> wondering if it would be possible to estimate Euler equations derived from a
> CCAPM model for instance.I guess it's not possible to program the implied
> numerical optimization with Gretl in its current state.

No, it's not possible at the moment. I suspect you could fool mle or nls
into doing it, but it would definitely require some acrobatics. The good
news is that adding GMM is probably doable in a few weeks (at least 1-step
GMM, but probably 2-step can be done in that timeframe too); the bad news
is that neither Allin (I presume) nor I are able at the moment to tackle
this, because we're rather busy with some new exciting things which
unfortunately have the potential for breaking a lot of existing stuff, so
it's going to take some time (but it'll be worth the wait).

If you can program in C, you're welcome to help ;-)

Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============0841418635824853298==--


From cottrell@wfu.edu Wed Jan 18 22:33:48 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] gretl work in progress (was Re: gmm)
Date: Wed, 18 Jan 2006 22:33:48 -0500
Message-ID: <Pine.LNX.4.64.0601182210390.2338@ricardo.ecn.wfu.edu>
In-Reply-To: Pine.LNX.4.44.0601182236500.28524-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============9057940268785302456=="

--===============9057940268785302456==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Wed, 18 Jan 2006, jack wrote:

> The good news is that adding GMM is probably doable in a few weeks 
> (at least 1-step GMM, but probably 2-step can be done in that 
> timeframe too); the bad news is that neither Allin (I presume) nor 
> I are able at the moment to tackle this, because we're rather busy 
> with some new exciting things...

I might just add a hint or two at what's going on (I agree, this is 
exciting).

* We're adding a general facility for defining and manipulating 
matrices.  This is fairly well advanced but needs more testing.  At 
present we have most of the standard matrix operators and functions 
implemented, using a syntax much like ox.  People using gretl CVS 
can read about this in the new manual chapter file, matrices.tex.

* We're also adding a general facility for "farming out" tasks from 
gretl to other programs that offer functionality not (yet) available 
in gretl.  We already do that to some extent with x12arima and 
tramo/seats, but Jack has developed a more general, elegant and 
efficient mechanism that will allow gretl to exchange binary 
information with external programs.  Ox is the primary target at 
present, but R is also a good candidate.

In combination, these facilities will greatly increase the 
opportunities for people to write functions (in gretl script, not C) 
that extend gretl's capabilites.

I'm also working (though this is at an early stage) on a gui 
interface to such "add-on functions".  The idea is you could 
download these from some repository, then open up a gui window 
showing what functions are available (and who wrote them, and what 
their purpose is), with the option of loading any functions of 
interest into gretl's workspace, where they could be used in scripts 
or at the gretl console.  Perhaps these add-on functions could even 
attach themselves at appropriate positions in the gretl menu 
structure, and hence become directly accessible via point-and-click.

Allin Cottrell


--===============9057940268785302456==--


From wmixon@berry.edu Thu Jan 19 07:46:28 2006
From: Wilson Mixon <wmixon@berry.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] gretl work in progress (was Re: gmm)
Date: Thu, 19 Jan 2006 07:46:23 -0500
Message-ID: <43CF8A1F.2000908@berry.edu>
In-Reply-To: Pine.LNX.4.64.0601182210390.2338@ricardo.ecn.wfu.edu
Content-Type: multipart/mixed; boundary="===============4297773565191612991=="

--===============4297773565191612991==
Content-Type: text/x-vcard
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="wmixon.vcf"
MIME-Version: 1.0

YmVnaW46dmNhcmQKZm46V2lsc29uIE1peG9uCm46TWl4b247V2lsc29uCmVtYWlsO2ludGVybmV0
OndtaXhvbkBiZXJyeS5lZHUKdGVsO3dvcms6NzA2IDI5MCAyNjc5CnRlbDtmYXg6NzA2IDIzOCA3
ODU0CnRlbDtob21lOjcwNiAyMzggNzY5NAp4LW1vemlsbGEtaHRtbDpUUlVFCnZlcnNpb246Mi4x
CmVuZDp2Y2FyZAoK

--===============4297773565191612991==--


From johnw2006@hotmail.com Thu Jan 19 08:15:19 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Variable name
Date: Thu, 19 Jan 2006 13:15:16 +0000
Message-ID: <BAY109-F11BAECF9EE086755AD70FFBF1C0@phx.gbl>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0450458705496922145=="

--===============0450458705496922145==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,
The Variable name on the main Gretl window is limited up to 8 characters.
This somethimes causes problems with duplicate variable names.
For example you can have diffs, logs, sesonal adjustment and  variable name 
like dL_VARNAME_sa. This is already over the limit. The problem occurs when 
importing data from other programs. Variable names are cut.

Is it possible to expand, in one of the next versions, the variable names 
from 8 to 16 characters?
There will still be enough place for Descriptive label.

Thank you.

Keep with good work!

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 
7.5 today! http://messenger.msn.co.uk


--===============0450458705496922145==--


From jack@deanovell.unian.it Thu Jan 19 11:57:35 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Variable name
Date: Thu, 19 Jan 2006 17:57:41 +0100
Message-ID: <Pine.LNX.4.44.0601191752430.15636-100000@ec-4.econ.univpm.it>
In-Reply-To: BAY109-F11BAECF9EE086755AD70FFBF1C0@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3370473652175353516=="

--===============3370473652175353516==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Thu, 19 Jan 2006, john w wrote:

> Hi,
> The Variable name on the main Gretl window is limited up to 8 characters.
> This somethimes causes problems with duplicate variable names.
> For example you can have diffs, logs, sesonal adjustment and  variable name
> like dL_VARNAME_sa. This is already over the limit. The problem occurs when
> importing data from other programs. Variable names are cut.
>
> Is it possible to expand, in one of the next versions, the variable names
> from 8 to 16 characters?
> There will still be enough place for Descriptive label.

I agree. In fact, I'd make it 32 characters. I can't see any technical
impediment, except going through the code to double-check everything will
be tedious and error-prone.

Allin, your opinion? If you agree, I can start working on this in the
next days.


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============3370473652175353516==--


From cottrell@wfu.edu Thu Jan 19 12:24:13 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Variable name
Date: Thu, 19 Jan 2006 12:24:13 -0500
Message-ID: <Pine.LNX.4.64.0601191202290.4936@ricardo.ecn.wfu.edu>
In-Reply-To: Pine.LNX.4.44.0601191752430.15636-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7699401286859242817=="

--===============7699401286859242817==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, 19 Jan 2006, jack wrote:

> On Thu, 19 Jan 2006, john w wrote:
>
>> Is it possible to expand, in one of the next versions, the variable names
>> from 8 to 16 characters?
>
> I agree. In fact, I'd make it 32 characters. I can't see any 
> technical impediment, except going through the code to 
> double-check everything will be tedious and error-prone.
>
> Allin, your opinion? If you agree, I can start working on this in 
> the next days.

I think this is basically a good idea (though I'd tend to go for 16 
characters, not 32, for regular variable names).  The main problem 
is with the various output-printing functions.  For both console 
output and the output that goes to gui windows, everything is in a 
fixed format.  Many of the output functions would have to be 
redesigned to avoid stuff breaking over lines given a wider variable 
name field.

One possible redesign that would save width on numeric output fields 
would be to print all numbers such as coefficients and standard 
errors in a fixed width, as opposed to gretl's current practice of 
using decimal-aligned numbers printed to a given number of 
significant figures, using scientific notation only when absolutely 
needed.  But I think gretl's current numeric output is nice and easy 
to read -- you can see the relative magnitude of coefficients at a 
glance.

That said, I don't claim that gretl's current regression output is 
perfect and I'm certainly willing to consider proposals for 
redesign, within an 80-column format.

Allin Cottrell





--===============7699401286859242817==--


From paravantis@hol.gr Thu Jan 19 15:58:24 2006
From: John Paravantis <paravantis@hol.gr>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Re: Gretl-users Digest, Vol 21, Issue 15
Date: Thu, 19 Jan 2006 22:58:18 +0200
Message-ID: <43CFFD6A.9030801@hol.gr>
In-Reply-To: 200601191700.k0JH029B005902@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0933646897836723470=="

--===============0933646897836723470==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

I should like to add my two pennies and say that expanding the 8 
characters limit in variable names is an OUTSTANDING and long overdue 
suggestion!

Even SPSS has gone to practically unlimited variable names in its latest 
versions.

John Paravantis
University of Piraeus

>The Variable name on the main Gretl window is limited up to 8 characters.
>This somethimes causes problems with duplicate variable names.
>For example you can have diffs, logs, sesonal adjustment and  variable name 
>like dL_VARNAME_sa. This is already over the limit. The problem occurs when 
>importing data from other programs. Variable names are cut.
>
>Is it possible to expand, in one of the next versions, the variable names 
>from 8 to 16 characters?
>There will still be enough place for Descriptive label.
>
>Thank you.
>  
>
>I agree. In fact, I'd make it 32 characters. I can't see any technical
>impediment, except going through the code to double-check everything will
>be tedious and error-prone.
>
>Allin, your opinion? If you agree, I can start working on this in the
>next days.
>
>
>Riccardo `Jack' Lucchetti
>Dipartimento di Economia
>Università Politecnica delle Marche
>
>jack(a)dea.unian.it
>http://www.econ.univpm.it/lucchetti
>  
>


--===============0933646897836723470==--


From johnw2006@hotmail.com Fri Jan 20 02:16:54 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Variable name and future requests
Date: Fri, 20 Jan 2006 07:16:52 +0000
Message-ID: <BAY109-F313CCE20A8FD01A5AFB84EBF1F0@phx.gbl>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8431712736890432401=="

--===============8431712736890432401==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Thank you very much for your answer.
I will be very greatefull if you expand variable name box.
I'm using Gretl from Wake Forrest University and I must say that plenty of 
things are made in last years. Good work guys.

But I also have some new suggestions for you...new features requests:
1. Data interpolation but from lower to high frequency data. Example from 
quarterlly to monthly.
2. The possibility to include exogenous variables in VAR/VECM.
3.Var inverse roots graph but followed with textual pop-up menu. It's 
difficult to see if some value is on or out the unit circle if it is close 
to the line.
4.FEVD followed by graph.
5. More stability tests for VAR/VECM (Cusum, breakpoint, 1-step Chow test, 
etc.)
6. F-tests of zero restrictions (Wald type Granger causality) for VECM.

This are only the suggestions. I know that you have plenty of work and 
unfortunatelly I'm not a programer so I can't help you.

Your comments are welcome!



>On Thu, 19 Jan 2006, john w wrote:
>
>>Is it possible to expand, in one of the next versions, the variable names
>>from 8 to 16 characters?
>
>I agree. In fact, I'd make it 32 characters. I can't see any technical 
>impediment, except going through the code to double-check everything will 
>be tedious and error-prone.
>
>Allin, your opinion? If you agree, I can start working on this in the next 
>days.

I think this is basically a good idea (though I'd tend to go for 16
characters, not 32, for regular variable names).  The main problem
is with the various output-printing functions.  For both console
output and the output that goes to gui windows, everything is in a
fixed format.  Many of the output functions would have to be
redesigned to avoid stuff breaking over lines given a wider variable
name field.

One possible redesign that would save width on numeric output fields
would be to print all numbers such as coefficients and standard
errors in a fixed width, as opposed to gretl's current practice of
using decimal-aligned numbers printed to a given number of
significant figures, using scientific notation only when absolutely
needed.  But I think gretl's current numeric output is nice and easy
to read -- you can see the relative magnitude of coefficients at a
glance.

That said, I don't claim that gretl's current regression output is
perfect and I'm certainly willing to consider proposals for
redesign, within an 80-column format.

Allin Cottrell






--------------------------------------------------------------------------------


Previous message: [Gretl-users] Variable name

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 
7.5 today! http://messenger.msn.co.uk


--===============8431712736890432401==--


From jack@deanovell.unian.it Fri Jan 20 04:13:52 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Variable name and future requests
Date: Fri, 20 Jan 2006 10:13:56 +0100
Message-ID: <Pine.LNX.4.44.0601200941360.17570-100000@ec-4.econ.univpm.it>
In-Reply-To: BAY109-F313CCE20A8FD01A5AFB84EBF1F0@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7809539542877145062=="

--===============7809539542877145062==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Fri, 20 Jan 2006, john w wrote:

> But I also have some new suggestions for you...new features requests:
> 1. Data interpolation but from lower to high frequency data. Example from
> quarterlly to monthly.

I don't remember if this is in 1.5.0 (I think it is), but it's definitely
in CVS.

> 2. The possibility to include exogenous variables in VAR/VECM.

Already in 1.5.0. From a script or console, you do, for example

vecm 2 1 endog1 endog2 ; exog1 exog2 --nc

In the gui you get a nice box where you can put your exogenous variables.

> 3.Var inverse roots graph but followed with textual pop-up menu. It's
> difficult to see if some value is on or out the unit circle if it is close
> to the line.

That's a bit tricky. If you need to edit the graph, here's a workaround:
1) Right-click -> Save as Icon
2) Session->Icon View
3) Select graph->right-click-Edit code

> 4.FEVD followed by graph.

Doable. It would help if you provided a gnuplot script to show us the way
you'd like it.

> 5. More stability tests for VAR/VECM (Cusum, breakpoint, 1-step Chow test,
> etc.)

Doable.

> 6. F-tests of zero restrictions (Wald type Granger causality) for VECM.

Doable for tests which EITHER do not involve beta OR only involve beta.
Much harder for general tests; as you probably know, Granger-causality
tests (and Wald tests in general) in cointegrated systems are not always
easy-as-pie, due to the different convergence rates among parameters.
Obligatory references:

Toda, Hiro Y & Phillips, Peter C B, 1993. "Vector Autoregressions and
Causality," Econometrica, Econometric Society, vol. 61(6), pages 1367-93.

Dolado, J.J., Lutkepohl, H. (1996), "Making wald tests work for
cointegrated VAR systems", Econometrics Reviews, Vol. 15 pp.369-86.


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti




--===============7809539542877145062==--


From Ignacio.Diaz-Emparanza@ehu.es Fri Jan 20 04:26:21 2006
From: Ignacio =?utf-8?q?D=C3=ADaz-Emparanza?= <Ignacio.Diaz-Emparanza@ehu.es>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Variable name and future requests
Date: Fri, 20 Jan 2006 10:26:11 +0100
Message-ID: <200601201026.11505.Ignacio.Diaz-Emparanza@ehu.es>
In-Reply-To: BAY109-F313CCE20A8FD01A5AFB84EBF1F0@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2418604756733999074=="

--===============2418604756733999074==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

El Viernes, 20 de Enero de 2006 08:16, john w escribió:
>...
> But I also have some new suggestions for you...new features requests:
> 1. Data interpolation but from lower to high frequency data. Example from
> quarterlly to monthly.
> 2. The possibility to include exogenous variables in VAR/VECM.
> 3.Var inverse roots graph but followed with textual pop-up menu. It's
> difficult to see if some value is on or out the unit circle if it is close
> to the line.
> 4.FEVD followed by graph.
> 5. More stability tests for VAR/VECM (Cusum, breakpoint, 1-step Chow test,
> etc.)
> 6. F-tests of zero restrictions (Wald type Granger causality) for VECM.
>
> This are only the suggestions. I know that you have plenty of work and
> unfortunatelly I'm not a programer so I can't help you.
>
> Your comments are welcome!
>

I am sure Allin and Jack  will have your suggestions into account.

This message is to highlight that non programers (as myself) may
also help with a free software project as gretl:

1- Reporting bugs (probably the most important work)
2- Offering suggestions for ways to improve gretl.
3- Writing new documentation: tutorials, guides, etc.
4- Reporting about their way to use gretl (cases of study).
5- Translating to new languages or collaborating with the existent 
translations.

-- 
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU


--===============2418604756733999074==--


From johnw2006@hotmail.com Fri Jan 20 04:46:17 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Variable name and future requests
Date: Fri, 20 Jan 2006 09:46:13 +0000
Message-ID: <BAY109-F32084C40F6204D06B481DEBF1F0@phx.gbl>
In-Reply-To: 200601201026.11505.Ignacio.Diaz-Emparanza@ehu.es
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4171016714828799617=="

--===============4171016714828799617==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

I'm sure they will!
Unfortunatelly I don't have a lot of free time due to my work. Regarding:
1. I use Gretl from Wake Forrest (which is more up to date) so I can report 
bugs from this version.
2. Always.
5. Maybe I could help with translation of Gretl on Croatian language if 
users are interested. This will cover almost all ex Yugoslavian republic as 
almost all from them understand and write Croatian language.


>From: Ignacio Díaz-Emparanza<Ignacio.Diaz-Emparanza(a)ehu.es>
>Reply-To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>To: gretl-users(a)ricardo.ecn.wfu.edu
>Subject: Re: [Gretl-users] Variable name and future requests
>Date: Fri, 20 Jan 2006 10:26:11 +0100
>
>El Viernes, 20 de Enero de 2006 08:16, john w escribió:
> >...
> > But I also have some new suggestions for you...new features requests:
> > 1. Data interpolation but from lower to high frequency data. Example 
>from
> > quarterlly to monthly.
> > 2. The possibility to include exogenous variables in VAR/VECM.
> > 3.Var inverse roots graph but followed with textual pop-up menu. It's
> > difficult to see if some value is on or out the unit circle if it is 
>close
> > to the line.
> > 4.FEVD followed by graph.
> > 5. More stability tests for VAR/VECM (Cusum, breakpoint, 1-step Chow 
>test,
> > etc.)
> > 6. F-tests of zero restrictions (Wald type Granger causality) for VECM.
> >
> > This are only the suggestions. I know that you have plenty of work and
> > unfortunatelly I'm not a programer so I can't help you.
> >
> > Your comments are welcome!
> >
>
>I am sure Allin and Jack  will have your suggestions into account.
>
>This message is to highlight that non programers (as myself) may
>also help with a free software project as gretl:
>
>1- Reporting bugs (probably the most important work)
>2- Offering suggestions for ways to improve gretl.
>3- Writing new documentation: tutorials, guides, etc.
>4- Reporting about their way to use gretl (cases of study).
>5- Translating to new languages or collaborating with the existent
>translations.
>
>--
>Ignacio Díaz-Emparanza
>Dpto. de Economía Aplicada III (Econometría y Estadística)
>UPV-EHU
>
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 
7.5 today! http://messenger.msn.co.uk



--===============4171016714828799617==--


From johnw2006@hotmail.com Fri Jan 20 04:59:33 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Variable name and future requests
Date: Fri, 20 Jan 2006 09:59:32 +0000
Message-ID: <BAY109-F25E5F38152AB1AA842722BF1F0@phx.gbl>
In-Reply-To: Pine.LNX.4.44.0601200941360.17570-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4303003924110550240=="

--===============4303003924110550240==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Thank you for your quick answer!
Yes, I use CVS version.
Regarding
1. There is Compact data option but only to convert higher to lower 
frequency not viceversa.
2. Thnx.
3. Will be nice. Thnx.
4. Ok. I'll try.
5. Thnx.
6. Ok. Thnx. There are some examples of this tests in JMulTi (also on 
Sourceforge. But in Jawa). You can test group Granger causality in VECM and 
you also have an option to impose zero restrictions on parameters (LR test).



>From: jack <jack(a)deanovell.unian.it>
>Reply-To: jack(a)deanovell.unian.it,        Gretl list 
><gretl-users(a)ricardo.ecn.wfu.edu>
>To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] Variable name and future requests
>Date: Fri, 20 Jan 2006 10:13:56 +0100 (CET)
>
>On Fri, 20 Jan 2006, john w wrote:
>
> > But I also have some new suggestions for you...new features requests:
> > 1. Data interpolation but from lower to high frequency data. Example 
>from
> > quarterlly to monthly.
>
>I don't remember if this is in 1.5.0 (I think it is), but it's definitely
>in CVS.
>
> > 2. The possibility to include exogenous variables in VAR/VECM.
>
>Already in 1.5.0. From a script or console, you do, for example
>
>vecm 2 1 endog1 endog2 ; exog1 exog2 --nc
>
>In the gui you get a nice box where you can put your exogenous variables.
>
> > 3.Var inverse roots graph but followed with textual pop-up menu. It's
> > difficult to see if some value is on or out the unit circle if it is 
>close
> > to the line.
>
>That's a bit tricky. If you need to edit the graph, here's a workaround:
>1) Right-click -> Save as Icon
>2) Session->Icon View
>3) Select graph->right-click-Edit code
>
> > 4.FEVD followed by graph.
>
>Doable. It would help if you provided a gnuplot script to show us the way
>you'd like it.
>
> > 5. More stability tests for VAR/VECM (Cusum, breakpoint, 1-step Chow 
>test,
> > etc.)
>
>Doable.
>
> > 6. F-tests of zero restrictions (Wald type Granger causality) for VECM.
>
>Doable for tests which EITHER do not involve beta OR only involve beta.
>Much harder for general tests; as you probably know, Granger-causality
>tests (and Wald tests in general) in cointegrated systems are not always
>easy-as-pie, due to the different convergence rates among parameters.
>Obligatory references:
>
>Toda, Hiro Y & Phillips, Peter C B, 1993. "Vector Autoregressions and
>Causality," Econometrica, Econometric Society, vol. 61(6), pages 1367-93.
>
>Dolado, J.J., Lutkepohl, H. (1996), "Making wald tests work for
>cointegrated VAR systems", Econometrics Reviews, Vol. 15 pp.369-86.
>
>
>Riccardo `Jack' Lucchetti
>Dipartimento di Economia
>Università Politecnica delle Marche
>
>jack(a)dea.unian.it
>http://www.econ.univpm.it/lucchetti
>
>
>
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
The new MSN Search Toolbar now includes Desktop search! 
http://toolbar.msn.co.uk/



--===============4303003924110550240==--


From jack@deanovell.unian.it Fri Jan 20 07:13:19 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Variable name and future requests
Date: Fri, 20 Jan 2006 13:13:22 +0100
Message-ID: <Pine.LNX.4.44.0601201310020.6829-100000@ec-4.econ.univpm.it>
In-Reply-To: BAY109-F25E5F38152AB1AA842722BF1F0@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6619578286787972540=="

--===============6619578286787972540==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Fri, 20 Jan 2006, john w wrote:

> Thank you for your quick answer!
> Yes, I use CVS version.
> Regarding
> 1. There is Compact data option but only to convert higher to lower
> frequency not viceversa.

If you open a quarterly dataset, you have "Expand data" right under
"Compact data" in the Sample menu

> 2. Thnx.
> 3. Will be nice. Thnx.
> 4. Ok. I'll try.
> 5. Thnx.
> 6. Ok. Thnx. There are some examples of this tests in JMulTi (also on
> Sourceforge. But in Jawa). You can test group Granger causality in VECM and
> you also have an option to impose zero restrictions on parameters (LR test).

Oh, that's interesting. I'll have a look at it. Not now. But I promise I
will! Honest!


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============6619578286787972540==--


From johnw2006@hotmail.com Fri Jan 20 07:34:28 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Variable name and future requests
Date: Fri, 20 Jan 2006 12:34:27 +0000
Message-ID: <BAY109-F35A5B7B175CF3D57AAE050BF1F0@phx.gbl>
In-Reply-To: Pine.LNX.4.44.0601201310020.6829-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0567564850934280428=="

--===============0567564850934280428==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Ok, thanks Jack.
If you need any help let me know.
JMulTi web: www.jmulti.com or www.jmulti.de
A realy good software.


>From: jack <jack(a)deanovell.unian.it>
>Reply-To: jack(a)deanovell.unian.it,        Gretl list 
><gretl-users(a)ricardo.ecn.wfu.edu>
>To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] Variable name and future requests
>Date: Fri, 20 Jan 2006 13:13:22 +0100 (CET)
>
>On Fri, 20 Jan 2006, john w wrote:
>
> > Thank you for your quick answer!
> > Yes, I use CVS version.
> > Regarding
> > 1. There is Compact data option but only to convert higher to lower
> > frequency not viceversa.
>
>If you open a quarterly dataset, you have "Expand data" right under
>"Compact data" in the Sample menu
>
> > 2. Thnx.
> > 3. Will be nice. Thnx.
> > 4. Ok. I'll try.
> > 5. Thnx.
> > 6. Ok. Thnx. There are some examples of this tests in JMulTi (also on
> > Sourceforge. But in Jawa). You can test group Granger causality in VECM 
>and
> > you also have an option to impose zero restrictions on parameters (LR 
>test).
>
>Oh, that's interesting. I'll have a look at it. Not now. But I promise I
>will! Honest!
>
>
>Riccardo `Jack' Lucchetti
>Dipartimento di Economia
>Università Politecnica delle Marche
>
>jack(a)dea.unian.it
>http://www.econ.univpm.it/lucchetti
>
>
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 
7.5 today! http://messenger.msn.co.uk



--===============0567564850934280428==--


From peter@tomatoad.com Sat Jan 21 10:30:21 2006
From: Peter Davidoff <peter@tomatoad.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] FREETYPE6.DLL
Date: Sat, 21 Jan 2006 08:35:35 -0700
Message-ID: <6.2.3.4.0.20060121083123.027b9a10@mail.frii.com>
In-Reply-To: Pine.LNX.4.64.0601191202290.4936@ricardo.ecn.wfu.edu
Content-Type: multipart/mixed; boundary="===============5837135897965205576=="

--===============5837135897965205576==
Content-Type: text/html
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="attachment.html"
MIME-Version: 1.0

PGh0bWw+Cjxib2R5Pgo8YnI+PGJyPgo8YnI+CkhlbGxvIEdyZXRsLWZvbGssPGJyPjxicj4KSSBh
bSB1c2luZyBHUkVUTCBpbiBhbiBlY29ub21ldHJpY3MgY2xhc3MgSSdtPGJyPgp0ZWFjaGluZyB0
aGlzIHNlbWVzdGVyLiZuYnNwOyBPbmUgb2YgbXkgc3R1ZGVudHMgaGFzPGJyPgpiZWVuIGhhdmlu
ZyBhIHByb2JsZW0gd2l0aCBHUkVUTCBncmFwaGljcyBvbiBoZXI8YnI+ClBDLiZuYnNwOyBJJ3Zl
IGFza2VkIGhlciB0byBkb3VibGUgY2hlY2sgdGhlIHBhdGhzIGluPGJyPgp0aGUgUFJFRiBkaWFs
b2d1ZS4mbmJzcDsgSGVyZSBpcyB3aGF0IHNoZSByZXBvcnRzOjxicj48YnI+CjxibG9ja3F1b3Rl
IHR5cGU9Y2l0ZSBjbGFzcz1jaXRlIGNpdGU9IiI+PGZvbnQgc2l6ZT0yPkkgbWFkZSBzdXJlIHRo
YXQKZ251cGxvdCB3YXMgbG9hZGVkIGJ1dCB3aGVuIEkgYXR0ZW1wdGVkIDxicj4KdG8gZ3JhcGgg
dGhlIGRhdGEgbXkgY29tcHV0ZXIgc2FpZCB0aGUgRExMIGZpbGUsIEZSRUVUWVBFNi5ETEwgPGJy
Pgp3YXMgbm90IGF2YWlsYWJsZSBhbmQgdGhhdCB0aGUgZ251cGxvdCBjb21tYW5kCmZhaWxlZC4u
LjwvZm9udD48L2Jsb2NrcXVvdGU+PGJyPgpJIGhhdmUgc3VnZ2VzdGVkIHRoYXQgc2hlIHVuaW5z
dGFsbCBHUkVUTCBhbmQgdGhlbiB0cnk8YnI+CmFuIGluc3RhbGwgYWdhaW4uJm5ic3A7IEkgYW0g
YXNzdW1pbmcgc2hlIGlzIHBvaW50aW5nIHRvIHdnbnVwbG90PGJyPgphcyB0aGVyZSBpc24ndCBh
IGdudXBsb3QgaW4gbXkgZGlyZWN0b3J5LiZuYnNwOyBBbnkgdGhvdWdodHM/PGJyPjxicj4KV2l0
aCB0aGFua3MsPGJyPjxicj4KUGV0ZXI8YnI+PGJyPgo8L2JvZHk+CjwvaHRtbD4KCg==

--===============5837135897965205576==--


From rguima@face.ufmg.br Sat Jan 21 13:02:06 2006
From: Raquel Rangel de Meireles Guimaraes <rguima@face.ufmg.br>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Variable name and future requests
Date: Sat, 21 Jan 2006 14:51:34 -0300
Message-ID: <20060121174631.M42502@face.ufmg.br>
In-Reply-To: 200601201026.11505.Ignacio.Diaz-Emparanza@ehu.es
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0322705600243803613=="

--===============0322705600243803613==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hi all,

It would be a pleasure to help to translate gretl into brazilian portuguese -
as a non programer, while I'm just a beginner in C++. Is someone already
working on this?

Best Regards,

Raquel Guimarães
Universidade Federal de Minas Gerais
Belo Horizonte, MG, Brazil



--
Esta mensagem foi verificada pelo  sistema  de
antivírus e acredita-se estar livre de perigo.
--




--===============0322705600243803613==--


From cottrell@wfu.edu Sat Jan 21 13:14:49 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] FREETYPE6.DLL
Date: Sat, 21 Jan 2006 13:14:49 -0500
Message-ID: <Pine.LNX.4.64.0601211308010.16020@ricardo.ecn.wfu.edu>
In-Reply-To: 6.2.3.4.0.20060121083123.027b9a10@mail.frii.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8339881083955934618=="

--===============8339881083955934618==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Sat, 21 Jan 2006, Peter Davidoff wrote:

> One of my students has been having a problem with GRETL graphics 
> on her PC.  I've asked her to double check the paths in the PREF 
> dialogue.  Here is what she reports:
>
>       I made sure that gnuplot was loaded but when I attempted
>       to graph the data my computer said the DLL file,
>       FREETYPE6.DLL
>       was not available and that the gnuplot command failed...
> 
> I have suggested that she uninstall GRETL and then try
> an install again. 

Probably a good idea.  The gretl installer comes with the files 
wgnuplot.exe and freetype6.dll, which are both placed in the main 
gretl installation directory (by default c:\userdata\gretl).  It 
should not be necessary to make any manual changes in paths to 
programs.

One possible scenario that can cause this sort of problem: (a) 
student installs gretl; (b) student then drags the whole gretl 
folder to some new location.  This will break things, since the 
actual paths will no longer correspond with those written into the 
Windows registry on installation.

Allin Cottrell


--===============8339881083955934618==--


From cottrell@wfu.edu Sat Jan 21 23:39:50 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] VAR roots plot
Date: Sat, 21 Jan 2006 23:39:50 -0500
Message-ID: <Pine.LNX.4.64.0601212337530.18051@ricardo.ecn.wfu.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2726899300556267426=="

--===============2726899300556267426==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Sorry, can't remember who mentioned this, but someone said it would 
be nice to see the numerical values of the roots in this plot.

This is done in CVS and will be in the next release: when you mouse 
over the "dot" representing a root you get a label showing the 
numerical value.

Allin Cottrell

--===============2726899300556267426==--


From cottrell@wfu.edu Sat Jan 21 23:44:43 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Variable name and future requests
Date: Sat, 21 Jan 2006 23:44:43 -0500
Message-ID: <Pine.LNX.4.64.0601212340480.18051@ricardo.ecn.wfu.edu>
In-Reply-To: 20060121174631.M42502@face.ufmg.br
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5155046722738903691=="

--===============5155046722738903691==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Sat, 21 Jan 2006, Raquel Rangel de Meireles Guimaraes wrote:

> It would be a pleasure to help to translate gretl into brazilian 
> portuguese - as a non programer, while I'm just a beginner in C++. 
> Is someone already working on this?

Sounds good!

I have to confess my ignorance as to how great the difference is 
between Brazilian Portuguese and Portuguese Portuguese, but you'll 
probably want to coordinate with Hélio Guilherme

heliosoft(a)oninetspeed.pt

who I think has made a start on this.  (I know that Hélio has 
translated the gretl web pages into Portuguese.)

Allin Cottrell

--===============5155046722738903691==--


From rguima@face.ufmg.br Sun Jan 22 06:37:36 2006
From: Raquel Rangel de Meireles Guimaraes <rguima@face.ufmg.br>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Variable name and future requests
Date: Sun, 22 Jan 2006 08:26:52 -0300
Message-ID: <20060122112146.M77171@face.ufmg.br>
In-Reply-To: Pine.LNX.4.64.0601212340480.18051@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5517357405072474879=="

--===============5517357405072474879==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Allin, 

There is, in my opinion, no significant difference between them. But, in the
future, perhaps it would be interessant..

I'll contact Helio to ask him if I could help with something!

Greetings,

Raquel Guimarães
Universidade Federal de Minas Gerais
Belo Horizonte, MG, Brazil



--
Esta mensagem foi verificada pelo  sistema  de
antivírus e acredita-se estar livre de perigo.
--




--===============5517357405072474879==--


From svetosch@gmx.net Sun Jan 22 09:21:48 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Sun, 22 Jan 2006 15:21:07 +0100
Message-ID: <43D394D3.30703@gmx.net>
In-Reply-To: Pine.LNX.4.64.0601212337530.18051@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6982580168409908651=="

--===============6982580168409908651==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin Cottrell schrieb:
> Sorry, can't remember who mentioned this, but someone said it would be
> nice to see the numerical values of the roots in this plot.
> 
> This is done in CVS and will be in the next release: when you mouse over
> the "dot" representing a root you get a label showing the numerical value.
> 

I'm not the one who asked for this, but if it is included (which is
great btw) I suggest to add the possibility of displaying the full list
of roots. Otherwise you need to write down the values by hand.

-sven

--===============6982580168409908651==--


From cottrell@wfu.edu Sun Jan 22 17:50:46 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Sun, 22 Jan 2006 17:50:46 -0500
Message-ID: <Pine.LNX.4.64.0601221750070.29748@ricardo.ecn.wfu.edu>
In-Reply-To: 43D394D3.30703@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3418042341663022595=="

--===============3418042341663022595==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Sun, 22 Jan 2006, Sven Schreiber wrote:

> Allin Cottrell schrieb:
>> Sorry, can't remember who mentioned this, but someone said it would be
>> nice to see the numerical values of the roots in this plot.
>>
>> This is done in CVS and will be in the next release: when you mouse over
>> the "dot" representing a root you get a label showing the numerical value.
>>
>
> I'm not the one who asked for this, but if it is included (which is
> great btw) I suggest to add the possibility of displaying the full list
> of roots. Otherwise you need to write down the values by hand.

That's a reasonable suggestion.  Should be doable.

Allin Cottrell

--===============3418042341663022595==--


From johnw2006@hotmail.com Mon Jan 23 02:22:12 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Mon, 23 Jan 2006 07:22:06 +0000
Message-ID: <BAY109-F894B9B1CDE28E8766D70FBF100@phx.gbl>
In-Reply-To: Pine.LNX.4.64.0601221750070.29748@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2710651987541929474=="

--===============2710651987541929474==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,
I mentioned VAR root plots.
Ok. Thank you. And I have another question/request.
What about Information criteria (AIC, BIC, HQ etc.) for selecting lags in 
VAR/VECM?
LR test for the longest lag (lag signifficance) is great but it would be 
nice to have Information criteria tests for choosen number of lags in one 
table.

What do you think?


>From: Allin Cottrell <cottrell(a)wfu.edu>
>Reply-To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] VAR roots plot
>Date: Sun, 22 Jan 2006 17:50:46 -0500 (EST)
>
>On Sun, 22 Jan 2006, Sven Schreiber wrote:
>
>>Allin Cottrell schrieb:
>>>Sorry, can't remember who mentioned this, but someone said it would be
>>>nice to see the numerical values of the roots in this plot.
>>>
>>>This is done in CVS and will be in the next release: when you mouse over
>>>the "dot" representing a root you get a label showing the numerical 
>>>value.
>>>
>>
>>I'm not the one who asked for this, but if it is included (which is
>>great btw) I suggest to add the possibility of displaying the full list
>>of roots. Otherwise you need to write down the values by hand.
>
>That's a reasonable suggestion.  Should be doable.
>
>Allin Cottrell
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! 
http://www.msn.co.uk/newsletters


--===============2710651987541929474==--


From jack@deanovell.unian.it Mon Jan 23 04:28:56 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Mon, 23 Jan 2006 10:28:51 +0100
Message-ID: <Pine.LNX.4.44.0601231007070.9922-100000@ec-4.econ.univpm.it>
In-Reply-To: BAY109-F894B9B1CDE28E8766D70FBF100@phx.gbl
Content-Type: multipart/mixed; boundary="===============4654161921583787960=="

--===============4654161921583787960==
Content-Type: chemical/x-gamess-input
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="var_autolag.inp"
MIME-Version: 1.0

ZnVuY3Rpb24gdmFyX2F1dG9sYWcgY2xlYXIKZnVuY3Rpb24gdmFyX2F1dG9sYWcobGlzdCBYLCBs
aXN0IFosIHNjYWxhciBtYXhsYWcpCgojIFg6IFZBUiB2YXJpYWJsZXMKIyBaOiBleG9nZW5vdXMg
dmFyaWFibGVzIChtYXkgYmUgbnVsbCkKIyBtYXhsYWc6IG1heGltdW0gbGFnIHRvIHRyeQogCiAg
ICBzZXQgZWNobyBvZmYKICAgIHNldCBtZXNzYWdlcyBvZmYKICAgIG1hdHJpeCBzbGFnID0geyAw
ICwgMCB9CiAgICBtYXRyaXggbWluY3JpdCA9IHsgMS4wRTIwICwgMS4wRTIwIH0KICAgIG1hdHJp
eCBjcml0ID0gemVyb3MobWF4bGFnLDIpCiAgICBzY2FsYXIgdG1wID0gMAoKICAgIGxvb3AgZm9y
IGk9MS4ubWF4bGFnCgogICAgICAgIHRtcCA9IG5lbGVtKFopCglpZiAodG1wPjApCiAgICAgICAg
ICAgIHZhciAkaSBYIDsgWiAtLXF1aWV0CiAgICAgICAgZWxzZSAKICAgICAgICAgICAgdmFyICRp
IFggLS1xdWlldAoJZW5kaWYKCiAgICAgICAgdG1wID0gJGFpYwoJY3JpdFskaSwxXSA9IHRtcAog
ICAgICAgIGlmICh0bXA8bWluY3JpdFsxXSkKICAgICAgICAgICAgbWluY3JpdFsxXSA9IHRtcAog
ICAgICAgICAgICBzbGFnWzFdID0gJGkKICAgICAgICBlbmRpZgogICAgICAgIHRtcCA9ICRiaWMK
CWNyaXRbJGksMl0gPSB0bXAKICAgICAgICBpZiAodG1wPG1pbmNyaXRbMl0pCiAgICAgICAgICAg
IG1pbmNyaXRbMl0gPSB0bXAKICAgICAgICAgICAgc2xhZ1syXSA9ICRpCiAgICAgICAgZW5kaWYK
CiAgICBlbmQgbG9vcAoKICAgIG1hdHJpeCBjcml0CgogICAgcHJpbnRmICJBdXRvbWF0aWMgbGFn
IHNlbGVjdGlvblxuICBBSUMgPSAlZCwgQklDID0gJWRcbiIsIHNsYWdbMV0sIHNsYWdbMl0KCiAg
ICByZXR1cm4gbWF0cml4IHNsYWcKCmVuZCBmdW5jdGlvbgo=

--===============4654161921583787960==
Content-Type: chemical/x-gamess-input
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="var_autolag_ex.inp"
MIME-Version: 1.0

b3BlbiBkZW5tYXJrCgppbmNsdWRlIHZhcl9hdXRvbGFnLmlucAoKbGlzdCBYID0gMSAyIDMgNAps
aXN0IFogPSBudWxsCgp2YXJfYXV0b2xhZyhYLFosNCkKCg==

--===============4654161921583787960==--


From johnw2006@hotmail.com Mon Jan 23 05:12:25 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Mon, 23 Jan 2006 10:12:18 +0000
Message-ID: <BAY109-F251E03F15A78C76D0344BCBF100@phx.gbl>
In-Reply-To: Pine.LNX.4.44.0601231007070.9922-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3419236845976849544=="

--===============3419236845976849544==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Thnx Jack.
1. This could be done for VECM too?
2. function var_autolag(list X, list Z, scalar maxlag). X,Z and maxlag must 
be changed manually?
    If there are no exogenous then Z must be 0?
3. In your previous mails you mentioned GUI. Where I can download GUI (if 
you have some link)?

Thank you again.


>From: jack <jack(a)deanovell.unian.it>
>Reply-To: jack(a)deanovell.unian.it,        Gretl list 
><gretl-users(a)ricardo.ecn.wfu.edu>
>To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] VAR roots plot
>Date: Mon, 23 Jan 2006 10:28:51 +0100 (CET)
>
>On Mon, 23 Jan 2006, john w wrote:
>
> > Hi,
> > I mentioned VAR root plots.
> > Ok. Thank you. And I have another question/request.
> > What about Information criteria (AIC, BIC, HQ etc.) for selecting lags 
>in
> > VAR/VECM?
> > LR test for the longest lag (lag signifficance) is great but it would be
> > nice to have Information criteria tests for choosen number of lags in 
>one
> > table.
> >
> > What do you think?
>
>This is rather easy to do. However, a dedicated function does the job
>nicely too. See the attached files.
>
>
>Riccardo `Jack' Lucchetti
>Dipartimento di Economia
>Università Politecnica delle Marche
>
>jack(a)dea.unian.it
>http://www.econ.univpm.it/lucchetti


><< var_autolag.inp >>


><< var_autolag_ex.inp >>


>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! 
http://www.msn.co.uk/newsletters



--===============3419236845976849544==--


From jack@deanovell.unian.it Mon Jan 23 05:36:32 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Mon, 23 Jan 2006 11:36:29 +0100
Message-ID: <Pine.LNX.4.44.0601231126010.10185-100000@ec-4.econ.univpm.it>
In-Reply-To: BAY109-F251E03F15A78C76D0344BCBF100@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7606599727239295273=="

--===============7606599727239295273==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Mon, 23 Jan 2006, john w wrote:

> Thnx Jack.
> 1. This could be done for VECM too?

Yes, of course, although normally you select the lag length first on
the VAR representation and only then you work on the cointegration rank.
But again, you can write a similar function for vecms rather easily.

> 2. function var_autolag(list X, list Z, scalar maxlag). X,Z and maxlag must
> be changed manually?
>     If there are no exogenous then Z must be 0?

The function is meant to be used from within a script. I thought the file
var_autolag_ex was self-explanatory (but obviously wasn't :-))

You can either write a script or run the following commands in a gretl
console:
1) run "include var_autolag.inp" to load the function in memory
2) define the lists with any name you want; for example
	list foo = x1 x2
	list bar = z1 z2
   with the proviso that you can use the syntax
	list bar = null
   for an empty list.
3) run
	var_autolag(foo,bar,4)
   or
	autolags = var_autolag(foo,bar,4)
   if you want to save the results in a vector (may be useful for futher
   processing)

> 3. In your previous mails you mentioned GUI. Where I can download GUI (if
> you have some link)?

Oh, sorry, GUI stands for "Graphical User Interface". What I meant is
"what you get by running the graphical version of gretl rather than the
command-line version".


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============7606599727239295273==--


From johnw2006@hotmail.com Mon Jan 23 06:39:30 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Mon, 23 Jan 2006 11:39:24 +0000
Message-ID: <BAY109-F3825CC06E1ADB0198FE745BF100@phx.gbl>
In-Reply-To: Pine.LNX.4.44.0601231126010.10185-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8650642469654366603=="

--===============8650642469654366603==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Thank you Jack. I'll try.
Regarding my point 3.  In Gretl VAR module (GUI) deterministic variables 
covers trend and exogenous variables?
This is from Gretl help: ...any "deterministic" or exogenous terms ...

In VECM module the terminology is quite clear, but in VAR module a little 
bit cunfuses me.
My suggestion for VAR module is:
1. To include one more check option for including a trend (like for a 
constant),
2. To replace "Deterministic variables" with "Exogenous variables".


>From: jack <jack(a)deanovell.unian.it>
>Reply-To: jack(a)deanovell.unian.it,        Gretl list 
><gretl-users(a)ricardo.ecn.wfu.edu>
>To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] VAR roots plot
>Date: Mon, 23 Jan 2006 11:36:29 +0100 (CET)
>
>On Mon, 23 Jan 2006, john w wrote:
>
> > Thnx Jack.
> > 1. This could be done for VECM too?
>
>Yes, of course, although normally you select the lag length first on
>the VAR representation and only then you work on the cointegration rank.
>But again, you can write a similar function for vecms rather easily.
>
> > 2. function var_autolag(list X, list Z, scalar maxlag). X,Z and maxlag 
>must
> > be changed manually?
> >     If there are no exogenous then Z must be 0?
>
>The function is meant to be used from within a script. I thought the file
>var_autolag_ex was self-explanatory (but obviously wasn't :-))
>
>You can either write a script or run the following commands in a gretl
>console:
>1) run "include var_autolag.inp" to load the function in memory
>2) define the lists with any name you want; for example
>	list foo = x1 x2
>	list bar = z1 z2
>    with the proviso that you can use the syntax
>	list bar = null
>    for an empty list.
>3) run
>	var_autolag(foo,bar,4)
>    or
>	autolags = var_autolag(foo,bar,4)
>    if you want to save the results in a vector (may be useful for futher
>    processing)
>
> > 3. In your previous mails you mentioned GUI. Where I can download GUI 
>(if
> > you have some link)?
>
>Oh, sorry, GUI stands for "Graphical User Interface". What I meant is
>"what you get by running the graphical version of gretl rather than the
>command-line version".
>
>
>Riccardo `Jack' Lucchetti
>Dipartimento di Economia
>Università Politecnica delle Marche
>
>jack(a)dea.unian.it
>http://www.econ.univpm.it/lucchetti
>
>
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! 
http://www.msn.co.uk/newsletters



--===============8650642469654366603==--


From jack@deanovell.unian.it Mon Jan 23 07:05:38 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Mon, 23 Jan 2006 13:05:35 +0100
Message-ID: <Pine.LNX.4.44.0601231255270.10639-100000@ec-4.econ.univpm.it>
In-Reply-To: BAY109-F3825CC06E1ADB0198FE745BF100@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2590267825104850264=="

--===============2590267825104850264==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Mon, 23 Jan 2006, john w wrote:

> Thank you Jack. I'll try.
> Regarding my point 3.  In Gretl VAR module (GUI) deterministic variables
> covers trend and exogenous variables?
> This is from Gretl help: ...any "deterministic" or exogenous terms ...
>
> In VECM module the terminology is quite clear, but in VAR module a little
> bit cunfuses me.
> My suggestion for VAR module is:
> 1. To include one more check option for including a trend (like for a
> constant),

The way the source code is now, that would be a little inconvenient,
unless we're willing to add a "--trend" option to rhe "var" command. I
wouldn't be against it, but adding a trend to a VAR is also very easy now,
and such an option would be a tad gratuitous. Hence, I'm not either
strongly pro nor against such a change. What do other list members think?

> 2. To replace "Deterministic variables" with "Exogenous variables".

Any adjective you use in this context is rather arbitrary. The word
"exogenous" may mean at least 4 different things in the econometrics
literature, so my very personal preference is for using it as sparingly as
possible, unless the context makes what I mean very clear. But others may
disagree.


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============2590267825104850264==--


From johnw2006@hotmail.com Mon Jan 23 07:13:31 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Mon, 23 Jan 2006 12:13:25 +0000
Message-ID: <BAY109-F27E508F1469BA4BAD5DE5ABF100@phx.gbl>
In-Reply-To: Pine.LNX.4.44.0601231255270.10639-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3474996459271554110=="

--===============3474996459271554110==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

You are wrigt Jack.
At the end, it's better to work on completely new features rather than 
spending time on cosmetics. Let it stay.


>From: jack <jack(a)deanovell.unian.it>
>Reply-To: jack(a)deanovell.unian.it,        Gretl list 
><gretl-users(a)ricardo.ecn.wfu.edu>
>To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] VAR roots plot
>Date: Mon, 23 Jan 2006 13:05:35 +0100 (CET)
>
>On Mon, 23 Jan 2006, john w wrote:
>
> > Thank you Jack. I'll try.
> > Regarding my point 3.  In Gretl VAR module (GUI) deterministic variables
> > covers trend and exogenous variables?
> > This is from Gretl help: ...any "deterministic" or exogenous terms ...
> >
> > In VECM module the terminology is quite clear, but in VAR module a 
>little
> > bit cunfuses me.
> > My suggestion for VAR module is:
> > 1. To include one more check option for including a trend (like for a
> > constant),
>
>The way the source code is now, that would be a little inconvenient,
>unless we're willing to add a "--trend" option to rhe "var" command. I
>wouldn't be against it, but adding a trend to a VAR is also very easy now,
>and such an option would be a tad gratuitous. Hence, I'm not either
>strongly pro nor against such a change. What do other list members think?
>
> > 2. To replace "Deterministic variables" with "Exogenous variables".
>
>Any adjective you use in this context is rather arbitrary. The word
>"exogenous" may mean at least 4 different things in the econometrics
>literature, so my very personal preference is for using it as sparingly as
>possible, unless the context makes what I mean very clear. But others may
>disagree.
>
>
>Riccardo `Jack' Lucchetti
>Dipartimento di Economia
>Università Politecnica delle Marche
>
>jack(a)dea.unian.it
>http://www.econ.univpm.it/lucchetti
>
>
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 
7.5 today! http://messenger.msn.co.uk



--===============3474996459271554110==--


From svetosch@gmx.net Mon Jan 23 07:29:57 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Mon, 23 Jan 2006 13:30:53 +0100
Message-ID: <43D4CC7D.7010501@gmx.net>
In-Reply-To: BAY109-F27E508F1469BA4BAD5DE5ABF100@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8694141159775712845=="

--===============8694141159775712845==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

john w schrieb:
> You are wrigt Jack.
> At the end, it's better to work on completely new features rather than
> spending time on cosmetics. Let it stay.
> 

don't give up so quickly ;-)

>> >
>> > In VECM module the terminology is quite clear, but in VAR module a
>> little
>> > bit cunfuses me.
>> > My suggestion for VAR module is:
>> > 1. To include one more check option for including a trend (like for a
>> > constant),
>>
>> The way the source code is now, that would be a little inconvenient,
>> unless we're willing to add a "--trend" option to rhe "var" command. I
>> wouldn't be against it, but adding a trend to a VAR is also very easy
>> now,
>> and such an option would be a tad gratuitous. Hence, I'm not either
>> strongly pro nor against such a change. What do other list members think?

I would (mildly) favor consistency for the interface of VARs and VECMs, but it's not terribly important.

>>
>> > 2. To replace "Deterministic variables" with "Exogenous variables".
>>
>> Any adjective you use in this context is rather arbitrary. The word
>> "exogenous" may mean at least 4 different things in the econometrics
>> literature, so my very personal preference is for using it as
>> sparingly as
>> possible, unless the context makes what I mean very clear. But others may
>> disagree.

In this context "deterministic" seems wrong, because you can add any variable you like. "Exogenous"
may not be precise, but at least it's correct. So I think john w is right and it should be changed
(that way it's also consistent with the vecm formulation).

cheers,
sven

--===============8694141159775712845==--


From johnw2006@hotmail.com Mon Jan 23 07:40:53 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Mon, 23 Jan 2006 12:40:47 +0000
Message-ID: <BAY109-F37D32732E605DAA073AAAABF100@phx.gbl>
In-Reply-To: 43D4CC7D.7010501@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2529040961297804717=="

--===============2529040961297804717==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Ah ah my friend. Never! :)))
Look how many posts are mine.

Always forward!
But as I see they are only two (Allin and Jack). Let's insist on new 
features firstly.


>From: Sven Schreiber <svetosch(a)gmx.net>
>Reply-To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] VAR roots plot
>Date: Mon, 23 Jan 2006 13:30:53 +0100
>
>john w schrieb:
> > You are wrigt Jack.
> > At the end, it's better to work on completely new features rather than
> > spending time on cosmetics. Let it stay.
> >
>
>don't give up so quickly ;-)
>
> >> >
> >> > In VECM module the terminology is quite clear, but in VAR module a
> >> little
> >> > bit cunfuses me.
> >> > My suggestion for VAR module is:
> >> > 1. To include one more check option for including a trend (like for a
> >> > constant),
> >>
> >> The way the source code is now, that would be a little inconvenient,
> >> unless we're willing to add a "--trend" option to rhe "var" command. I
> >> wouldn't be against it, but adding a trend to a VAR is also very easy
> >> now,
> >> and such an option would be a tad gratuitous. Hence, I'm not either
> >> strongly pro nor against such a change. What do other list members 
>think?
>
>I would (mildly) favor consistency for the interface of VARs and VECMs, but 
>it's not terribly important.
>
> >>
> >> > 2. To replace "Deterministic variables" with "Exogenous variables".
> >>
> >> Any adjective you use in this context is rather arbitrary. The word
> >> "exogenous" may mean at least 4 different things in the econometrics
> >> literature, so my very personal preference is for using it as
> >> sparingly as
> >> possible, unless the context makes what I mean very clear. But others 
>may
> >> disagree.
>
>In this context "deterministic" seems wrong, because you can add any 
>variable you like. "Exogenous"
>may not be precise, but at least it's correct. So I think john w is right 
>and it should be changed
>(that way it's also consistent with the vecm formulation).
>
>cheers,
>sven
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
The new MSN Search Toolbar now includes Desktop search! 
http://toolbar.msn.co.uk/


--===============2529040961297804717==--


From svetosch@gmx.net Mon Jan 23 08:03:11 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Mon, 23 Jan 2006 14:04:09 +0100
Message-ID: <43D4D449.2040200@gmx.net>
In-Reply-To: BAY109-F37D32732E605DAA073AAAABF100@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8870376854954214044=="

--===============8870376854954214044==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

john w schrieb:
> Ah ah my friend. Never! :)))
> Look how many posts are mine.
> 
> Always forward!
> But as I see they are only two (Allin and Jack). Let's insist on new
> features firstly.
> 

Well, changing one word to another is not going to prevent them from adding new features, I'd say.
And I think a good and consistent user interface is very important especially for a program like
gretl. In terms of raw econometric and number-crunching features there are quite a few alternatives
out there. What sets gretl apart (imho) is mainly (but not only, of course) the intuitive interface.

-sven


--===============8870376854954214044==--


From jack@deanovell.unian.it Mon Jan 23 08:13:22 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Mon, 23 Jan 2006 14:13:15 +0100
Message-ID: <Pine.LNX.4.44.0601231410070.10867-100000@ec-4.econ.univpm.it>
In-Reply-To: 43D4CC7D.7010501@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7172792751397529940=="

--===============7172792751397529940==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 23 Jan 2006, Sven Schreiber wrote:

> >> Any adjective you use in this context is rather arbitrary. The word
> >> "exogenous" may mean at least 4 different things in the econometrics
> >> literature, so my very personal preference is for using it as
> >> sparingly as
> >> possible, unless the context makes what I mean very clear. But others may
> >> disagree.
>
> In this context "deterministic" seems wrong, because you can add any variab=
le you like. "Exogenous"
> may not be precise, but at least it's correct. So I think john w is right a=
nd it should be changed
> (that way it's also consistent with the vecm formulation).

Well, as the Brits say, "you can, but you may not"! Anyway, if the word
"dterministic" is perceived as (potentially) misleading, that's a
good enough reason to change it IMO.

Allin?


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Universit=C3=A0 Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============7172792751397529940==--


From johnw2006@hotmail.com Mon Jan 23 08:21:01 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] VAR roots plot
Date: Mon, 23 Jan 2006 13:20:55 +0000
Message-ID: <BAY109-F18E7036B981846655F4605BF100@phx.gbl>
In-Reply-To: 43D4D449.2040200@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2490450938146976331=="

--===============2490450938146976331==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

I have a feeling that in the next version this few things will be corrected.
As I said, I insist on Exogenous rather than Deterministic (only for const 
and trend).
In the most of the literature I found so (software too).
Average user must know what in VAR terminology means exogenous and what is 
weakly exogenous in VECM terminology. This is my opinion.

Ok. Now I see that we are two for these changes.


>From: Sven Schreiber <svetosch(a)gmx.net>
>Reply-To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] VAR roots plot
>Date: Mon, 23 Jan 2006 14:04:09 +0100
>
>john w schrieb:
> > Ah ah my friend. Never! :)))
> > Look how many posts are mine.
> >
> > Always forward!
> > But as I see they are only two (Allin and Jack). Let's insist on new
> > features firstly.
> >
>
>Well, changing one word to another is not going to prevent them from adding 
>new features, I'd say.
>And I think a good and consistent user interface is very important 
>especially for a program like
>gretl. In terms of raw econometric and number-crunching features there are 
>quite a few alternatives
>out there. What sets gretl apart (imho) is mainly (but not only, of course) 
>the intuitive interface.
>
>-sven
>
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to 
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement


--===============2490450938146976331==--


From jparav@unipi.gr Mon Jan 23 09:02:00 2006
From: John Paravantis PhD <jparav@unipi.gr>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] 2 ISSUES: ARIMA and Windows metafiles
Date: Mon, 23 Jan 2006 16:01:39 +0200
Message-ID: <43D4E1C3.1050208@unipi.gr>
In-Reply-To: 200601231213.k0NCDePp000398@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0368180190310420067=="

--===============0368180190310420067==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin,

Two suggestions for the next version of gretl, if you deem them worthy 
of attention:

1. The new forecasting platform of gretl is SUPERB and allows one to 
carry out model estimation and forecasting without the need for any 
additional calculations or backtransformations. Would you consider 
adding similar capabilities in ARMA, i.e. making the ARMA platform look 
like an ARIMA platform that would, in other words, allow the user to 
specify the degree of differencing and let gretl take care of the rest?

2. When gretl plots a scatterplot in which zero is included in the Y 
range, the zero reference line is plotted nicely as a DOTTED line and 
this translates correctly to either a PDF or an EPS graphics file. 
UNFORTUNATELY when copying/pasting or saving the file as a Windows 
metafile, this dotted line becomes SOLID. I am sure there is a solution 
to this in gnuplot BUT it should not be trivial. Would you consider 
fixing this so one may readily copy/paste graphic files into, say, a 
Word document?

Regards
John Paravantis
University of Piraeus


--===============0368180190310420067==--


From Ignacio.Diaz-Emparanza@ehu.es Mon Jan 23 09:21:28 2006
From: Ignacio =?utf-8?q?D=C3=ADaz-Emparanza?= <Ignacio.Diaz-Emparanza@ehu.es>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] 2 ISSUES: ARIMA and Windows metafiles
Date: Mon, 23 Jan 2006 15:21:16 +0100
Message-ID: <200601231521.16925.Ignacio.Diaz-Emparanza@ehu.es>
In-Reply-To: 43D4E1C3.1050208@unipi.gr
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8289448830698167537=="

--===============8289448830698167537==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

El Lunes, 23 de Enero de 2006 15:01, John Paravantis PhD escribió:
> Allin,
>
> Two suggestions for the next version of gretl, if you deem them worthy
> of attention:
>
> 1. The new forecasting platform of gretl is SUPERB and allows one to
> carry out model estimation and forecasting without the need for any
> additional calculations or backtransformations. Would you consider
> adding similar capabilities in ARMA, i.e. making the ARMA platform look
> like an ARIMA platform that would, in other words, allow the user to
> specify the degree of differencing and let gretl take care of the rest?

I agree with this. As you normally want to forecast the original series it is 
better to setup the differences (also the seasonal diffs) in the ARMA dialog 
box. So gretl (integrating the estimated data) may obtain the forecats for 
the original series. With respect to this I would also suggest the 
possibility to specify lags of the exogenous variables in that dialog box (or 
may be it is solved with the lists you are considering?).


-- 
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
http://www.bl.ehu.es/~etpdihei/


--===============8289448830698167537==--


From svetosch@gmx.net Mon Jan 23 13:49:31 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject:
 [Gretl-users] bug (?): double quote in script comment causes syntax error
Date: Mon, 23 Jan 2006 19:50:26 +0100
Message-ID: <43D52572.4060500@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2263009958999558252=="

--===============2263009958999558252==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,
just stumbled across the following:

Syntax-Fehler in genr-Formel

Error executing script: halting
> scalar r = -0.2		# Korrelationskoeffizient ("rho" ist in gretl tabu)

If I change the " to ' or omit them, everything is fine, so it's not serious.

cheers,
sven

--===============2263009958999558252==--


From cottrell@wfu.edu Mon Jan 23 14:45:29 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject:
 Re: [Gretl-users] bug (?): double quote in script comment causes syntax error
Date: Mon, 23 Jan 2006 14:45:29 -0500
Message-ID: <Pine.LNX.4.64.0601231442510.1435@ricardo.ecn.wfu.edu>
In-Reply-To: 43D52572.4060500@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8939942283303647874=="

--===============8939942283303647874==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Mon, 23 Jan 2006, Sven Schreiber wrote:

> Error executing script: halting
>> scalar r = -0.2		# Korrelationskoeffizient ("rho" ist in gretl tabu)
>
> If I change the " to ' or omit them, everything is fine, so it's not serious.

Hmm, can't replicate the problem with a current CVS build.  Maybe 
this has cured itself "by accident".

By the way, as of gretl 1.5.1, "rho" is nicht tabu in gretl.  All
of the special accessors such as rho have had a dollar sign prefixed
($rho, $coeff, etc.) and you can use the unprefixed versions as
ordinary variable names.

Allin Cottrell

--===============8939942283303647874==--


From abervas@hotmail.com Mon Jan 23 18:11:02 2006
From: Arnaud Bervas <abervas@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] sessions reconstitution
Date: Mon, 23 Jan 2006 23:10:57 +0000
Message-ID: <BAY104-F37C4C10CC1ABC321A73721BF100@phx.gbl>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3913324846013733622=="

--===============3913324846013733622==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Most of the time, I fail to reconstitute the sessions I have saved. I 
sometimes manage to open them, but I don't understand what is different from 
when I can't. Am I missing something about it ?
Thanks



--===============3913324846013733622==--


From cottrell@wfu.edu Mon Jan 23 20:55:28 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] sessions reconstitution
Date: Mon, 23 Jan 2006 20:55:28 -0500
Message-ID: <Pine.LNX.4.64.0601232042230.3980@ricardo.ecn.wfu.edu>
In-Reply-To: BAY104-F37C4C10CC1ABC321A73721BF100@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3543972229866954037=="

--===============3543972229866954037==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Mon, 23 Jan 2006, Arnaud Bervas wrote:

> Most of the time, I fail to reconstitute the sessions I have 
> saved. I sometimes manage to open them, but I don't understand 
> what is different from when I can't. Am I missing something about 
> it ?

Sorry, I have to admit this aspect of gretl is potentially flaky.

In my experience things work OK if you simply (a) carry out some 
tasks in gretl; (b) save your session; and (c) re-open it.  If 
things are not working for you in ths context, please post a 
description of what's happening.

Problems start arising when you make changes to a saved session and 
re-save it -- the main problem here being the logical design issue 
of what *ought* to happen in this situation.  It's harder than you 
might think.  Any thoughts on this would be appreciated -- 
preferably, informed by an examination of what gretl writes into a 
session (*.gretl) file.

Allin Cottrell


--===============3543972229866954037==--


From cottrell@wfu.edu Mon Jan 23 21:06:59 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] sessions reconstitution [2]
Date: Mon, 23 Jan 2006 21:06:59 -0500
Message-ID: <Pine.LNX.4.64.0601232104020.3980@ricardo.ecn.wfu.edu>
In-Reply-To: BAY104-F37C4C10CC1ABC321A73721BF100@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7987318330674305674=="

--===============7987318330674305674==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Mon, 23 Jan 2006, Arnaud Bervas wrote:

> Most of the time, I fail to reconstitute the sessions I have saved.

A second thought: Does anyone on the list happen to know how R's 
mechanism for saving the binary image of one's workspace works?  It 
may be that a radical redesign of gretl's "session saving" mechanism 
is in order, along the lines of doing some sort of binary memory 
dump.

Allin Cottrell

--===============7987318330674305674==--


From cottrell@wfu.edu Mon Jan 23 22:21:55 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Variable name
Date: Mon, 23 Jan 2006 22:21:55 -0500
Message-ID: <Pine.LNX.4.64.0601232213110.3980@ricardo.ecn.wfu.edu>
In-Reply-To: BAY109-F11BAECF9EE086755AD70FFBF1C0@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8363870234143433570=="

--===============8363870234143433570==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, 19 Jan 2006, john w wrote:

> Is it possible to expand, in one of the next versions, the 
> variable names from 8 to 16 characters?

The seems like a suggestion whose time has come.  The next release 
of gretl will permit variable names of up to 15 characters.

That's the maximum we can handle by means of a tweaking of the 
existing printout routines.  With longer variable names than that 
we'd basically have to trash the existing printing routines and 
redesign them from scratch, and I feel that those of us who are 
programming gretl have more productive things to do with our time!

Allin Cottrell

--===============8363870234143433570==--


From johnw2006@hotmail.com Tue Jan 24 02:10:59 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] sessions reconstitution [2]
Date: Tue, 24 Jan 2006 07:10:53 +0000
Message-ID: <BAY109-F11C3E51C7C6F81C85E4CA0BF130@phx.gbl>
In-Reply-To: Pine.LNX.4.64.0601232104020.3980@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5566092230449479248=="

--===============5566092230449479248==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Thanx for that Allin.

Now I have another problem with exogenous variables. In VAR module (and in 
VECM too) there is no possibility to specify number of lags of exogenous 
variables. They are allways included with zero lags. I also tried with 
creating lags manually and then to include them as exogenous but it's not 
working. They do not apper in VAR and VECM modules (This is possible in 
OLS). This means that Gretl threats exogenous as deterministics i.e. as 
constant and trend i.e. without lags.
Is it possible to do that somehow?
If not, then I am opting for this option as a new feature! This is realy an 
usefull thing.

For Jack: I tried to do AIC and BIC tests for lag selection in VAR but the 
procedure stops here
matrix mincrit = { 1.0E20 , 1.0E20 }
I think the problem is in numbers in brackets. As I am from Croatia, I tried 
to change Regional settings on Italian and English but the procedure still 
remains unfinished. I'll try again, maybe I missed something. Do you have an 
idea?
It will be great to include it as a feature in next version.


>From: Allin Cottrell <cottrell(a)wfu.edu>
>Reply-To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] sessions reconstitution [2]
>Date: Mon, 23 Jan 2006 21:06:59 -0500 (EST)
>
>On Mon, 23 Jan 2006, Arnaud Bervas wrote:
>
>>Most of the time, I fail to reconstitute the sessions I have saved.
>
>A second thought: Does anyone on the list happen to know how R's mechanism 
>for saving the binary image of one's workspace works?  It may be that a 
>radical redesign of gretl's "session saving" mechanism is in order, along 
>the lines of doing some sort of binary memory dump.
>
>Allin Cottrell
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 
7.5 today! http://messenger.msn.co.uk


--===============5566092230449479248==--


From jack@deanovell.unian.it Tue Jan 24 02:25:28 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] sessions reconstitution [2]
Date: Tue, 24 Jan 2006 08:25:23 +0100
Message-ID: <Pine.LNX.4.44.0601240823290.10493-100000@ec-4.econ.univpm.it>
In-Reply-To: Pine.LNX.4.64.0601232104020.3980@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7990367509600514813=="

--===============7990367509600514813==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Mon, 23 Jan 2006, Allin Cottrell wrote:

> On Mon, 23 Jan 2006, Arnaud Bervas wrote:
>
> > Most of the time, I fail to reconstitute the sessions I have saved.
>
> A second thought: Does anyone on the list happen to know how R's
> mechanism for saving the binary image of one's workspace works?  It
> may be that a radical redesign of gretl's "session saving" mechanism
> is in order, along the lines of doing some sort of binary memory
> dump.

Once the "bundles" mechanism Allin and I have been discussing is properly
in place, this should be much easier. All we need to settle is a precise
list of what has to be carried over between sessions.

Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============7990367509600514813==--


From jack@deanovell.unian.it Tue Jan 24 02:36:21 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] sessions reconstitution [2]
Date: Tue, 24 Jan 2006 08:36:16 +0100
Message-ID: <Pine.LNX.4.44.0601240825510.10493-100000@ec-4.econ.univpm.it>
In-Reply-To: BAY109-F11C3E51C7C6F81C85E4CA0BF130@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8281050583256536329=="

--===============8281050583256536329==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Tue, 24 Jan 2006, john w wrote:

> Thanx for that Allin.
>
> Now I have another problem with exogenous variables. In VAR module (and in
> VECM too) there is no possibility to specify number of lags of exogenous
> variables. They are allways included with zero lags. I also tried with
> creating lags manually and then to include them as exogenous but it's not
> working. They do not apper in VAR and VECM modules (This is possible in
> OLS). This means that Gretl threats exogenous as deterministics i.e. as
> constant and trend i.e. without lags.
> Is it possible to do that somehow?
> If not, then I am opting for this option as a new feature! This is realy an
> usefull thing.

Short-run workaround: define lagged variables using another name. For
example

	genr xlag1 = x(-1)

or if you feel adventurous

	loop for i=1..4
	  genr xlag$i = x(-$i)
	end loop

In the long run, I still think this could be solved by setting up tools
for handling lists in the GUI interface, but that will have to wait a bit.

> For Jack: I tried to do AIC and BIC tests for lag selection in VAR but the
> procedure stops here
> matrix mincrit = { 1.0E20 , 1.0E20 }
> I think the problem is in numbers in brackets. As I am from Croatia, I tried
> to change Regional settings on Italian and English but the procedure still
> remains unfinished. I'll try again, maybe I missed something. Do you have an
> idea?

Sorry, I was assuming you're running the CVS version. If you're using
Windows, that should work with the nightly snapshot, which is basically
CVS with a 1-day lag.  The matrix infrastructure is totally new and
the script cannot work with 1.5.0. OTOH, there is no real need for
matrices in that script, so modifying it to avoid matrix constructs
should be a relatively simple task.

> It will be great to include it as a feature in next version.

We'll think about it.

Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============8281050583256536329==--


From jack@deanovell.unian.it Tue Jan 24 03:10:15 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Building gretl under windows: volunteers?
Date: Tue, 24 Jan 2006 09:10:10 +0100
Message-ID: <Pine.LNX.4.44.0601240852340.10596-100000@ec-4.econ.univpm.it>
In-Reply-To: BAY109-F11C3E51C7C6F81C85E4CA0BF130@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3558351862439789986=="

--===============3558351862439789986==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Something that's been floating around in my mind for a while: most people
who actively work on the gretl development are Linux users: Allin,
Ignacio, Cristian, myself, for instance, are all linux addicts. On the
other hand, I have the feeling that most gretl users use windows as their
primary environment (this is certainly true of my students).

In some cases, this is a nuisance: once a Windows-only user spots a bug,
he has no other choice but to report it, hoping it will be fixed soon,
even if he had all the necessary skills to fix it himself. That's because
up to now no-one (as far as I know) has ever tried to compile gretl under
windows.

Building gretl under windows is certainly possible. Unfortunately, I have
no experience whatsoever with the GNU toolchain for Win32 (nor have I
intention of setting up a Windows box for trying, no thanks); but I know
for a fact that all the programs you need to build gretl (gcc compiler,
make etc.) are available under windows; one implementation (but there may
be others) can be found at http://cygwin.org.

Has anyone on the list some experience with this?

Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============3558351862439789986==--


From svetosch@gmx.net Tue Jan 24 08:18:44 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Building gretl under windows: volunteers?
Date: Tue, 24 Jan 2006 14:19:45 +0100
Message-ID: <43D62971.80308@gmx.net>
In-Reply-To: Pine.LNX.4.44.0601240852340.10596-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8836239698840565305=="

--===============8836239698840565305==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

jack schrieb:
> Something that's been floating around in my mind for a while: most people
> who actively work on the gretl development are Linux users: Allin,
> Ignacio, Cristian, myself, for instance, are all linux addicts. On the
> other hand, I have the feeling that most gretl users use windows as their
> primary environment (this is certainly true of my students).
> 
> In some cases, this is a nuisance: once a Windows-only user spots a bug,
> he has no other choice but to report it, hoping it will be fixed soon,
> even if he had all the necessary skills to fix it himself. That's because
> up to now no-one (as far as I know) has ever tried to compile gretl under
> windows.
> 
> Building gretl under windows is certainly possible. Unfortunately, I have
> no experience whatsoever with the GNU toolchain for Win32 (nor have I
> intention of setting up a Windows box for trying, no thanks); but I know
> for a fact that all the programs you need to build gretl (gcc compiler,
> make etc.) are available under windows; one implementation (but there may
> be others) can be found at http://cygwin.org.
> 
> Has anyone on the list some experience with this?
> 

Very limited only, I have mingw (not cygwin) installed and built something successfully by following
exact instructions. Due to the translation job I also have the cvs-repository here, so I could try
if you provide those instructions.
But what exactly would the purpose be? You guys seem very successful at cross-compiling for Windows,
no?
-sven

--===============8836239698840565305==--


From jack@deanovell.unian.it Tue Jan 24 08:49:11 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Building gretl under windows: volunteers?
Date: Tue, 24 Jan 2006 14:49:05 +0100
Message-ID: <Pine.LNX.4.44.0601241438060.28678-100000@ec-4.econ.univpm.it>
In-Reply-To: 43D62971.80308@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2492889584089039626=="

--===============2492889584089039626==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 24 Jan 2006, Sven Schreiber wrote:

> Very limited only, I have mingw (not cygwin) installed and built something =
successfully by following
> exact instructions. Due to the translation job I also have the cvs-reposito=
ry here, so I could try
> if you provide those instructions.
> But what exactly would the purpose be? You guys seem very successful at cro=
ss-compiling for Windows,
> no?

Sorry, I wasn't quite clear. The purpose is not to have a windows
executable; we've got that. The purpose is assembling a recipe for
compiling the source under windows.

Suppose you only use windows and there's something you'd like to change in
the source (recent example: "exogenous" vs "deterministic" in VARs).
That's a trivial change, so you think "Instead of bugging Allin, I'll do
it myself". You spot the line(s) to change, you change it, and then what?
If you can't compile, you have no way of checking if your changes have the
effects you wanted or, worse, break something. So eventually, your patch
sits idle.

Since the majority of our users use windows, I think that would be a
sizeable step forward. (It'd be better still if the majority used linux,
but I digress... and using win is a crime that contains its own punishment
anyway)

Riccardo `Jack' Lucchetti
Dipartimento di Economia
Universit=C3=A0 Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============2492889584089039626==--


From svetosch@gmx.net Tue Jan 24 09:00:05 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Building gretl under windows: volunteers?
Date: Tue, 24 Jan 2006 15:01:05 +0100
Message-ID: <43D63321.30806@gmx.net>
In-Reply-To: Pine.LNX.4.44.0601241438060.28678-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6115591335179509644=="

--===============6115591335179509644==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

jack schrieb:

> 
> Sorry, I wasn't quite clear. The purpose is not to have a windows
> executable; we've got that. The purpose is assembling a recipe for
> compiling the source under windows.
> 

Ah I see. I will try it, but I'm expecting to not get it working right away, and I don't have the
time for long trial-and-error sessions with makefiles and such, sorry.

However, there may be a workaround: Windows users can run Linux as a virtual machine with the free
vmware player. There are pre-built virtual Linux machines available linked from the vm website; I'm
currently in the process of trying such a thing out. At least some of those distros should come with
complete compilers, which would make it possible for Windows users to build gretl on Linux the same
way as you do, for free (and legally).

-sven


--===============6115591335179509644==--


From jack@deanovell.unian.it Tue Jan 24 09:11:08 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Building gretl under windows: volunteers?
Date: Tue, 24 Jan 2006 15:08:29 +0100
Message-ID: <Pine.LNX.4.44.0601241504190.31387-100000@ec-4.econ.univpm.it>
In-Reply-To: 43D63321.30806@gmx.net
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4854875414957177582=="

--===============4854875414957177582==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 24 Jan 2006, Sven Schreiber wrote:

> jack schrieb:
>
> >
> > Sorry, I wasn't quite clear. The purpose is not to have a windows
> > executable; we've got that. The purpose is assembling a recipe for
> > compiling the source under windows.
> >
>
> Ah I see. I will try it, but I'm expecting to not get it working right away=
, and I don't have the
> time for long trial-and-error sessions with makefiles and such, sorry.
>
> However, there may be a workaround: Windows users can run Linux as a virtua=
l machine with the free
> vmware player. There are pre-built virtual Linux machines available linked =
from the vm website; I'm
> currently in the process of trying such a thing out. At least some of those=
 distros should come with
> complete compilers, which would make it possible for Windows users to build=
 gretl on Linux the same
> way as you do, for free (and legally).

I don't know about the performace of vmware. In any case, installing a
whole distro on a virtual machine for the sole purpose of compiling gretl
seems a bit overkill. But, if you have to, choose Debian :-)

Just out of curiosity: assuming you have mingw installed and working, what
happens if you run the "configure" script in the top directory of the
source from a bash shell? Does it run at all? Does it complain about
missing stuff?


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Universit=C3=A0 Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti




--===============4854875414957177582==--


From jean.ries.l@gmail.com Tue Jan 24 09:39:23 2006
From: jean.ries.l@gmail.com
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] internal variables
Date: Tue, 24 Jan 2006 15:39:19 +0100
Message-ID: <f7e0fa9a0601240639s4e79849al3de195dd75f6f130@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8123726828117603016=="

--===============8123726828117603016==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,

I would like to ask a question on internal variables in gretl. From
the command reference I have learned that one can access the fitted
values from the mast regression command using an internal variable
called $yhat. So, after running a probit regression one can obtain the
predicted probabilities via $yhat. I would like to know if there is a
variable that stores the values of the linear predictor. Formally, in
addition to obtaining F(xb), I would also like to obtain xb, for
non-linear models such as probit, logit or poisson. In probit
regression, the linear predictor will e.g. be useful for computing
Mills' ratio or slopes (other than those computed by gretl).

I have another slightly related question. Under the genr entry, the
gretl command reference tells that one can access estimated
coefficients using coeff(var). I tried the following using one of
Wooldridge's sample datasets:

open jtrain2
ols re78 const train
genr pre = $yhat
genr mycoeff = coeff(train)

The script runs fine until the last line. There it stops and tells me:

? genr mycoeff = coeff(train)
Syntax error in genr formula

Error executing script: halting
> genr mycoeff = coeff(train)

I couldn't find any hints on a potential mistake in the documentation.
Could anyone tell me what's wrong here? I am using gretl 1.5.0 (build
date 01/17/2006) on Windows XP.

Thanks for your attention.

best wishes,

jean


--===============8123726828117603016==--


From f_bresson@yahoo.fr Tue Jan 24 10:45:38 2006
From: Florent Bresson <f_bresson@yahoo.fr>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Performing a t test of mean difference with factors
Date: Tue, 24 Jan 2006 16:45:29 +0100
Message-ID: <20060124154530.7466.qmail@web26803.mail.ukl.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5704086642682923553=="

--===============5704086642682923553==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I would like to perform a test of mean difference on a
series for different levels of a factor (usually I'm
using R, but I decided to choose gretl for my
students). Please, what's the command ?

Florent Bresson


=09

=09
	=09
___________________________________________________________________________=20
Nouveau : t=C3=A9l=C3=A9phonez moins cher avec Yahoo! Messenger ! D=C3=A9couv=
ez les tarifs exceptionnels pour appeler la France et l'international.
T=C3=A9l=C3=A9chargez sur http://fr.messenger.yahoo.com


--===============5704086642682923553==--


From cottrell@wfu.edu Tue Jan 24 11:27:58 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] internal variables
Date: Tue, 24 Jan 2006 11:27:58 -0500
Message-ID: <Pine.LNX.4.64.0601241123400.7606@ricardo.ecn.wfu.edu>
In-Reply-To: f7e0fa9a0601240639s4e79849al3de195dd75f6f130@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3697532170409234931=="

--===============3697532170409234931==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, 24 Jan 2006, jean.ries.l(a)gmail.com wrote:

> I would like to ask a question on internal variables in gretl. From
> the command reference I have learned that one can access the fitted
> values from the mast regression command using an internal variable
> called $yhat. So, after running a probit regression one can obtain the
> predicted probabilities via $yhat. I would like to know if there is a
> variable that stores the values of the linear predictor. Formally, in
> addition to obtaining F(xb), I would also like to obtain xb, for
> non-linear models such as probit, logit or poisson.

At present there is no such variable, but I think it would not be 
very difficult to add that possibility.  I'll put that on the
"to do" list.

> ? genr mycoeff = coeff(train)
> Syntax error in genr formula

Ah, I think the current Windows snapshot uses the new naming scheme 
for such variables, which will be in gretl 1.5.1.  Please try
$coeff(train) instead of coeff(train) and see if that works.  Also

stderr() -> $stderr
rho()    -> $rho
vcv()    -> $vcv

Allin Cottrell

--===============3697532170409234931==--


From jack@deanovell.unian.it Tue Jan 24 11:35:32 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] internal variables
Date: Tue, 24 Jan 2006 17:35:27 +0100
Message-ID: <Pine.LNX.4.44.0601241733520.14877-100000@ec-4.econ.univpm.it>
In-Reply-To: Pine.LNX.4.64.0601241123400.7606@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6250661135462393179=="

--===============6250661135462393179==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Tue, 24 Jan 2006, Allin Cottrell wrote:

> On Tue, 24 Jan 2006, jean.ries.l(a)gmail.com wrote:
>
> > I would like to ask a question on internal variables in gretl. From
> > the command reference I have learned that one can access the fitted
> > values from the mast regression command using an internal variable
> > called $yhat. So, after running a probit regression one can obtain the
> > predicted probabilities via $yhat. I would like to know if there is a
> > variable that stores the values of the linear predictor. Formally, in
> > addition to obtaining F(xb), I would also like to obtain xb, for
> > non-linear models such as probit, logit or poisson.
>
> At present there is no such variable, but I think it would not be
> very difficult to add that possibility.  I'll put that on the
> "to do" list.

you can also do

  probit y x
  xb = qnorm($yhat)

which is not optimal, but does the job.

Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============6250661135462393179==--


From cottrell@wfu.edu Tue Jan 24 11:55:18 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: VAR dialog (was Re: [Gretl-users] sessions reconstitution [2])
Date: Tue, 24 Jan 2006 11:55:17 -0500
Message-ID: <Pine.LNX.4.64.0601241140540.7606@ricardo.ecn.wfu.edu>
In-Reply-To: Pine.LNX.4.44.0601240825510.10493-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5282054795294860955=="

--===============5282054795294860955==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, 24 Jan 2006, jack quoted john w:

>> Now I have another problem with exogenous variables. In VAR module (and in
>> VECM too) there is no possibility to specify number of lags of exogenous
>> variables. They are allways included with zero lags. I also tried with
>> creating lags manually and then to include them as exogenous but it's not
>> working. They do not apper in VAR and VECM modules (This is possible in
>> OLS). This means that Gretl threats exogenous as deterministics i.e. as
>> constant and trend i.e. without lags.

The VAR command is one of the older interfaces in the program, and 
it could do with some updating.  In CVS I have added a "--trend" 
option to the command, with an associated checkbox, "Include a 
trend", in the VAR dialog box.  I have also the renamed the upper 
right-hand variable selection box to "Exogenous" rather than 
"Deterministic" variables.

However, as you point out, including lags of exogenous variables is 
problematic.  In the original design, the upper box was indeed 
intended for non-stochastic variables (trend, dummies), where the 
inclusion of lags would not make sense.  And lagged variables are 
not shown in the left-hand list, for the obvious reason that this 
could get very confusing, since lags of the endogenous variables are 
handled automatically.

Jack suggests:

> Short-run workaround: define lagged variables using another name. For
> example
>
> 	genr xlag1 = x(-1)

Yes, this is a good idea (for the present).  You can thereby fool 
gretl into thinking that "xlag1" is not really a lag, and it will be 
displayed in the left-hand variable selection list.

> In the long run, I still think this could be solved by setting up 
> tools for handling lists in the GUI interface, but that will have 
> to wait a bit.

Agreed, on both counts.

Quting john w again:

>> I tried to do AIC and BIC tests for lag selection in VAR but the
>> procedure stops here
>> matrix mincrit = { 1.0E20 , 1.0E20 }

Jack:

> Sorry, I was assuming you're running the CVS version. If you're 
> using Windows, that should work with the nightly snapshot, which 
> is basically CVS with a 1-day lag.  The matrix infrastructure is 
> totally new and the script cannot work with 1.5.0.

The Windows snapshot usually follows CVS with a short lag, but 
there's some discretion here and in fact I haven't made a snapshot 
lately since there's a lot of new material in CVS that could be 
unstable.  There will be a new snapshot as soon as CVS has settled 
down (shouldn't be long now).

Allin Cottrell

--===============5282054795294860955==--


From cottrell@wfu.edu Tue Jan 24 12:05:27 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Building gretl under windows: volunteers?
Date: Tue, 24 Jan 2006 12:05:27 -0500
Message-ID: <Pine.LNX.4.64.0601241158060.7606@ricardo.ecn.wfu.edu>
In-Reply-To: Pine.LNX.4.44.0601241438060.28678-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3697190765758549688=="

--===============3697190765758549688==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, 24 Jan 2006, jack wrote:

> Sorry, I wasn't quite clear. The purpose is not to have a windows
> executable; we've got that. The purpose is assembling a recipe for
> compiling the source under windows...

I think this would be useful.

At present the gretl "configure" script is not going to work on 
Windows, even with a fully-endowed mingw installation, because it 
makes various *nix-specific assumptions.

It would not be too difficult to fix that by adding some appropriate 
conditionals.  I don't have time to work on that right now, but if 
anyone's interested I think a reasonable approach would be to 
cross-reference gretl's "configure.in" with the Makefile and 
"config.mk" in the win32 subdirectory of the gretl source (which are 
used for the cross-compile).

Allin Cottrell

--===============3697190765758549688==--


From jean.ries.l@gmail.com Tue Jan 24 12:12:24 2006
From: jean.ries.l@gmail.com
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] internal variables
Date: Tue, 24 Jan 2006 18:12:19 +0100
Message-ID: <f7e0fa9a0601240912m27edd013ib3094ad410268483@mail.gmail.com>
In-Reply-To: Pine.LNX.4.44.0601241733520.14877-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5740592739625491324=="

--===============5740592739625491324==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin and Jack: Thanks for your prompt reply

For accessing the coefficients, using the new naming scheme
($coeff(x1) rather than coeff(x1)) has indeed solved the problem.

> you can also do
>
>   probit y x
>   xb = qnorm($yhat)
>
> which is not optimal, but does the job.

I did no know about the qnorm() function. It seems to me that it is
not mentioned in the documentation (User manual & Command Reference).

For sure it is not optimal, but much better than the workaround I had in mind:

probit y 0 x1 x2 X3
genr xb = $coeff(0)
loop foreach i x1 x2 x3
genr xb = xb + $coeff($i)*$i
endloop


Best wishes,

jean


--===============5740592739625491324==--


From cottrell@wfu.edu Tue Jan 24 12:20:35 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Performing a t test of mean difference with factors
Date: Tue, 24 Jan 2006 12:20:34 -0500
Message-ID: <Pine.LNX.4.64.0601241214050.7606@ricardo.ecn.wfu.edu>
In-Reply-To: 20060124154530.7466.qmail@web26803.mail.ukl.yahoo.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4959876657319440863=="

--===============4959876657319440863==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, 24 Jan 2006, Florent Bresson wrote:

> I would like to perform a test of mean difference on a series for 
> different levels of a factor (usually I'm using R, but I decided 
> to choose gretl for my students). Please, what's the command ?

OK, this is not super-convenient at present, but here's an example 
using Ramanathan's data7-2 salary data file.

open data7-2
smpl GENDER=0 --restrict
genr W0 = WAGE
smpl GENDER=1 --restrict --replace
genr W1 = WAGE
smpl full
meantest W0 W1

In the GUI program you can also do this under Utilities/Test 
Statistic calculator.

* Select the "2 means" tab

* In the upper panel, check "Use variable from dataset", and in the
   selection box, type "WAGE(GENDER=0)".  Press Enter in this box to
   get the sample statistics calculated.

* In the lower panel, again check "Use variable from dataset",
   type in "WAGE(GENDER=1)" and Enter.

* Click "OK" for the test.

Allin Cottrell


--===============4959876657319440863==--


From jean.ries.l@gmail.com Tue Jan 24 12:21:57 2006
From: jean.ries.l@gmail.com
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Performing a t test of mean difference with factors
Date: Tue, 24 Jan 2006 18:21:53 +0100
Message-ID: <f7e0fa9a0601240921v77afa0d8p3d4822564934c13@mail.gmail.com>
In-Reply-To: 20060124154530.7466.qmail@web26803.mail.ukl.yahoo.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6181129925895660314=="

--===============6181129925895660314==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 1/24/06, Florent Bresson <f_bresson(a)yahoo.fr> wrote:
> I would like to perform a test of mean difference on a
> series for different levels of a factor (usually I'm
> using R, but I decided to choose gretl for my
> students). Please, what's the command ?

So, you want to do a two-sample t-test. Indeed, it seems that gretl's
meantest function is only doing one-sample tests. However, a
two-sample t-test is the same as regressing the variable of interest
on a constant and the group variable. So you could do:
ols y 0 groupvar
or
ols y 0 groupvar --robust

Hope this helps,

jean


--===============6181129925895660314==--


From jack@deanovell.unian.it Tue Jan 24 12:48:22 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] internal variables
Date: Tue, 24 Jan 2006 18:48:17 +0100
Message-ID: <Pine.LNX.4.44.0601241844570.22435-100000@ec-4.econ.univpm.it>
In-Reply-To: f7e0fa9a0601240912m27edd013ib3094ad410268483@mail.gmail.com
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0288627435610725372=="

--===============0288627435610725372==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Tue, 24 Jan 2006 jean.ries.l(a)gmail.com wrote:

> Allin and Jack: Thanks for your prompt reply
>
> For accessing the coefficients, using the new naming scheme
> ($coeff(x1) rather than coeff(x1)) has indeed solved the problem.
>
> > you can also do
> >
> >   probit y x
> >   xb = qnorm($yhat)
> >
> > which is not optimal, but does the job.
>
> I did no know about the qnorm() function. It seems to me that it is
> not mentioned in the documentation (User manual & Command Reference).

Yes, it was a recent addition, not documented yet. The manuals need a bit
of love. Anyone who speaks LaTeX is welcome to help.


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============0288627435610725372==--


From johnw2006@hotmail.com Wed Jan 25 03:41:32 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: RE: VAR dialog (was Re: [Gretl-users] sessions reconstitution [2])
Date: Wed, 25 Jan 2006 08:41:26 +0000
Message-ID: <BAY109-F4262D3652304EDD569553BF120@phx.gbl>
In-Reply-To: Pine.LNX.4.64.0601241140540.7606@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4365536835178175999=="

--===============4365536835178175999==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Thnx for accepting my advice. I hope that VAR and VECM module will be 
finished soon.
Please could you send me a link to download the latest CVS version for 
Windows.
I can't find it on the page anymore.


>From: Allin Cottrell <cottrell(a)wfu.edu>
>Reply-To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>To: jack(a)deanovell.unian.it, Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: VAR dialog (was Re: [Gretl-users] sessions reconstitution [2])
>Date: Tue, 24 Jan 2006 11:55:17 -0500 (EST)
>
>On Tue, 24 Jan 2006, jack quoted john w:
>
>>>Now I have another problem with exogenous variables. In VAR module (and 
>>>in
>>>VECM too) there is no possibility to specify number of lags of exogenous
>>>variables. They are allways included with zero lags. I also tried with
>>>creating lags manually and then to include them as exogenous but it's not
>>>working. They do not apper in VAR and VECM modules (This is possible in
>>>OLS). This means that Gretl threats exogenous as deterministics i.e. as
>>>constant and trend i.e. without lags.
>
>The VAR command is one of the older interfaces in the program, and it could 
>do with some updating.  In CVS I have added a "--trend" option to the 
>command, with an associated checkbox, "Include a trend", in the VAR dialog 
>box.  I have also the renamed the upper right-hand variable selection box 
>to "Exogenous" rather than "Deterministic" variables.
>
>However, as you point out, including lags of exogenous variables is 
>problematic.  In the original design, the upper box was indeed intended for 
>non-stochastic variables (trend, dummies), where the inclusion of lags 
>would not make sense.  And lagged variables are not shown in the left-hand 
>list, for the obvious reason that this could get very confusing, since lags 
>of the endogenous variables are handled automatically.
>
>Jack suggests:
>
>>Short-run workaround: define lagged variables using another name. For
>>example
>>
>>	genr xlag1 = x(-1)
>
>Yes, this is a good idea (for the present).  You can thereby fool gretl 
>into thinking that "xlag1" is not really a lag, and it will be displayed in 
>the left-hand variable selection list.
>
>>In the long run, I still think this could be solved by setting up tools 
>>for handling lists in the GUI interface, but that will have to wait a bit.
>
>Agreed, on both counts.
>
>Quting john w again:
>
>>>I tried to do AIC and BIC tests for lag selection in VAR but the
>>>procedure stops here
>>>matrix mincrit = { 1.0E20 , 1.0E20 }
>
>Jack:
>
>>Sorry, I was assuming you're running the CVS version. If you're using 
>>Windows, that should work with the nightly snapshot, which is basically 
>>CVS with a 1-day lag.  The matrix infrastructure is totally new and the 
>>script cannot work with 1.5.0.
>
>The Windows snapshot usually follows CVS with a short lag, but there's some 
>discretion here and in fact I haven't made a snapshot lately since there's 
>a lot of new material in CVS that could be unstable.  There will be a new 
>snapshot as soon as CVS has settled down (shouldn't be long now).
>
>Allin Cottrell
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 
7.5 today! http://messenger.msn.co.uk


--===============4365536835178175999==--


From cottrell@wfu.edu Wed Jan 25 16:14:51 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] New Windows snapshot available
Date: Wed, 25 Jan 2006 16:14:51 -0500
Message-ID: <Pine.LNX.4.64.0601251608010.13146@ricardo.ecn.wfu.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1194164551419117210=="

--===============1194164551419117210==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

OK, there's now a snapshot with some of the new features we've been 
discussing.  It has matrix methods, 15-character variable names, and
a new lag-selection dialog box.

This version still needs to have the bugs shaken out of it, so I 
wouldn't recommend feeding it to students yet.  It is available at 
this URL only:

http://ricardo.ecn.wfu.edu/pub/gretl/gretl_install.exe

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

--===============1194164551419117210==--


From johnw2006@hotmail.com Thu Jan 26 16:12:50 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] New Windows snapshot - PERFECT!
Date: Thu, 26 Jan 2006 21:12:48 +0000
Message-ID: <BAY109-F39C866EE0F4991D2EAAA8FBF150@phx.gbl>
In-Reply-To: Pine.LNX.4.64.0601251608010.13146@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0487250278133300447=="

--===============0487250278133300447==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

All I can say Allin: it's PERFECT!
Yes, that's it!
Thank you.
I got a few advices:
1. VAR module output: It will be great to split endogenous variables and 
exogenous variables with putting deterministics between them. To get clearer 
output.

2. VAR and VECM module impulse responses graph: it will be better to plot 
confidence intervals with lines in some other colour rather to use fans. 
This is to get clearer output. It is a mess when plotting combined graph. 
The plot window is small and can't be extended so when plotting CI as fans 
you can't see any more the main impulse response graph. Other software have 
lines too.

3. Pleeeaaassee put AIC and BIC tests for lag selection in VAR and VECM. For 
example in Tests module of VAR and VECM.

4. In VAR roots plot output: it is good have numerical values of the roots 
in this plot but when some root is on or outside the circle you can't see 
root values because plot window can't be extended. But I see that youu put a 
new optin Number value which is currently disabled. Is this optin the 
solution for the previous mentioned problem?

5. VAR module: include a constant check box status is remembered by Gretl 
but include a trend is allways unchecked when re-estimateing VAR. It is a 
big possibility to forget to re-check this option.

What do you think about this?


>From: Allin Cottrell <cottrell(a)wfu.edu>
>Reply-To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>To: gretl-users(a)ricardo.ecn.wfu.edu
>Subject: [Gretl-users] New Windows snapshot available
>Date: Wed, 25 Jan 2006 16:14:51 -0500 (EST)
>
>OK, there's now a snapshot with some of the new features we've been 
>discussing.  It has matrix methods, 15-character variable names, and
>a new lag-selection dialog box.
>
>This version still needs to have the bugs shaken out of it, so I wouldn't 
>recommend feeding it to students yet.  It is available at this URL only:
>
>http://ricardo.ecn.wfu.edu/pub/gretl/gretl_install.exe
>
>--
>Allin Cottrell
>Department of Economics
>Wake Forest University, NC
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 
7.5 today! http://messenger.msn.co.uk


--===============0487250278133300447==--


From jack@deanovell.unian.it Thu Jan 26 17:18:55 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] New Windows snapshot - PERFECT!
Date: Thu, 26 Jan 2006 23:18:56 +0100
Message-ID: <Pine.LNX.4.44.0601262256020.22736-100000@ec-4.econ.univpm.it>
In-Reply-To: BAY109-F39C866EE0F4991D2EAAA8FBF150@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0694449132202793815=="

--===============0694449132202793815==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Thu, 26 Jan 2006, john w wrote:

> 3. Pleeeaaassee put AIC and BIC tests for lag selection in VAR and VECM. For
> example in Tests module of VAR and VECM.

I've been thinking about this. First of all, note that you ALREADY get
those statistics in the VAR output. In case you haven't noticed, they're
right at the beginning.

But I assume that what you want is those criteria reported for several lag
orders, so you can choose the "right" lag order. The trouble is, I don't
think you want to check the information criteria AFTER having estimated
the model. The ideal thing to do, in my view, would be to have a separate
command (say, "lagselect") to give you an idea of the order of the VAR you
want to estimate. VECMs wouldn't need a separate procedure, since a VECM
is nothing but a VAR with a peculiar type of restriction on the
parameters.

The most linear way to accomplish this in a script would be something
like:

	list VARvars = x y z
	n = lagselect(VARvars,BIC)

	var n VARvars

having the lagselect command issue some sort of output to let you check
what's happening. Note, by the way, that something like the above can be
achieved by some simple modifications to the script I sent a few days ago.

Now, how would you translate this into a GUI procedure? Maybe you can
select some variables from the main window and then (after right-clicking
or going through the menu) you get the output from lagselect, after which
you decide which lag structure you want and proceed with estimation. Or
would you rather have the option (in the VAR dialog)  of automatically
selecting the lag order via AIC or BIC instead of specifying it manually?
Or both things?

If we reach a consensus on
a) whether this is necessary at all
b) if a), if it is urgently needed
c) if a) & b), the "right" way to do it,
then we can get something done.


Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti




--===============0694449132202793815==--


From heliosoft@oninetspeed.pt Thu Jan 26 17:48:13 2006
From: HelioSoft de =?utf-8?q?H=C3=A9lio?= Guilherme <heliosoft@oninetspeed.pt>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Again the decimal comma vs decimal point.
Date: Thu, 26 Jan 2006 22:47:46 +0000
Message-ID: <43D95192.3020400@oninetspeed.pt>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3493692493169380130=="

--===============3493692493169380130==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
I'm using the latest Windows snapshot, and I did a simple test to
check how things are about the decimal point vs decimal comma
notation. So numbers must be entered with decimal point, but the
outputs are with decimal commas; is this the final decision?
About difficulties on handling scripts saved by users using decimal
commas, should it be established that "session files should always be
saved with decimal points, and at the moment of loading the session
the numbers are filtered to reflect user preference.", this way the
interactive environment would use user preference for inputting numbers.
Or alternatively, for readability of the session file, it stays as it
was saved, only that on the first(s) line(s) should appear a special
gretl directive, like for instance:
# gretl::decimal=","
# gretl::list_separator=";"                # this way a function call
would be: function_name( x ; y )
# gretl::thousands="."
or a single directive, like;
# gretl::notation=",;."
This way, by default, if no directives, no need for more processing.
And if directives match current user options, no need to filter the
numbers. So a user reading a session file would know how the numbers
are represented even if not using Gretl.
What you think about this?

My test output was obtained using Windows version, with the "use
locale decimal setting" checked (locale is Portuguese settings).
- -----
gretl console: type 'help' for a list of commands
? genr myvariable=1.2345678
Generated scalar myvariable (ID 5) = 1,23457

? print myvariable

     myvariable =  1,23457

? genr myvariable=1,2345678
Syntax error in command line

?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
 
iD8DBQFD2VGSHvesJJ5UqvkRAp5pAKDt4H6UnJJlS9TK0Adz0xQuVeqhkQCglsYZ
bAV5Rn92mee0pPa3K93jIgM=
=2htW
-----END PGP SIGNATURE-----


--===============3493692493169380130==--


From cottrell@wfu.edu Thu Jan 26 22:24:24 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] New Windows snapshot - PERFECT!
Date: Thu, 26 Jan 2006 22:24:24 -0500
Message-ID: <Pine.LNX.4.64.0601262210580.20532@ricardo.ecn.wfu.edu>
In-Reply-To: BAY109-F39C866EE0F4991D2EAAA8FBF150@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2544020291277231411=="

--===============2544020291277231411==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Thu, 26 Jan 2006, john w wrote:

> All I can say Allin: it's PERFECT!

Glad you like it!  Actually I'm working a bit more on the design of 
the lags dialog (how it relates to the main model dialog).

Thanks also for suggestions 1 to 3, which I will consider.

> 4. In VAR roots plot output: it is good have numerical values of 
> the roots in this plot but when some root is on or outside the 
> circle you can't see root values because plot window can't be 
> extended. But I see that youu put a new optin Number value which 
> is currently disabled. Is this optin the solution for the previous 
> mentioned problem?

Yes, it is the solution.  What exactly do you mean when you say it's 
"disabled"?  I haven't tested the Windows version in particular but 
it works fine here on Linux.

> 5. VAR module: include a constant check box status is remembered 
> by Gretl but include a trend is allways unchecked when 
> re-estimateing VAR. It is a big possibility to forget to re-check 
> this option.

"Include a constant" is not actually remembered, it's just the 
default.  If you uncheck it for one VAR, you'll have to uncheck it 
again for the next.  "Include a trend" is not the default, so it's 
always off until checked.  It would be easy enough to remember the 
setting, but I wonder if that's really a good idea.  It seems to me 
that a sloppy user is just as likely

(a) to omit a trend by mistake, somehow assuming that gretl would 
add it since the box was checked for a previous VAR, as

(b) to include a trend by mistake, failing to notice that the trend 
box had remembered the choice to include a trend in a previous VAR.

Allin Cottrell



--===============2544020291277231411==--


From Ignacio.Diaz-Emparanza@ehu.es Fri Jan 27 03:47:19 2006
From: Ignacio =?utf-8?q?D=C3=ADaz-Emparanza?= <Ignacio.Diaz-Emparanza@ehu.es>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] New Windows snapshot - PERFECT!
Date: Fri, 27 Jan 2006 09:47:09 +0100
Message-ID: <200601270947.09926.Ignacio.Diaz-Emparanza@ehu.es>
In-Reply-To: Pine.LNX.4.44.0601262256020.22736-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0419658668244318116=="

--===============0419658668244318116==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

El Jueves, 26 de Enero de 2006 23:18, jack escribi=C3=B3:
>...The ideal thing to do, in my view, would be to have a separate
> command (say, "lagselect") to give you an idea of the order of the VAR you
> want to estimate. VECMs wouldn't need a separate procedure, since a VECM
> is nothing but a VAR with a peculiar type of restriction on the
> parameters.
>
> The most linear way to accomplish this in a script would be something
> like:
>
> 	list VARvars =3D x y z
> 	n =3D lagselect(VARvars,BIC)
>
> 	var n VARvars
>
> having the lagselect command issue some sort of output to let you check
> what's happening. Note, by the way, that something like the above can be
> achieved by some simple modifications to the script I sent a few days ago.
>
> Now, how would you translate this into a GUI procedure? Maybe you can
> select some variables from the main window and then (after right-clicking
> or going through the menu) you get the output from lagselect, after which
> you decide which lag structure you want and proceed with estimation. Or
> would you rather have the option (in the VAR dialog)  of automatically
> selecting the lag order via AIC or BIC instead of specifying it manually?
> Or both things?
>
> If we reach a consensus on
> a) whether this is necessary at all
> b) if a), if it is urgently needed
> c) if a) & b), the "right" way to do it,
> then we can get something done.

There is a lag selection procedure in RATS (LAGSELEC.SRC), you can download i=
t=20
from http://www.estima.com/procs_alpha.shtml

It works only for univariate series but I suppose this may give us some=20
indications about doing what you are thinking in gretl.


--=20
Ignacio D=C3=ADaz-Emparanza
Dpto. de Econom=C3=ADa Aplicada III (Econometr=C3=ADa y Estad=C3=ADstica)
UPV-EHU


--===============0419658668244318116==--


From cottrell@wfu.edu Fri Jan 27 10:41:11 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Again the decimal comma vs decimal point.
Date: Fri, 27 Jan 2006 10:41:10 -0500
Message-ID: <Pine.LNX.4.64.0601271034380.23705@ricardo.ecn.wfu.edu>
In-Reply-To: 43D95192.3020400@oninetspeed.pt
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3674795705600047456=="

--===============3674795705600047456==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Thu, 26 Jan 2006, HelioSoft de Hélio Guilherme wrote:

> I'm using the latest Windows snapshot, and I did a simple test to
> check how things are about the decimal point vs decimal comma
> notation. So numbers must be entered with decimal point, but the
> outputs are with decimal commas; is this the final decision?

In the context of a "genr" command or equivalent (series, scalar, 
matrix), Yes, numbers must be entered using a decimal point.  We'll 
have to make that clear in the manual, and probably engineer a more 
explicit error message when this is violated.

> About difficulties on handling scripts saved by users using 
> decimal commas, should it be established that "session files 
> should always be saved with decimal points, and at the moment of 
> loading the session the numbers are filtered to reflect user 
> preference.", this way the interactive environment would use user 
> preference for inputting numbers. Or alternatively...

These are clever suggestions.  I think they'd make life 
over-complicated, but do others have any thoughts?

> My test output was obtained using Windows version, with the "use
> locale decimal setting" checked (locale is Portuguese settings).
> - -----
> gretl console: type 'help' for a list of commands
> ? genr myvariable=1.2345678
> Generated scalar myvariable (ID 5) = 1,23457
>
> ? print myvariable
>
>     myvariable =  1,23457
>
> ? genr myvariable=1,2345678
> Syntax error in command line

As things stand, this is the expected and intended behaviour, 
slightly odd as it may be.

Allin Cottrell

--===============3674795705600047456==--


From cottrell@wfu.edu Fri Jan 27 11:33:53 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] gretl and (old) gtk-1.2
Date: Fri, 27 Jan 2006 11:33:53 -0500
Message-ID: <Pine.LNX.4.64.0601271125360.23705@ricardo.ecn.wfu.edu>
In-Reply-To: BAY109-F39C866EE0F4991D2EAAA8FBF150@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6176066040440890794=="

--===============6176066040440890794==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

I wonder, are any list members using a recent version of gretl built 
with gtk-1.2?  Or does anyone know of a colleague who's doing so?

If you're running gretl on Windows you're using gtk-2.0.  You'd be 
using gtk-1.2 only if (a) you've downloaded one of

gretl-VERSION-1rh73.i386.rpm
gretl-VERSION-1generic.i386.rpm

or (b) you compiled gretl yourself on a gtk-1.2 system.  You can 
check that by doing

gretl --dump

at the command prompt to dump gretl's configuration.  The gtk 
version should be stated at the top of the output file.

The reason I ask is this: gtk-1.2 was been officially "obsolete" for 
years now, but to date we have continued to support it.  It would 
clean up the GUI code considerably if we could drop support for 
gtk-1.2 at this point.

Allin Cottrell

--===============6176066040440890794==--


From jack@deanovell.unian.it Fri Jan 27 11:59:42 2006
From: jack <jack@deanovell.unian.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Again the decimal comma vs decimal point.
Date: Fri, 27 Jan 2006 17:59:44 +0100
Message-ID: <Pine.LNX.4.44.0601271755510.2886-100000@ec-4.econ.univpm.it>
In-Reply-To: Pine.LNX.4.64.0601271034380.23705@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1261236639486021499=="

--===============1261236639486021499==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

On Fri, 27 Jan 2006, Allin Cottrell wrote:

> > About difficulties on handling scripts saved by users using
> > decimal commas, should it be established that "session files
> > should always be saved with decimal points, and at the moment of
> > loading the session the numbers are filtered to reflect user
> > preference.", this way the interactive environment would use user
> > preference for inputting numbers. Or alternatively...
>
> These are clever suggestions.  I think they'd make life
> over-complicated, but do others have any thoughts?

At the risk of sounding like a nazi, I'll reiterate: as far as I'm
concerned, locale-dependent decimal separators can be dumped altogether.
I cannot imagine a situation where a user can significantly benefit from
them.

Riccardo `Jack' Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche

jack(a)dea.unian.it
http://www.econ.univpm.it/lucchetti



--===============1261236639486021499==--


From johnw2006@hotmail.com Fri Jan 27 14:06:48 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] New Windows snapshot - PERFECT!
Date: Fri, 27 Jan 2006 19:06:47 +0000
Message-ID: <BAY109-F229C62D5CCFA75C8BDB17BF140@phx.gbl>
In-Reply-To: Pine.LNX.4.44.0601262256020.22736-100000@ec-4.econ.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3279909930859467763=="

--===============3279909930859467763==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Yes I have noticed them in VAR output.
Yes, I'm pointing on: criteria reported for several lag orders, so you can 
choose the "right" lag order.
They are a nice way to start building VARs.

You said:

The trouble is, I don't think you want to check the information criteria 
AFTER having estimated
>the model. The ideal thing to do, in my view, would be to have a separate
>command (say, "lagselect") to give you an idea of the order of the VAR you
>want to estimate. VECMs wouldn't need a separate procedure, since a VECM
>is nothing but a VAR with a peculiar type of restriction on the
>parameters.

As you said, the best way will be to put them in VAR and VECM module.

You said:
Or would you rather have the option (in the VAR dialog)  of automatically
>selecting the lag order via AIC or BIC instead of specifying it manually?
>Or both things?

I agree to have both options (automatically and manually).

If this is not a problem it will be nice to have it. Firstly for students, 
as when you start with learning VARs this is one of the first lessons and 
the second thing is the reason that all professional software include this 
option. I will be very happy that Gretl becomes a pro software-it has the 
potential to be that!

Thnx.

>From: jack <jack(a)deanovell.unian.it>
>Reply-To: jack(a)deanovell.unian.it,        Gretl list 
><gretl-users(a)ricardo.ecn.wfu.edu>
>To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] New Windows snapshot - PERFECT!
>Date: Thu, 26 Jan 2006 23:18:56 +0100 (CET)
>
>On Thu, 26 Jan 2006, john w wrote:
>
> > 3. Pleeeaaassee put AIC and BIC tests for lag selection in VAR and VECM. 
>For
> > example in Tests module of VAR and VECM.
>
>I've been thinking about this. First of all, note that you ALREADY get
>those statistics in the VAR output. In case you haven't noticed, they're
>right at the beginning.
>
>But I assume that what you want is those criteria reported for several lag
>orders, so you can choose the "right" lag order. The trouble is, I don't
>think you want to check the information criteria AFTER having estimated
>the model. The ideal thing to do, in my view, would be to have a separate
>command (say, "lagselect") to give you an idea of the order of the VAR you
>want to estimate. VECMs wouldn't need a separate procedure, since a VECM
>is nothing but a VAR with a peculiar type of restriction on the
>parameters.
>
>The most linear way to accomplish this in a script would be something
>like:
>
>	list VARvars = x y z
>	n = lagselect(VARvars,BIC)
>
>	var n VARvars
>
>having the lagselect command issue some sort of output to let you check
>what's happening. Note, by the way, that something like the above can be
>achieved by some simple modifications to the script I sent a few days ago.
>
>Now, how would you translate this into a GUI procedure? Maybe you can
>select some variables from the main window and then (after right-clicking
>or going through the menu) you get the output from lagselect, after which
>you decide which lag structure you want and proceed with estimation. Or
>would you rather have the option (in the VAR dialog)  of automatically
>selecting the lag order via AIC or BIC instead of specifying it manually?
>Or both things?
>
>If we reach a consensus on
>a) whether this is necessary at all
>b) if a), if it is urgently needed
>c) if a) & b), the "right" way to do it,
>then we can get something done.
>
>
>Riccardo `Jack' Lucchetti
>Dipartimento di Economia
>Università Politecnica delle Marche
>
>jack(a)dea.unian.it
>http://www.econ.univpm.it/lucchetti
>
>
>
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 
7.5 today! http://messenger.msn.co.uk



--===============3279909930859467763==--


From johnw2006@hotmail.com Fri Jan 27 14:30:51 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] New Windows snapshot - PERFECT!
Date: Fri, 27 Jan 2006 19:30:50 +0000
Message-ID: <BAY109-F9596F895B1C3335BF07F0BF140@phx.gbl>
In-Reply-To: Pine.LNX.4.64.0601262210580.20532@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0822515799945501244=="

--===============0822515799945501244==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Yes, I really like it!
And now it's really proffessional.

You said:
>Yes, it is the solution.  What exactly do you mean when you say it's 
>"disabled"?  I haven't tested the Windows version in particular but it 
>works fine here on Linux.

I use Gretl 1.5.0 Windows edition and it's not working. It's not disabled 
but the error message comes out when clicking on that option. Something with 
data error.

You said:
>"Include a constant" is not actually remembered, it's just the default.  If 
>you uncheck it for one VAR, you'll have to uncheck it again for the next.  
>"Include a trend" is not the default, so it's always off until checked.  It 
>would be easy enough to remember the setting, but I wonder if that's really 
>a good idea.


I think that it will be a good idea to remember the settings for trend too 
just like as for the sesonals. They are remembered when re-estimateing the 
same model. But I agree to reset them (not for a constant) when reopening 
Gretl.

What do you think?

Also as a user I have some new suggestions (plus that from yesterday post):
1. It will be nice to include Cointegration vector (EC) graph and EC vector 
data in the VECM module. Graph option under "Graphs module" and under "Add 
to data set" EC graph values.
Now I can find the graph on the main Gretl console but it's a little bit non 
practical solution.

2. In VECM output you can also put alphas wright after the Cointegratin 
vectors. I know that you can see them in equatations (and this should stay) 
but it's much clearer to put the alpha results once again after the vectors.


What do you say?






>From: Allin Cottrell <cottrell(a)wfu.edu>
>Reply-To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] New Windows snapshot - PERFECT!
>Date: Thu, 26 Jan 2006 22:24:24 -0500 (EST)
>
>On Thu, 26 Jan 2006, john w wrote:
>
>>All I can say Allin: it's PERFECT!
>
>Glad you like it!  Actually I'm working a bit more on the design of the 
>lags dialog (how it relates to the main model dialog).
>
>Thanks also for suggestions 1 to 3, which I will consider.
>
>>4. In VAR roots plot output: it is good have numerical values of the roots 
>>in this plot but when some root is on or outside the circle you can't see 
>>root values because plot window can't be extended. But I see that youu put 
>>a new optin Number value which is currently disabled. Is this optin the 
>>solution for the previous mentioned problem?
>
>Yes, it is the solution.  What exactly do you mean when you say it's 
>"disabled"?  I haven't tested the Windows version in particular but it 
>works fine here on Linux.
>
>>5. VAR module: include a constant check box status is remembered by Gretl 
>>but include a trend is allways unchecked when re-estimateing VAR. It is a 
>>big possibility to forget to re-check this option.
>
>"Include a constant" is not actually remembered, it's just the default.  If 
>you uncheck it for one VAR, you'll have to uncheck it again for the next.  
>"Include a trend" is not the default, so it's always off until checked.  It 
>would be easy enough to remember the setting, but I wonder if that's really 
>a good idea.  It seems to me that a sloppy user is just as likely
>
>(a) to omit a trend by mistake, somehow assuming that gretl would add it 
>since the box was checked for a previous VAR, as
>
>(b) to include a trend by mistake, failing to notice that the trend box had 
>remembered the choice to include a trend in a previous VAR.
>
>Allin Cottrell
>
>
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! 
http://www.msn.co.uk/newsletters


--===============0822515799945501244==--


From paravantis@otenet.gr Sat Jan 28 08:57:14 2006
From: John Paravantis <paravantis@otenet.gr>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Suggestion on forecasting; copy/paste issue
Date: Sat, 28 Jan 2006 15:57:05 +0200
Message-ID: <43DB7831.3030902@otenet.gr>
In-Reply-To: 200601271700.k0RGxvWD024814@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5448011452033754504=="

--===============5448011452033754504==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

When I select "Model data" > "Forecasts ..." in, say, the OLS platform, 
gretl graphs and tabulates forecasts and confidence intervals.

Unfortunately forecasts CANNOT BE SAVED (so I usually type them in 
manually). Would you consider adding this functionality?

Another somewhat related issue. Say I right-click on a variable and 
select "Display values" - an output window opens and the values are 
nicely tabulated. Now, if I click the copy icon, I can choose among "RTF 
(MS Word)", "Table (MS Word)", CSV (Spreadsheet)" and "plain text"; 
then, depending on my previous choice, I may be presented with a final 
dialog in which I may choose among comma, space and tab.

Well, THESE DON'T WORK -- no matter which one I select, the clipboard 
always contains TEXT.

This, I think, is an IMPORTANT issue because it hinders copying and 
pasting columns of data in Excel; if you copy multiple columns and past 
them in Excel, they end up in ONE Excel column and data look like (ALL 
IN ONE EXCEL COLUMN):

Year Var1
'1970 2.87897838
'1971 3.06792340
'1972 3.40698470
'1973 4.28687556

Excel 2003 does NOT seem to be doing the translation correctly. Is this 
a gretl issue or am I missing something?

Regards from Greece
John Paravantis
University of Piraeus

--===============5448011452033754504==--


From cottrell@wfu.edu Sat Jan 28 13:00:11 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Suggestion on forecasting; copy/paste issue
Date: Sat, 28 Jan 2006 13:00:11 -0500
Message-ID: <Pine.LNX.4.64.0601281256500.30652@ricardo.ecn.wfu.edu>
In-Reply-To: 43DB7831.3030902@otenet.gr
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6015820090627561928=="

--===============6015820090627561928==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Sat, 28 Jan 2006, John Paravantis wrote:

> When I select "Model data" > "Forecasts ..." in, say, the OLS platform, 
> gretl graphs and tabulates forecasts and confidence intervals.
>
> Unfortunately forecasts CANNOT BE SAVED (so I usually type them in 
> manually). Would you consider adding this functionality?

Don't you see the forecasts in a window equipped with Save, Print 
and Copy buttons?

> Another somewhat related issue. Say I right-click on a variable 
> and select "Display values" - an output window opens and the 
> values are nicely tabulated. Now, if I click the copy icon, I can 
> choose among "RTF (MS Word)", "Table (MS Word)", CSV 
> (Spreadsheet)" and "plain text"; then, depending on my previous 
> choice, I may be presented with a final dialog in which I may 
> choose among comma, space and tab.
>
> Well, THESE DON'T WORK -- no matter which one I select, the clipboard 
> always contains TEXT...

I'll have to check that on Windows.  It works OK on Linux but I 
guess something must have got broken in the Windows version.

Allin Cottrell

--===============6015820090627561928==--


From paravantis@hol.gr Sun Jan 29 09:39:53 2006
From: John Paravantis <paravantis@hol.gr>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Copied graphs have wide top and right margin
Date: Sun, 29 Jan 2006 16:39:40 +0200
Message-ID: <43DCD3AC.5040603@hol.gr>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1965668230002018770=="

--===============1965668230002018770==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Alin and community,

When a graph is copied to the clipboard and pasted to, say, Word, it has 
a very wide TOP and RIGHT margin.

Usually, I have to crop about 3.5 cm from the top margin and 5 cm from 
the right margin to make the white space around the graph appear 
symmetrical.

Can you correct this?

John Paravantis
University of Piraeus
Greece

--===============1965668230002018770==--


From peter@tomatoad.com Sun Jan 29 12:34:38 2006
From: Peter Davidoff <peter@tomatoad.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Copied graphs have wide top and right margin
Date: Sun, 29 Jan 2006 10:30:37 -0700
Message-ID: <6.2.3.4.0.20060129102908.03e03e20@mail.frii.com>
In-Reply-To: 43DCD3AC.5040603@hol.gr
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3313296745069566197=="

--===============3313296745069566197==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit


John,

I work-around I've been using is to go through my graph edits,
then save the file as temp.png.  I then insert the temp.png
where needed.  It is an extra step or two, but works well enough.

Peter
Colorado State University
University of Northern Colorado


At 07:39 AM 1/29/2006, you wrote:

>Alin and community,
>
>When a graph is copied to the clipboard and pasted to, say, Word, it 
>has a very wide TOP and RIGHT margin.
>
>Usually, I have to crop about 3.5 cm from the top margin and 5 cm 
>from the right margin to make the white space around the graph 
>appear symmetrical.
>
>Can you correct this?
>
>John Paravantis
>University of Piraeus
>Greece
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users
>
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.1.375 / Virus Database: 267.14.23/243 - Release Date: 1/27/2006


--===============3313296745069566197==--


From cottrell@wfu.edu Sun Jan 29 12:44:40 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Copied graphs have wide top and right margin
Date: Sun, 29 Jan 2006 12:44:40 -0500
Message-ID: <Pine.LNX.4.64.0601291242320.11669@ricardo.ecn.wfu.edu>
In-Reply-To: 43DCD3AC.5040603@hol.gr
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8136638145144814693=="

--===============8136638145144814693==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Sun, 29 Jan 2006, John Paravantis wrote:

> When a graph is copied to the clipboard and pasted to, say, Word, 
> it has a very wide TOP and RIGHT margin.
>
> Usually, I have to crop about 3.5 cm from the top margin and 5 cm 
> from the right margin to make the white space around the graph 
> appear symmetrical.

Gnuplot handles gretl's graphs.  What you're seeing is an artifact 
of the EMF (Enhanced Metafile) driver in gnuplot.  There may be some 
workaround that gretl could exploit when it sends the instructions 
to gnuplot to create the EMF file.  I'll try fiddling with this.

Allin Cottrell

--===============8136638145144814693==--


From paravantis@hol.gr Sun Jan 29 12:47:44 2006
From: John Paravantis <paravantis@hol.gr>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Adding forecasts to data set
Date: Sun, 29 Jan 2006 19:47:33 +0200
Message-ID: <43DCFFB5.8060807@hol.gr>
In-Reply-To: 200601291700.k0TH02dl011608@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2435558436162236594=="

--===============2435558436162236594==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Allin,

>>When I select "Model data" > "Forecasts ..." in, say, the OLS platform, 
>>gretl graphs and tabulates forecasts and confidence intervals.
>>
>>Unfortunately forecasts CANNOT BE SAVED (so I usually type them in 
>>manually). Would you consider adding this functionality?
>>    
>>
>
>Don't you see the forecasts in a window equipped with Save, Print 
>and Copy buttons?
>  
>
I DO -- what I meant is that it would be nice if I could SAVE the 
forecasts into a gretl data column, i.e. by choosing

"Model data" > "Add to data set"

where one can add to data set fits, residuals etc but NOT forecasts.

John

--===============2435558436162236594==--


From cottrell@wfu.edu Sun Jan 29 12:54:30 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Adding forecasts to data set
Date: Sun, 29 Jan 2006 12:54:30 -0500
Message-ID: <Pine.LNX.4.64.0601291253440.11669@ricardo.ecn.wfu.edu>
In-Reply-To: 43DCFFB5.8060807@hol.gr
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2233632980164970564=="

--===============2233632980164970564==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Sun, 29 Jan 2006, John Paravantis wrote:

>> Don't you see the forecasts in a window equipped with Save, Print and Copy 
>> buttons?
>> 
> I DO -- what I meant is that it would be nice if I could SAVE the forecasts 
> into a gretl data column, i.e. by choosing
>
> "Model data" > "Add to data set"
>
> where one can add to data set fits, residuals etc but NOT forecasts.

Ah, OK, got you.  That would be worth adding.

Allin.

--===============2233632980164970564==--


From jean.ries.l@gmail.com Mon Jan 30 03:13:27 2006
From: jean.ries.l@gmail.com
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Suggestion on forecasting; copy/paste issue
Date: Mon, 30 Jan 2006 09:13:19 +0100
Message-ID: <f7e0fa9a0601300013n562f2619qf14984452eb8ba9f@mail.gmail.com>
In-Reply-To: 43DB7831.3030902@otenet.gr
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============2818201786270283187=="

--===============2818201786270283187==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On 1/28/06, John Paravantis <paravantis(a)otenet.gr> wrote:
> Another somewhat related issue. Say I right-click on a variable and
> select "Display values" - an output window opens and the values are
> nicely tabulated. Now, if I click the copy icon, I can choose among "RTF
> (MS Word)", "Table (MS Word)", CSV (Spreadsheet)" and "plain text";
> then, depending on my previous choice, I may be presented with a final
> dialog in which I may choose among comma, space and tab.
>
> Well, THESE DON'T WORK -- no matter which one I select, the clipboard
> always contains TEXT.
>
> This, I think, is an IMPORTANT issue because it hinders copying and
> pasting columns of data in Excel; if you copy multiple columns and past
> them in Excel, they end up in ONE Excel column and data look like (ALL
> IN ONE EXCEL COLUMN):
>
> Year Var1
> '1970 2.87897838
> '1971 3.06792340
> '1972 3.40698470
> '1973 4.28687556
>
> Excel 2003 does NOT seem to be doing the translation correctly. Is this
> a gretl issue or am I missing something?

John,

I think that you can easily fix this within Excel. You can use the
"Data to columns" or "Text to columns" dialog, accessible via one of
the menus (I can't recall which one ...). This feature allows you to
split the data into several columns.

By the way, Gnumeric behaves much smarter in such a situation. If you
paste data from external applications, it presents you such a dialog
before finalizing the paste.

best wishes,

jean


--===============2818201786270283187==--


From paravantis@otenet.gr Mon Jan 30 19:10:42 2006
From: John Paravantis <paravantis@otenet.gr>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] ARMA bug?
Date: Tue, 31 Jan 2006 02:10:19 +0200
Message-ID: <43DEAAEB.5000509@otenet.gr>
In-Reply-To: 200601301700.k0UH03s9018502@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5147892710672374349=="

--===============5147892710672374349==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Methinks I found a bug in ARMA.

Copy/paste the following data into a gretl column (possibly pasting into 
Word and ALT-copying and pasting the column into Excel):

0.019
0.046
-0.16
0.328
0.077
0.408
-0.08
-0.166
-0.596
0.344
0.008
0.053
0.026
0.383
-0.196
-0.23
0.012
0.249
0.276
-0.881
0.089
0.742
-0.164
0.109
-0.006
0.2
0.115
0.718
0.138
-0.299
-0.009

(They are 2nd differences of car ownership per 100 people in Greece, 
from 1970 to 2000 appr.)

Then try to run an ARMA(1,1): you get a dialog that "The convergence 
criterion is not met". Unfortunately, it is possible to fiddle with the 
convergence criterios (# of iterations) on the ARMA dialog box!

Here comes worse. Try to estimate an ARMA(0,1) WITHOUT THE CONSTANT: you 
get an "out of memory error"!

Incidentally, these estimate ok in Statgraphics 5.1.

BTW thanks to all for your kind responses to my graph querry:
- Peter (of Colorado), many thanks for your tip -- I would rather not go 
through the PNG format because unlike vector graphics it deteriorates 
when zoomed and is usually not accepted by research journals.
- Jean, your appropriate reference to Gnumeric made me delve deeper into 
Excel 2003 (yuck!) only to find out that the reason I do not get the 
format confirmation dialog anymore is that Excel 2003 has now a separate 
menu (Data>Import External Data...) that imports other formats! Using 
that menu worked fine!

Warmest regards to all,
John
University of Piraues
Greece

PS I am mailing a separate gretl file with the above data to Allin (I 
cannot attach files to the user forum address, can I?)



--===============5147892710672374349==--


From cottrell@wfu.edu Mon Jan 30 21:32:31 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] ARMA bug?
Date: Mon, 30 Jan 2006 21:32:31 -0500
Message-ID: <Pine.LNX.4.64.0601302124290.20445@ricardo.ecn.wfu.edu>
In-Reply-To: 43DEAAEB.5000509@otenet.gr
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0851851875162905501=="

--===============0851851875162905501==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, 31 Jan 2006, John Paravantis wrote:

> Methinks I found a bug in ARMA.

[ data series snipped -- but thanks for providing this ]

> Then try to run an ARMA(1,1): you get a dialog that "The 
> convergence criterion is not met". Unfortunately, it is possible 
> to fiddle with the convergence criterios (# of iterations) on the 
> ARMA dialog box!
>
> Here comes worse. Try to estimate an ARMA(0,1) WITHOUT THE 
> CONSTANT: you get an "out of memory error"!

I'm not sure precisely what feature of the data or gretl's methods 
is responsible for the non-convergence in your first model. 
Perhaps Jack will have an idea on that.  But note that in gretl you 
have the option of using X-12-ARIMA for ARMA estimation, and in this 
case it will produce estimates for you.

As for the "out of memory" error in the second case, that is indeed 
a bug, now fixed in gretl CVS.  Gretl's native ARMA module will 
estimate the second model OK with this bug fixed (and in reasonable 
agreement with X-12-ARIMA).

? arma 0 1 ; x --nc
Convergence achieved after 7 iterations

ARMA estimates using the 30 observations 1971-2000
Dependent variable: x

VARIABLE       COEFFICIENT        STDERROR      T STAT   P-VALUE

  e(-1)           -0.218822         0.207045     -1.057   0.29929

Allin Cottrell

--===============0851851875162905501==--


From cottrell@wfu.edu Mon Jan 30 22:03:44 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Another Windows snapshot
Date: Mon, 30 Jan 2006 22:03:43 -0500
Message-ID: <Pine.LNX.4.64.0601302202180.21198@ricardo.ecn.wfu.edu>
In-Reply-To: 43DEAAEB.5000509@otenet.gr
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7435596733098156121=="

--===============7435596733098156121==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

OK, time for another snapshot.  This one fixes some recently 
reported bugs and adds some recently requested features (in a rough 
state):

http://ricardo.ecn.wfu.edu/pub/gretl/gretl_install.exe

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

--===============7435596733098156121==--


From ricardogs@terra.com.br Tue Jan 31 00:09:16 2006
From: Ricardo =?utf-8?q?Gon=C3=A7alves?= Silva <ricardogs@terra.com.br>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] ARMA bug?
Date: Tue, 31 Jan 2006 03:02:54 -0200
Message-ID: <000201c62624$77d5b450$0100000a@homeecon>
In-Reply-To: 43DEAAEB.5000509@otenet.gr
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6550386236532739206=="

--===============6550386236532739206==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,
Using a model without a constant a got:
Model 2: ARMA estimates using the 30 observations 1971-2000
Dependent variable: sales

VARIABLE       COEFFICIENT        STDERROR      T STAT   P-VALUE

 car(-1)          0.460111         0.928532      0.496   0.62410
 e(-1)           -0.673785         0.773696     -0.871   0.39123

The model has no constant term.
F is calculated as in Sect. 4.4 of Ramanathan's Introductory Econometrics.
R-squared is the square of the correlation between the observed and fitted 
values of the dependent variable.

----- Original Message ----- 
From: "John Paravantis" <paravantis(a)otenet.gr>
To: <gretl-users(a)ricardo.ecn.wfu.edu>
Sent: Monday, January 30, 2006 10:10 PM
Subject: [Gretl-users] ARMA bug?


> Methinks I found a bug in ARMA.
>
> Copy/paste the following data into a gretl column (possibly pasting into 
> Word and ALT-copying and pasting the column into Excel):
>
> 0.019
> 0.046
> -0.16
> 0.328
> 0.077
> 0.408
> -0.08
> -0.166
> -0.596
> 0.344
> 0.008
> 0.053
> 0.026
> 0.383
> -0.196
> -0.23
> 0.012
> 0.249
> 0.276
> -0.881
> 0.089
> 0.742
> -0.164
> 0.109
> -0.006
> 0.2
> 0.115
> 0.718
> 0.138
> -0.299
> -0.009
>
> (They are 2nd differences of car ownership per 100 people in Greece, from 
> 1970 to 2000 appr.)
>
> Then try to run an ARMA(1,1): you get a dialog that "The convergence 
> criterion is not met". Unfortunately, it is possible to fiddle with the 
> convergence criterios (# of iterations) on the ARMA dialog box!
>
> Here comes worse. Try to estimate an ARMA(0,1) WITHOUT THE CONSTANT: you 
> get an "out of memory error"!
>
> Incidentally, these estimate ok in Statgraphics 5.1.
>
> BTW thanks to all for your kind responses to my graph querry:
> - Peter (of Colorado), many thanks for your tip -- I would rather not go 
> through the PNG format because unlike vector graphics it deteriorates when 
> zoomed and is usually not accepted by research journals.
> - Jean, your appropriate reference to Gnumeric made me delve deeper into 
> Excel 2003 (yuck!) only to find out that the reason I do not get the 
> format confirmation dialog anymore is that Excel 2003 has now a separate 
> menu (Data>Import External Data...) that imports other formats! Using that 
> menu worked fine!
>
> Warmest regards to all,
> John
> University of Piraues
> Greece
>
> PS I am mailing a separate gretl file with the above data to Allin (I 
> cannot attach files to the user forum address, can I?)
>
>
> _______________________________________________
> Gretl-users mailing list
> Gretl-users(a)ricardo.ecn.wfu.edu
> http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users
> 


--===============6550386236532739206==--


From ricardogs@terra.com.br Tue Jan 31 00:20:29 2006
From: Ricardo =?utf-8?q?Gon=C3=A7alves?= Silva <ricardogs@terra.com.br>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] ARMA bug?
Date: Tue, 31 Jan 2006 03:20:21 -0200
Message-ID: <001201c62626$088e15e0$0100000a@homeecon>
In-Reply-To: 43DEAAEB.5000509@otenet.gr
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0065196925314176656=="

--===============0065196925314176656==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi,
I think I sent an incomplete e-mail. Well, estimating the model WITHOUT 
CONSTANT I got:
Convergence achieved after 15 iterations

Model 1: ARMA estimates using the 30 observations 1971-2000
Dependent variable: sales

VARIABLE       COEFFICIENT        STDERROR      T STAT   P-VALUE
car(-1)          0.460111         0.928532      0.496   0.62410
e(-1)           -0.673785         0.773696     -0.871   0.39123

The model has no constant term.
F is calculated as in Sect. 4.4 of Ramanathan's Introductory Econometrics.
R-squared is the square of the correlation between the observed and fitted
 values of the dependent variable.

  Mean of dependent variable = 0.0511333
  Standard deviation of dep. var. = 0.330484
  Mean of residuals = 0.0807281
  Sum of squared residuals = 3.06531
  Standard error of residuals = 0.33087
  Unadjusted R-squared = 0.105481
  Adjusted R-squared = 0.0735342
  F-statistic (2, 28) = 0.803697 (p-value = 0.458)
  Log-likelihood = -8.352
  AIC = 22.705
  BIC = 26.908
                        Real  Imaginary    Modulus  Frequency
  -----------------------------------------------------------
  AR  Root  1           2.1734     0.0000     2.1734     0.0000
  MA Root  1           1.4842     0.0000     1.4842     0.0000
  -----------------------------------------------------------

Using Stata I got,  WITH CONSTANT:


ARIMA regression

Sample:  1970 to 2000                           Number of obs      = 
31
                                                Wald chi2(2)       = 
12.05
Log likelihood =  -6.37294                      Prob > chi2        = 
0.0024

------------------------------------------------------------------------------
             |                 OPG
         car |      Coef.   Std. Err.      z    P>|z|     [95% Conf. 
Interval]
-------------+----------------------------------------------------------------
car          |
       _cons |   .0440328   .0318114     1.38   0.166    -.0183163 
.106382
-------------+----------------------------------------------------------------
ARMA         |
          ar |
         L1. |   .6318026   .3154554     2.00   0.045     .0135214 
1.250084
          ma |
         L1. |  -1.000008   2292.182    -0.00   1.000    -4493.595 
4491.595
-------------+----------------------------------------------------------------
      /sigma |    .287396   329.4019     0.00   0.999    -645.3285 
645.9032
------------------------------------------------------------------------------


However, the BHHH algorithm in Stata does not got convergence. It was 
necessary change to the BFGS one.
I think the problem is due to teh MA term, which, in fact does not exist 
(this is a second difference time-series!!!).
Did you tested the original series for one (or more ) unit roots? The 
spectrum was not clear about this.

I hope this help.

Ricardo
----- Original Message ----- 
From: "John Paravantis" <paravantis(a)otenet.gr>
To: <gretl-users(a)ricardo.ecn.wfu.edu>
Sent: Monday, January 30, 2006 10:10 PM
Subject: [Gretl-users] ARMA bug?


> Methinks I found a bug in ARMA.
>
> Copy/paste the following data into a gretl column (possibly pasting into 
> Word and ALT-copying and pasting the column into Excel):
>
> 0.019
> 0.046
> -0.16
> 0.328
> 0.077
> 0.408
> -0.08
> -0.166
> -0.596
> 0.344
> 0.008
> 0.053
> 0.026
> 0.383
> -0.196
> -0.23
> 0.012
> 0.249
> 0.276
> -0.881
> 0.089
> 0.742
> -0.164
> 0.109
> -0.006
> 0.2
> 0.115
> 0.718
> 0.138
> -0.299
> -0.009
>
> (They are 2nd differences of car ownership per 100 people in Greece, from 
> 1970 to 2000 appr.)
>
> Then try to run an ARMA(1,1): you get a dialog that "The convergence 
> criterion is not met". Unfortunately, it is possible to fiddle with the 
> convergence criterios (# of iterations) on the ARMA dialog box!
>
> Here comes worse. Try to estimate an ARMA(0,1) WITHOUT THE CONSTANT: you 
> get an "out of memory error"!
>
> Incidentally, these estimate ok in Statgraphics 5.1.
>
> BTW thanks to all for your kind responses to my graph querry:
> - Peter (of Colorado), many thanks for your tip -- I would rather not go 
> through the PNG format because unlike vector graphics it deteriorates when 
> zoomed and is usually not accepted by research journals.
> - Jean, your appropriate reference to Gnumeric made me delve deeper into 
> Excel 2003 (yuck!) only to find out that the reason I do not get the 
> format confirmation dialog anymore is that Excel 2003 has now a separate 
> menu (Data>Import External Data...) that imports other formats! Using that 
> menu worked fine!
>
> Warmest regards to all,
> John
> University of Piraues
> Greece
>
> PS I am mailing a separate gretl file with the above data to Allin (I 
> cannot attach files to the user forum address, can I?)
>
>
> _______________________________________________
> Gretl-users mailing list
> Gretl-users(a)ricardo.ecn.wfu.edu
> http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users
> 


--===============0065196925314176656==--


From r.lucchetti@univpm.it Tue Jan 31 02:49:31 2006
From: r.lucchetti@univpm.it
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] ARMA bug?
Date: Tue, 31 Jan 2006 08:49:25 +0100
Message-ID: <35174.81.200.130.230.1138693765.squirrel@mta01.univpm.it>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4152285076435590928=="

--===============4152285076435590928==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit


> On Tue, 31 Jan 2006, John Paravantis wrote:
>
>> Then try to run an ARMA(1,1): you get a dialog that "The
>> convergence criterion is not met". Unfortunately, it is possible to
fiddle with the convergence criterios (# of iterations) on the ARMA
dialog box!
>>

[ ... ]

>
> I'm not sure precisely what feature of the data or gretl's methods is
responsible for the non-convergence in your first model.
> Perhaps Jack will have an idea on that.  But note that in gretl you have
the option of using X-12-ARIMA for ARMA estimation, and in this case it
will produce estimates for you.

The issue we have here is very similar to the GARCH case that was
discussed here about 3 weeks ago (see
http://ricardo.ecn.wfu.edu/pipermail/gretl-users/2006-January/000292.html).

The "ARMA(1,1)--no constant" model has a likelihood function that, with
this dataset, appears to have no maximum inside the admissible parameter
region. I tried the same model with several packages: all of them report
problems.

For example, R's "tseries" package yields

Coefficients:
         ar1      ma1  intercept
      0.6318  -1.0000     0.0440
s.e.  0.1522   0.1102     0.0129

And clearly the idea here is to stop when the algorithm takes you to a
noninvertible MA structure. Ox arfima package gives:

                  Coefficient  Std.Error  t-value  t-prob
AR-1                 0.648324     0.1489     4.36   0.000
MA-1                -1.000000     0.1365    -7.32   0.000

which is very close to R. Eviews (ugh!) gives

AR(1)	 0.460374 0.643653  0.715253	0.4804
MA(1)	-0.674092 0.551803 -1.221617	0.2320

which is rather strange, considering that the score vector at that point
is not zero (but Eviews in not renowned for its numerical strength).

What *we* do here is simply give up. Actually, those who use linux will
perhaps see the message

MA root 0 = 0.999999
arma: MA estimate(s) out of bounds
bhhh_max: crit = 8.44786e-06, tol = 1e-06, err = 40
arma: bhhh_max returned 40

but that is issued to stderr, not to the main output (Allin, maybe we
ought to redirect this?)

As Ricardo pointed out, the trouble here is probably overdifferencing,
which induces a unit root in the MA part. If you try working with 1st
differences instead things are much much better. Try this:

genr ccars = cum(cars)
arma 1 1 ; ccars

Model 5: ARMA estimates using the 30 observations 1971-2000
Dependent variable: ccars

      VARIABLE       COEFFICIENT        STDERROR      T STAT   P-VALUE

       const            0.123980         0.139820      0.887   0.38279
     ccars(-1)          0.863621         0.230057      3.754   0.00081 ***
       e(-1)           -0.0827397        0.400739     -0.206   0.83792

If you get an adequate ARMA representation for "ccars", obviously any ARMA
representation for "cars" contains a unit root in the MA part, due to
excessive differencing. Hence the numerical problems.


-- 
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona


--===============4152285076435590928==--


From johnw2006@hotmail.com Tue Jan 31 12:12:28 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] New Windows snapshot - Again....
Date: Tue, 31 Jan 2006 17:12:23 +0000
Message-ID: <BAY109-F5D074F93FA4BF2B217158BF080@phx.gbl>
In-Reply-To: BAY109-F9596F895B1C3335BF07F0BF140@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3275369513484862229=="

--===============3275369513484862229==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

......perfect!

Thnx Allin and thnx Jack again. It's beautifull.
Windows version is working well.

I have some suggestions regardind this version:
1. Now constant, trend and seasonals are "remembered", but if you remoove 
some variable from a list in VAR and VECM module this is not "remembered". 
When re-estimateing again remooved variables are present.
It will be better that Gretl "remembers" only the LAST estimated 
specification i.e. if some variable is remooved or unchecked then in the 
next re-estimation this specifications must be "remembered".

2. It will be better to put "Lags" settings option wright after "Add" option 
in OLS module. It is more practical and the same logic is present in VAR and 
VECM module.

Also try to consider the following suggestions:

1. Now what is missing is the F test of zero restrictions for exogenous 
variables in VAR/VECM for every equatation and for a system as a whole !!! 
It will be a great help.

2. It will be nice to include Cointegration vector (EC) graph and EC vector
data in the VECM module. Graph option under "Graphs module" and under "Add
to data set" EC graph values.
Now I can find the graph on the main Gretl console but it's a little bit non
practical solution.

2. In VECM output you can also put alphas wright after the Cointegratin
vectors. I know that you can see them in equatations (and this should stay)
but it's much clearer to put the alpha results once again after the vectors.

and

3. ...a recursive VAR/VECM estimation.

I think that this 3 suggestions will mainly complete VAR and VECM modules.


   Thank you

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 
7.5 today! http://messenger.msn.co.uk


--===============3275369513484862229==--


From cottrell@wfu.edu Tue Jan 31 12:30:29 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] New Windows snapshot - Again....
Date: Tue, 31 Jan 2006 12:30:29 -0500
Message-ID: <Pine.LNX.4.64.0601311224150.23614@ricardo.ecn.wfu.edu>
In-Reply-To: BAY109-F5D074F93FA4BF2B217158BF080@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3330147355083124458=="

--===============3330147355083124458==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, 31 Jan 2006, john w wrote:

> 1. Now constant, trend and seasonals are "remembered", but if you 
> remoove some variable from a list in VAR and VECM module this is 
> not "remembered". When re-estimateing again remooved variables are 
> present. It will be better that Gretl "remembers" only the LAST 
> estimated specification

I thought that was what gretl did.  Could you give a specific 
"recipe" for getting the behavior you describe (i.e. remove variable 
how, from which list box)?  Thanks.

> 2. It will be better to put "Lags" settings option wright after 
> "Add" option in OLS module. It is more practical and the same 
> logic is present in VAR and VECM module.

I think that may be better.  It raises the question of how to handle 
IV estimation ("two-stage least squares") -- where should be button 
be placed in that case?

> Also try to consider the following suggestions:
>
> 1. Now what is missing is the F test of zero restrictions for 
> exogenous variables in VAR/VECM for every equatation and for a 
> system as a whole !!! It will be a great help.

I take it you mean exogenous variable other than deterministic ones 
such as constant and trend?

I'll get back to your VECM suggestions shortly.

Allin.

--===============3330147355083124458==--


From johnw2006@hotmail.com Tue Jan 31 12:55:14 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] New Windows snapshot - Again....
Date: Tue, 31 Jan 2006 17:55:09 +0000
Message-ID: <BAY109-F40BB78A7F1C723D2258353BF080@phx.gbl>
In-Reply-To: Pine.LNX.4.64.0601311224150.23614@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4983524341839269654=="

--===============4983524341839269654==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Regarding 1.
I tried to estimate VAR with endogenous, deterministics and exogenous 
variables. After taht I decided to re-estimate the model again. I again 
clicked on VAR module. Now I remooved exogenous variables form the exogenous 
list and clicked Ok. The model was estimated ok. Now I decided to again 
re-estimate my model. I clicked again on VAR module. Exogenous variables 
were present and they shouldn't be because I remooved them in the second 
re-estimation. So, the last estimation wasn't remembered (the first was).

Regarding 2.
Yes, you are wright. Maybe the solution is to put "Lags" in OLS module after 
Add option and to put it down in 2SLS next to Robust std errors box for 
example.


Regarding F test on zero restrictions.
Hmm..it will be great to have F test of zero restrictions for deterministics 
(const, trend and seasonals) and for exogenous variables. This will be 
"Bulls eye"!



John

>From: Allin Cottrell <cottrell(a)wfu.edu>
>Reply-To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] New Windows snapshot - Again....
>Date: Tue, 31 Jan 2006 12:30:29 -0500 (EST)
>
>On Tue, 31 Jan 2006, john w wrote:
>
>>1. Now constant, trend and seasonals are "remembered", but if you remoove 
>>some variable from a list in VAR and VECM module this is not "remembered". 
>>When re-estimateing again remooved variables are present. It will be 
>>better that Gretl "remembers" only the LAST estimated specification
>
>I thought that was what gretl did.  Could you give a specific "recipe" for 
>getting the behavior you describe (i.e. remove variable how, from which 
>list box)?  Thanks.
>
>>2. It will be better to put "Lags" settings option wright after "Add" 
>>option in OLS module. It is more practical and the same logic is present 
>>in VAR and VECM module.
>
>I think that may be better.  It raises the question of how to handle IV 
>estimation ("two-stage least squares") -- where should be button be placed 
>in that case?
>
>>Also try to consider the following suggestions:
>>
>>1. Now what is missing is the F test of zero restrictions for exogenous 
>>variables in VAR/VECM for every equatation and for a system as a whole !!! 
>>It will be a great help.
>
>I take it you mean exogenous variable other than deterministic ones such as 
>constant and trend?
>
>I'll get back to your VECM suggestions shortly.
>
>Allin.
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! 
http://www.msn.co.uk/newsletters


--===============4983524341839269654==--


From cottrell@wfu.edu Tue Jan 31 13:09:10 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] New Windows snapshot - Again....
Date: Tue, 31 Jan 2006 13:09:09 -0500
Message-ID: <Pine.LNX.4.64.0601311302100.23614@ricardo.ecn.wfu.edu>
In-Reply-To: BAY109-F40BB78A7F1C723D2258353BF080@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4922262553609191403=="

--===============4922262553609191403==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, 31 Jan 2006, john w wrote:

> Regarding 1.
> I tried to estimate VAR with endogenous, deterministics and exogenous 
> variables. After taht I decided to re-estimate the model again. I again 
> clicked on VAR module. Now I remooved exogenous variables form the exogenous 
> list and clicked Ok. The model was estimated ok. Now I decided to again 
> re-estimate my model. I clicked again on VAR module. Exogenous variables were 
> present and they shouldn't be because I remooved them in the second 
> re-estimation.

OK, that's not what I saw on a quick test.  I'll try some more 
checking.

> Regarding 2.
> Yes, you are wright. Maybe the solution is to put "Lags" in OLS module after 
> Add option and to put it down in 2SLS next to Robust std errors box for 
> example.

OK, that makes sense.

> Regarding F test on zero restrictions. Hmm..it will be great to 
> have F test of zero restrictions for deterministics (const, trend 
> and seasonals) and for exogenous variables. This will be "Bulls 
> eye"!

I think it would be best to implement this via the "omit" command 
that's currently available for single-equation models -- that is, 
extend it to cover VARs.  In the GUI program this command would be 
accessed via a menu item, "omit variables", under the Tests menu in 
the VAR window (it's there at present for single equation models). 
In the VAR case the variables displayed as candidates for omission 
would be the deterministic/exogenous terms.  Then the user can 
choose which subset to test.

Allin.

--===============4922262553609191403==--


From johnw2006@hotmail.com Tue Jan 31 13:27:51 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] New Windows snapshot - Again....
Date: Tue, 31 Jan 2006 18:27:45 +0000
Message-ID: <BAY109-F11713E3E1FBB83A67CE007BF080@phx.gbl>
In-Reply-To: Pine.LNX.4.64.0601311302100.23614@ricardo.ecn.wfu.edu
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6094858513768601936=="

--===============6094858513768601936==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

I use Windows version if this can help you.

Yes, that's it Allin!
"Omit" variables is the solution. But why not to extend it on endogenous 
variables too!? (Plus deterministics and exogenous variables). This will be 
just perfect!

Also, I think that this is possible for VECMs too.

As we are talking about causalities, one of the possible feature could be 
the possibility to test Granger causality (block and bivariate or pairwise).
What do you think?


John

>From: Allin Cottrell <cottrell(a)wfu.edu>
>Reply-To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>To: Gretl list <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] New Windows snapshot - Again....
>Date: Tue, 31 Jan 2006 13:09:09 -0500 (EST)
>
>On Tue, 31 Jan 2006, john w wrote:
>
>
>>Regarding F test on zero restrictions. Hmm..it will be great to have F 
>>test of zero restrictions for deterministics (const, trend and seasonals) 
>>and for exogenous variables. This will be "Bulls eye"!
>
>I think it would be best to implement this via the "omit" command that's 
>currently available for single-equation models -- that is, extend it to 
>cover VARs.  In the GUI program this command would be accessed via a menu 
>item, "omit variables", under the Tests menu in the VAR window (it's there 
>at present for single equation models). In the VAR case the variables 
>displayed as candidates for omission would be the deterministic/exogenous 
>terms.  Then the user can choose which subset to test.
>
>Allin.
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
The new MSN Search Toolbar now includes Desktop search! 
http://toolbar.msn.co.uk/


--===============6094858513768601936==--


From r.lucchetti@univpm.it Tue Jan 31 13:44:07 2006
From: Riccardo Jack Lucchetti <r.lucchetti@univpm.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] New Windows snapshot - Again....
Date: Tue, 31 Jan 2006 19:44:01 +0100
Message-ID: <40843.193.205.135.4.1138733041.squirrel@mta01.univpm.it>
In-Reply-To: BAY109-F11713E3E1FBB83A67CE007BF080@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7880628487615653744=="

--===============7880628487615653744==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit


On Tue, January 31, 2006 19:27, john w wrote:
> I use Windows version if this can help you.
>
> Yes, that's it Allin!
> "Omit" variables is the solution. But why not to extend it on endogenous
> variables too!? (Plus deterministics and exogenous variables). This will be
> just perfect!
>

Hmm.. generalising here is tricky. If you omit SOME lags from a VAR, then you
lose the justification for estimating it via OLS, because if the regressors
vary across equations you should use SUR (that gretl provides, by the way)
instead. So I think endogenous variables should be left alone.


> Also, I think that this is possible for VECMs too.
>
> As we are talking about causalities, one of the possible feature could be
> the possibility to test Granger causality (block and bivariate or pairwise).
> What do you think?

You've already got that: the F-tests under the individual regressions are
precisely Granger-causality tests.

-- 
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona


--===============7880628487615653744==--


From johnw2006@hotmail.com Tue Jan 31 14:19:33 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] New Windows snapshot - Again....
Date: Tue, 31 Jan 2006 19:19:28 +0000
Message-ID: <BAY109-F3577D161A1CAA909819262BF080@phx.gbl>
In-Reply-To: 40843.193.205.135.4.1138733041.squirrel@mta01.univpm.it
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1344171188490720630=="

--===============1344171188490720630==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hmm...I saw omitting endogenous variables in PcGive. It is possibile. These 
are so called Exclusion restrictions and all variables in VAR can be tested. 
You can test all the variables in VAR using F test but Exclusion 
restrictions are done via Subset Chi^2 (square) test and you can test 
endogenous, deterministics and exogenous variables.

Are Granger tests doable for VECMs ?    As tere are no F tests in VECM 
output. (my question excludes testing beta)

In previous posts I was talking about VAR/VECM confidence intervals. They 
are set as default in plot console to be errorbars and this can't be 
changed. Is it possible to activate this option so user can set it freely 
for example to be lines?


Thanx

John

>From: "Riccardo Jack" Lucchetti"" <r.lucchetti(a)univpm.it>
>Reply-To: r.lucchetti(a)univpm.it, Gretl list 
><gretl-users(a)ricardo.ecn.wfu.edu>
>To: "Gretl list" <gretl-users(a)ricardo.ecn.wfu.edu>
>Subject: Re: [Gretl-users] New Windows snapshot - Again....
>Date: Tue, 31 Jan 2006 19:44:01 +0100 (CET)
>
>
>On Tue, January 31, 2006 19:27, john w wrote:
> > I use Windows version if this can help you.
> >
> > Yes, that's it Allin!
> > "Omit" variables is the solution. But why not to extend it on endogenous
> > variables too!? (Plus deterministics and exogenous variables). This will 
>be
> > just perfect!
> >
>
>Hmm.. generalising here is tricky. If you omit SOME lags from a VAR, then 
>you
>lose the justification for estimating it via OLS, because if the regressors
>vary across equations you should use SUR (that gretl provides, by the way)
>instead. So I think endogenous variables should be left alone.
>
>
> > Also, I think that this is possible for VECMs too.
> >
> > As we are talking about causalities, one of the possible feature could 
>be
> > the possibility to test Granger causality (block and bivariate or 
>pairwise).
> > What do you think?
>
>You've already got that: the F-tests under the individual regressions are
>precisely Granger-causality tests.
>
>--
>Riccardo "Jack" Lucchetti
>Dipartimento di Economia
>Facoltà di Economia "G. Fuà"
>Ancona
>
>_______________________________________________
>Gretl-users mailing list
>Gretl-users(a)ricardo.ecn.wfu.edu
>http://ricardo.ecn.wfu.edu/mailman/listinfo/gretl-users

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! 
http://www.msn.co.uk/newsletters



--===============1344171188490720630==--


From johnw2006@hotmail.com Tue Jan 31 15:15:52 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] Clear function
Date: Tue, 31 Jan 2006 20:15:47 +0000
Message-ID: <BAY109-F24E3C286B42AB60ACC8444BF080@phx.gbl>
In-Reply-To: BAY109-F3577D161A1CAA909819262BF080@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6434166431202639897=="

--===============6434166431202639897==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

I have one question regarding "Clear" function for VAR/VECM module.
I noticed that "Clear" function clears only endogenous variables while 
exogenous not.
It should clear exogenous too.

Basicly, this function clears all except const, trend, seasonals, and number 
of lags? Wright?
Maybe it will be better to be something like "reset" function i.e. clears 
all endogenous and exogenous variables, returns lags to a max value of 12, 
clears trend and seasonals and leaves constant checked. In other words, 
clears everything except constant. This is for VAR module.

And for VECM module the same thing except - returns number of coint rank to 
1, and leaves "Unrestricted constant" checked.

What do you say?

Sorry for so much questions.....but thanx to you Gretl will be the best 
software (this includes paid software too).

God bless you all guys.
Be sure that I will mention you in my works.

_________________________________________________________________
The new MSN Search Toolbar now includes Desktop search! 
http://toolbar.msn.co.uk/


--===============6434166431202639897==--


From cottrell@wfu.edu Tue Jan 31 15:25:24 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] Clear function
Date: Tue, 31 Jan 2006 15:25:23 -0500
Message-ID: <Pine.LNX.4.64.0601311523560.23614@ricardo.ecn.wfu.edu>
In-Reply-To: BAY109-F24E3C286B42AB60ACC8444BF080@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============8000710063089885217=="

--===============8000710063089885217==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, 31 Jan 2006, john w wrote:

> I have one question regarding "Clear" function for VAR/VECM module.
> I noticed that "Clear" function clears only endogenous variables while 
> exogenous not.
> It should clear exogenous too.
>
> Basicly, this function clears all except const, trend, seasonals, and number 
> of lags? Wright?

The "Clear" function needs updating: it hasn't been revised since 
a time when the model dialog box was a good deal simpler.  Your 
suggestions are good.

Allin.

--===============8000710063089885217==--


From johnw2006@hotmail.com Tue Jan 31 15:39:55 2006
From: john w <johnw2006@hotmail.com>
To: gretl-users@gretlml.univpm.it
Subject: RE: [Gretl-users] Clear function
Date: Tue, 31 Jan 2006 20:39:50 +0000
Message-ID: <BAY109-F1951362688F7700709A426BF080@phx.gbl>
In-Reply-To: BAY109-F24E3C286B42AB60ACC8444BF080@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1186312984294708030=="

--===============1186312984294708030==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Thank you Allin.

Will you take my previous requests in count ("omit" function and  confidence 
intervals plot ) ?

_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! 
http://www.msn.co.uk/newsletters


--===============1186312984294708030==--


From r.lucchetti@univpm.it Tue Jan 31 16:07:35 2006
From: Riccardo Jack Lucchetti <r.lucchetti@univpm.it>
To: gretl-users@gretlml.univpm.it
Subject: Re: [Gretl-users] New Windows snapshot - Again....
Date: Tue, 31 Jan 2006 22:07:30 +0100
Message-ID: <56583.81.200.130.230.1138741650.squirrel@mta01.univpm.it>
In-Reply-To: BAY109-F3577D161A1CAA909819262BF080@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6824046458172895945=="

--===============6824046458172895945==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit


On Tue, January 31, 2006 20:19, john w wrote:
> Hmm...I saw omitting endogenous variables in PcGive. It is possibile. These
> are so called Exclusion restrictions and all variables in VAR can be tested.
> You can test all the variables in VAR using F test but Exclusion
> restrictions are done via Subset Chi^2 (square) test and you can test
> endogenous, deterministics and exogenous variables.
>

Of course it is possible. VARs are rather trivial parametric models for which
standard inference methods apply (at least in the stationary case --- see
below). My point was, general exclusion tests are often pointless in VARs,
since  these models don't aim at a structural representation of the data, but
only at encapsulating conveniently their time-series properties. If you feel
like carving out variables and/or lags, you're much better off with a
simultaneous equations system.

> Are Granger tests doable for VECMs ?    As tere are no F tests in VECM
> output. (my question excludes testing beta)

This brings back a point you raised some time ago (see
http://ricardo.ecn.wfu.edu/pipermail/gretl-users/2006-January/000326.html and
subsequent messages). I had a look at JMulTi. They do Granger causality tests
in cointegrated systems by using a very ingenious method, proposed by
Lütkepohl (usurprisingly) and Dolado, that bypasses most of the inferential
difficulties by estimating a levels VAR of higher order than necessary. It's
not difficult to do the same in a script, I think (but I have to dig a little
deeper into this).

-- 
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona


--===============6824046458172895945==--


From cottrell@wfu.edu Tue Jan 31 16:11:37 2006
From: Allin Cottrell <cottrell@wfu.edu>
To: gretl-users@gretlml.univpm.it
Subject: RE: [Gretl-users] Clear function
Date: Tue, 31 Jan 2006 16:11:36 -0500
Message-ID: <Pine.LNX.4.64.0601311611140.23614@ricardo.ecn.wfu.edu>
In-Reply-To: BAY109-F1951362688F7700709A426BF080@phx.gbl
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0876566597673615904=="

--===============0876566597673615904==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

On Tue, 31 Jan 2006, john w wrote:

> Will you take my previous requests in count ("omit" function and  confidence 
> intervals plot ) ?

Yes, at least up to a point ;-)

Allin

--===============0876566597673615904==--


From svetosch@gmx.net Tue Jan 31 17:51:52 2006
From: Sven Schreiber <svetosch@gmx.net>
To: gretl-users@gretlml.univpm.it
Subject: [Gretl-users] crash in German windows snapshot
Date: Tue, 31 Jan 2006 23:51:45 +0100
Message-ID: <43DFEA01.40400@gmx.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7705947436627680864=="

--===============7705947436627680864==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi, I'm getting reproducible crashes of the latest snapshot on windows
whenever I try to open the Data menu.

However, this only happens with the German translation loaded, so I
suppose it could be my fault as the current German translator ;-)
I could need some help investigating the causes though...

Any advice is appreciated,
Sven

--===============7705947436627680864==--