From svetosch@gmx.net Thu Jan 5 10:08:48 2006 From: Sven Schreiber 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, I get the following error output: 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) The same thing happens if I type 5,67 instead of 5.67. Workaround: if instead I modify the script as follows, 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 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: This gives me the following error output; note that the pvalue-command works fine, while the pvalue-function fails: ... ? 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) 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: which produces: ... ? 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 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 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 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: 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 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: 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 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: 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 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: 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 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 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: 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 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 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: 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 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 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 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 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 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 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: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] Re: importing data Date: Fri, 06 Jan 2006 14:04:25 -0500 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] Re: importing data Date: Fri, 06 Jan 2006 16:09:08 -0500 Message-ID: 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?= 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 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 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 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: 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 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 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: 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 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 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 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: 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 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 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 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: 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 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 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 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: 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 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 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 To: gretl-users@gretlml.univpm.it Subject: [Gretl-users] gmm Date: Thu, 12 Jan 2006 19:53:37 +0000 Message-ID: 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 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: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] gmm Date: Fri, 13 Jan 2006 00:28:57 +0100 Message-ID: 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 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: 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 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: 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 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 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 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: 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 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: 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 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: 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 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: 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 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: 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 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 To: gretl-users@gretlml.univpm.it Subject: [Gretl-users] (no subject) Date: Mon, 16 Jan 2006 19:18:26 +0000 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: [Gretl-users] gmm Date: Tue, 17 Jan 2006 19:05:43 +0000 Message-ID: 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 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 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 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] gmm Date: Wed, 18 Jan 2006 22:44:51 +0100 Message-ID: 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 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: 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 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 To: gretl-users@gretlml.univpm.it Subject: [Gretl-users] Variable name Date: Thu, 19 Jan 2006 13:15:16 +0000 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] Variable name Date: Thu, 19 Jan 2006 17:57:41 +0100 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] Variable name Date: Thu, 19 Jan 2006 12:24:13 -0500 Message-ID: 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 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 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: 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 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: 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?= 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 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: 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 >Reply-To: Gretl list >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 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: 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 >Reply-To: jack(a)deanovell.unian.it, Gretl list > >To: Gretl list >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 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: 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 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: 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 >Reply-To: jack(a)deanovell.unian.it, Gretl list > >To: Gretl list >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 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 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] FREETYPE6.DLL Date: Sat, 21 Jan 2006 13:14:49 -0500 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: [Gretl-users] VAR roots plot Date: Sat, 21 Jan 2006 23:39:50 -0500 Message-ID: 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 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: 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 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 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] VAR roots plot Date: Sun, 22 Jan 2006 17:50:46 -0500 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] VAR roots plot Date: Mon, 23 Jan 2006 07:22:06 +0000 Message-ID: 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 >Reply-To: Gretl list >To: Gretl list >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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] VAR roots plot Date: Mon, 23 Jan 2006 10:28:51 +0100 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] VAR roots plot Date: Mon, 23 Jan 2006 10:12:18 +0000 Message-ID: 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 >Reply-To: jack(a)deanovell.unian.it, Gretl list > >To: Gretl list >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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] VAR roots plot Date: Mon, 23 Jan 2006 11:36:29 +0100 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] VAR roots plot Date: Mon, 23 Jan 2006 11:39:24 +0000 Message-ID: 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 >Reply-To: jack(a)deanovell.unian.it, Gretl list > >To: Gretl list >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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] VAR roots plot Date: Mon, 23 Jan 2006 13:05:35 +0100 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] VAR roots plot Date: Mon, 23 Jan 2006 12:13:25 +0000 Message-ID: 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 >Reply-To: jack(a)deanovell.unian.it, Gretl list > >To: Gretl list >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 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] VAR roots plot Date: Mon, 23 Jan 2006 12:40:47 +0000 Message-ID: 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 >Reply-To: Gretl list >To: Gretl list >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 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] VAR roots plot Date: Mon, 23 Jan 2006 14:13:15 +0100 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] VAR roots plot Date: Mon, 23 Jan 2006 13:20:55 +0000 Message-ID: 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 >Reply-To: Gretl list >To: Gretl list >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 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?= 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 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 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: 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 To: gretl-users@gretlml.univpm.it Subject: [Gretl-users] sessions reconstitution Date: Mon, 23 Jan 2006 23:10:57 +0000 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] sessions reconstitution Date: Mon, 23 Jan 2006 20:55:28 -0500 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] sessions reconstitution [2] Date: Mon, 23 Jan 2006 21:06:59 -0500 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] Variable name Date: Mon, 23 Jan 2006 22:21:55 -0500 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] sessions reconstitution [2] Date: Tue, 24 Jan 2006 07:10:53 +0000 Message-ID: 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 >Reply-To: Gretl list >To: Gretl list >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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] sessions reconstitution [2] Date: Tue, 24 Jan 2006 08:25:23 +0100 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] sessions reconstitution [2] Date: Tue, 24 Jan 2006 08:36:16 +0100 Message-ID: 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 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: 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 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 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: 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 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 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: 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: 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 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] internal variables Date: Tue, 24 Jan 2006 11:27:58 -0500 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] internal variables Date: Tue, 24 Jan 2006 17:35:27 +0100 Message-ID: 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 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: 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 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: 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: 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 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: 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: 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 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] internal variables Date: Tue, 24 Jan 2006 18:48:17 +0100 Message-ID: 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 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: 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 >Reply-To: Gretl list >To: jack(a)deanovell.unian.it, Gretl list >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 To: gretl-users@gretlml.univpm.it Subject: [Gretl-users] New Windows snapshot available Date: Wed, 25 Jan 2006 16:14:51 -0500 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: [Gretl-users] New Windows snapshot - PERFECT! Date: Thu, 26 Jan 2006 21:12:48 +0000 Message-ID: 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 >Reply-To: Gretl list >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 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: 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 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 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: 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?= 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 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: 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 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: 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 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: 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 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: 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 >Reply-To: jack(a)deanovell.unian.it, Gretl list > >To: Gretl list >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 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: 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 >Reply-To: Gretl list >To: Gretl list >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 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 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: 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 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 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 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: 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 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 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: 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: 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 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 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] ARMA bug? Date: Mon, 30 Jan 2006 21:32:31 -0500 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: [Gretl-users] Another Windows snapshot Date: Mon, 30 Jan 2006 22:03:43 -0500 Message-ID: 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 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" To: 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 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" To: 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 To: gretl-users@gretlml.univpm.it Subject: [Gretl-users] New Windows snapshot - Again.... Date: Tue, 31 Jan 2006 17:12:23 +0000 Message-ID: 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 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: 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 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: 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 >Reply-To: Gretl list >To: Gretl list >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 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: 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 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: 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 >Reply-To: Gretl list >To: Gretl list >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 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 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: 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"" >Reply-To: r.lucchetti(a)univpm.it, Gretl list > >To: "Gretl list" >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 To: gretl-users@gretlml.univpm.it Subject: [Gretl-users] Clear function Date: Tue, 31 Jan 2006 20:15:47 +0000 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: Re: [Gretl-users] Clear function Date: Tue, 31 Jan 2006 15:25:23 -0500 Message-ID: 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 To: gretl-users@gretlml.univpm.it Subject: RE: [Gretl-users] Clear function Date: Tue, 31 Jan 2006 20:39:50 +0000 Message-ID: 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 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 To: gretl-users@gretlml.univpm.it Subject: RE: [Gretl-users] Clear function Date: Tue, 31 Jan 2006 16:11:36 -0500 Message-ID: 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 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==--