From r.lucchetti@univpm.it Thu May 1 06:54:03 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] RFC: $sigma & co. Date: Thu, 01 May 2008 12:54:00 +0200 Message-ID: In-Reply-To: alpine.DEB.1.10.0804302307020.15440@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5860860890420787430==" --===============5860860890420787430== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, 30 Apr 2008, Riccardo (Jack) Lucchetti wrote: > On Wed, 30 Apr 2008, Allin Cottrell wrote: > >> On Mon, 28 Apr 2008, Sven Schreiber wrote: >>=20 >> [re, reorganizing the $sigma and $vcv accessors] >>=20 >>> Although I will be one of the (few?) affected users I agree with >>> Jack that $vcv should be changed, especially because it's very >>> simple to change $vcv to $sigma to get the scripts working >>> again. (And I like the functionality that $vcv will deliver in >>> VAR/VECM contexts.) >>=20 >> OK. > > Coding $vcv for VARs should be quite easy. I'll try to see to that tomorrow= .=20 > Things are a bit trickier for VECMs. Should we return the v-cov matrix of t= he=20 > coefficients in VECM or VAR form? I just committed to CVS a few modifications to the VAR code, so that $vcv=20 returns the estimated covariance matrix for the coefficients. I don't=20 think I've broken anything, but you never know, so please test!=20 Limitations: 1) the --robust switch is ignored 2) VECMs aren't handled Moreover, we have a slight inconsistency in the way we compute things:=20 $sigma uses the asymptotic formula (ie, E'E over T), while in the=20 displayed equations we use degrees-of-freedom corrected figures for=20 standard errors. I'm not overly bothered by this, but some may. Example=20 script: Comments welcome. Riccardo (Jack) Lucchetti Dipartimento di Economia Universit=C3=A0 Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti --===============5860860890420787430==-- From svetosch@gmx.net Thu May 1 07:24:54 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] RFC: $sigma & co. Date: Thu, 01 May 2008 13:24:44 +0200 Message-ID: <4819A87C.7010307@gmx.net> In-Reply-To: alpine.DEB.1.10.0804302307020.15440@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4357665850257215501==" --===============4357665850257215501== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Am 30.04.2008 23:16, Riccardo (Jack) Lucchetti schrieb: > On Wed, 30 Apr 2008, Allin Cottrell wrote: > >> On Mon, 28 Apr 2008, Sven Schreiber wrote: >> >> [re, reorganizing the $sigma and $vcv accessors] >> >>> Although I will be one of the (few?) affected users I agree with >>> Jack that $vcv should be changed, especially because it's very >>> simple to change $vcv to $sigma to get the scripts working >>> again. (And I like the functionality that $vcv will deliver in >>> VAR/VECM contexts.) >> >> OK. > > Coding $vcv for VARs should be quite easy. I'll try to see to that > tomorrow. Things are a bit trickier for VECMs. Should we return the > v-cov matrix of the coefficients in VECM or VAR form? > I think the VECM form is more natural for the user if she specified a VECM. Also the vcv for the levels-VAR form would be singular, no? (I guess you don't care too much about that, but still.) -sven --===============4357665850257215501==-- From svetosch@gmx.net Thu May 1 07:26:10 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] RFC: $sigma & co. Date: Thu, 01 May 2008 13:26:07 +0200 Message-ID: <4819A8CF.9070804@gmx.net> In-Reply-To: alpine.DEB.1.10.0805011246010.21301@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0250351271817204615==" --===============0250351271817204615== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Am 01.05.2008 12:54, Riccardo (Jack) Lucchetti schrieb: > > Moreover, we have a slight inconsistency in the way we compute things: > $sigma uses the asymptotic formula (ie, E'E over T), while in the > displayed equations we use degrees-of-freedom corrected figures for > standard errors. I'm not overly bothered by this, but some may. What about $sigma in other contexts, is that asymptotic or dof-corrected? I think that should be made consistent. -sven --===============0250351271817204615==-- From svetosch@gmx.net Thu May 1 07:35:38 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] RFC: $sigma & co. Date: Thu, 01 May 2008 13:35:35 +0200 Message-ID: <4819AB07.8080901@gmx.net> In-Reply-To: alpine.DEB.1.10.0804302307020.15440@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0771468806567440565==" --===============0771468806567440565== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Am 30.04.2008 23:16, Riccardo (Jack) Lucchetti schrieb: > On Wed, 30 Apr 2008, Allin Cottrell wrote: > >> I think it would be easier to roll such tests into the existing >> gretl regression suite. I can make this available via the web. >> Package maintainers could play a useful role, however, by >> contributing scripts that exercise their packages. > > I agree. IMHO, writing test scripts for contributed function packages is > be something the package writers should do. How am I supposed to write a > test script for econometric techniques I may know nothing about? > I agree it's ideal if the package authors also provide test cases, but simply calling a function doesn't require that you understand the results. I'd say that most of the time a backwards-incompatible change will give a plain error instead of wrong results. (Not always, of course.) The more widespread gretl wants to become, the more stable its programming interface needs to be, IMHO. For every user who openly complains about a problem she has with gretl (on the lists or wherever), there are many many more users who simply discard it silently and move on. be user-friendly, that's all I'm trying to say :-) -sven --===============0771468806567440565==-- From r.lucchetti@univpm.it Thu May 1 08:03:30 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] RFC: $sigma & co. Date: Thu, 01 May 2008 14:03:27 +0200 Message-ID: In-Reply-To: 4819A8CF.9070804@gmx.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7646737402284424434==" --===============7646737402284424434== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, 1 May 2008, Sven Schreiber wrote: > Am 01.05.2008 12:54, Riccardo (Jack) Lucchetti schrieb: > >>=20 >> Moreover, we have a slight inconsistency in the way we compute things:=20 >> $sigma uses the asymptotic formula (ie, E'E over T), while in the displaye= d=20 >> equations we use degrees-of-freedom corrected figures for standard errors.= =20 >> I'm not overly bothered by this, but some may.=20 > > What about $sigma in other contexts, is that asymptotic or dof-corrected? I= =20 > think that should be made consistent. I'm all for consistency in general, but this case is difficult. In OLS=20 estimation, for example, SSR/T and SSR/(T-k) are both consistent, but the=20 latter has the additional small advantage of being unbiased under certain=20 conditions, so that's traditionally what people use. I personally=20 think it's rather silly to worry about this when you have a decent=20 sample size; if you don't, well, I doubt very much you should be doing=20 inference _at all_. In other contexts, Tobit models for example, you simply don't have a=20 choice. In my view, the really important thing is that you know which=20 formula is used in each case, so that if you feel like re-computing $sigma=20 to your taste, you have the tools to do it. Riccardo (Jack) Lucchetti Dipartimento di Economia Universit=C3=A0 Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti --===============7646737402284424434==-- From svetosch@gmx.net Thu May 1 11:11:37 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] RFC: $sigma & co. Date: Thu, 01 May 2008 17:11:31 +0200 Message-ID: <4819DDA3.5020301@gmx.net> In-Reply-To: alpine.DEB.1.10.0805011354520.22637@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4331759307040135707==" --===============4331759307040135707== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Am 01.05.2008 14:03, Riccardo (Jack) Lucchetti schrieb: > On Thu, 1 May 2008, Sven Schreiber wrote: > >> Am 01.05.2008 12:54, Riccardo (Jack) Lucchetti schrieb: >> >>> >>> Moreover, we have a slight inconsistency in the way we compute >>> things: $sigma uses the asymptotic formula (ie, E'E over T), while in >>> the displayed equations we use degrees-of-freedom corrected figures >>> for standard errors. I'm not overly bothered by this, but some may. >> >> What about $sigma in other contexts, is that asymptotic or >> dof-corrected? I think that should be made consistent. > > I'm all for consistency in general, but this case is difficult. In OLS > estimation, for example, SSR/T and SSR/(T-k) are both consistent, but > the latter has the additional small advantage of being unbiased under > certain conditions, so that's traditionally what people use. I > personally think it's rather silly to worry about this when you have a > decent sample size; if you don't, well, I doubt very much you should be > doing inference _at all_. > > In other contexts, Tobit models for example, you simply don't have a > choice. In my view, the really important thing is that you know which > formula is used in each case, so that if you feel like re-computing > $sigma to your taste, you have the tools to do it. > I just meant "consistent definition" across the various contexts of $sigma, not consistent in the statistical sense. So if you are saying $sigma for Tobit models is w/o dof correction out of necessity but for OLS it currently is dof-corrected, then I would suggest the rule: "$sigma has a dof correction if at all feasible". That would mean dof correction for the VAR/VECM $sigma. BTW, I remember we had a discussion in the context of the vcv of the betas in the VECM, but I don't remember the result. Is there a dof correction there in the end? (I know I know it's probably in the manual...) cheers, sven --===============4331759307040135707==-- From r.lucchetti@univpm.it Thu May 1 13:00:33 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] RFC: $sigma & co. Date: Thu, 01 May 2008 19:00:29 +0200 Message-ID: In-Reply-To: 4819DDA3.5020301@gmx.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5887088266033045974==" --===============5887088266033045974== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thu, 1 May 2008, Sven Schreiber wrote: > Am 01.05.2008 14:03, Riccardo (Jack) Lucchetti schrieb: >> On Thu, 1 May 2008, Sven Schreiber wrote: >>=20 >>> Am 01.05.2008 12:54, Riccardo (Jack) Lucchetti schrieb: >>>=20 >>>>=20 >>>> Moreover, we have a slight inconsistency in the way we compute things:=20 >>>> $sigma uses the asymptotic formula (ie, E'E over T), while in the=20 >>>> displayed equations we use degrees-of-freedom corrected figures for=20 >>>> standard errors. I'm not overly bothered by this, but some may.=20 >>>=20 >>> What about $sigma in other contexts, is that asymptotic or dof-corrected?= =20 >>> I think that should be made consistent. >>=20 >> I'm all for consistency in general, but this case is difficult. In OLS=20 >> estimation, for example, SSR/T and SSR/(T-k) are both consistent, but the = >> latter has the additional small advantage of being unbiased under certain = >> conditions, so that's traditionally what people use. I personally think=20 >> it's rather silly to worry about this when you have a decent sample size; = >> if you don't, well, I doubt very much you should be doing inference _at=20 >> all_. >>=20 >> In other contexts, Tobit models for example, you simply don't have a=20 >> choice. In my view, the really important thing is that you know which=20 >> formula is used in each case, so that if you feel like re-computing $sigma= =20 >> to your taste, you have the tools to do it. >>=20 > > I just meant "consistent definition" across the various contexts of $sigma,= =20 > not consistent in the statistical sense. So if you are saying $sigma for=20 > Tobit models is w/o dof correction out of necessity but for OLS it currentl= y=20 > is dof-corrected, then I would suggest the rule: "$sigma has a dof correcti= on=20 > if at all feasible". That would mean dof correction for the VAR/VECM $sigma= .=20 > BTW, I remember we had a discussion in the context of the vcv of the betas = in=20 > the VECM, but I don't remember the result. Is there a dof correction there = in=20 > the end? (I know I know it's probably in the manual...) Sorry, my answer wan't clear. The meaning I gave to the word "consistency"=20 is exactly the same as yours. My point is, in some contexts you use dof=20 correction because, well, that's what people do and in some other contexts=20 you don't because... people don't! If this does not sound particularly scientific, too bad. Mrs McCloskey and=20 Mr Feyerabend (among others) wouldn't find it shocking, though. Riccardo (Jack) Lucchetti Dipartimento di Economia Universit=C3=A0 Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti --===============5887088266033045974==-- From svetosch@gmx.net Fri May 2 07:40:10 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: [Gretl-devel] new tracker for incompatible changes Date: Fri, 02 May 2008 13:40:03 +0200 Message-ID: <481AFD93.70900@gmx.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9013092594502537075==" --===============9013092594502537075== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Dear all, as we discussed recently I have created a new sourceforge tracker named "Backwards-incompatible changes", and have added a first item relating to the changed use of the $vcv accessors. Please check it out, correct it and/or expand it. (Allin and Jack, could you just drop some keywords what other incompatible changes will be new in 1.7.5, if any. thanks) I have designated the "group" field of the tracker to refer to different gretl versions, so that later it will be possible to search for all incompatible changes in a specific version. Currently there is only a group "new in 1.7.5", but as time progresses there will of course be more groups. (And there is a bogus group "changed in gretl version" that I erroneously created and now can't get rid of anymore.) This tracker is already visible on the sourceforge tracker page. I'm not sure if regular users are able to submit new items (which they normally shouldn't do), but at least you need to be logged in before doing that, and submitted items can always be deleted later. Before I announce this on the users list I would like to wait a bit for feedback, however. cheers, sven --===============9013092594502537075==-- From cottrell@wfu.edu Fri May 2 10:19:22 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] new tracker for incompatible changes Date: Fri, 02 May 2008 10:19:13 -0400 Message-ID: In-Reply-To: 481AFD93.70900@gmx.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4228288176932691253==" --===============4228288176932691253== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 2 May 2008, Sven Schreiber wrote: > as we discussed recently I have created a new sourceforge > tracker named "Backwards-incompatible changes", and have added a > first item relating to the changed use of the $vcv accessors. > Please check it out, correct it and/or expand it... Thanks very much, Sven. But now I see the new tracker in place I have to say, I wonder if this is the right way to go. It's certainly a good thing to have a searchable database of such changes, but IMO this should be (a) static and (b) editable only by developers (including yourself, of course). The regular SF tracker apparatus (Assigned to/Status/Priority, and so on) doesn't seem to apply, and might be confusing. However, that's just my first reaction and I'm willing to be persuaded otherwise. Allin. --===============4228288176932691253==-- From svetosch@gmx.net Fri May 2 10:38:59 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] new tracker for incompatible changes Date: Fri, 02 May 2008 16:38:59 +0200 Message-ID: <481B2783.7080002@gmx.net> In-Reply-To: alpine.LRH.1.10.0805021009060.6977@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2101749068397148025==" --===============2101749068397148025== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Am 02.05.2008 16:19, Allin Cottrell schrieb: > On Fri, 2 May 2008, Sven Schreiber wrote: > >> as we discussed recently I have created a new sourceforge >> tracker named "Backwards-incompatible changes", and have added a >> first item relating to the changed use of the $vcv accessors. >> Please check it out, correct it and/or expand it... > > Thanks very much, Sven. But now I see the new tracker in place I > have to say, I wonder if this is the right way to go. > > It's certainly a good thing to have a searchable database of such > changes, but IMO this should be (a) static and (b) editable only > by developers (including yourself, of course). The regular SF > tracker apparatus (Assigned to/Status/Priority, and so on) doesn't > seem to apply, and might be confusing. quickly @b: I'm not sure right who may edit it. I have set some permissions, where the six gretl developers I could identify in the sourceforge list are made admins of that new tracker. I'm not sure what that means for regular (logged-in) users, it would be nice if someone who's not in the sourceforge gretl developers list could test. -sven --===============2101749068397148025==-- From pyz@brama.com Fri May 2 19:04:04 2008 From: Max Pyziur To: gretl-devel@gretlml.univpm.it Subject: [Gretl-devel] Problems building and installing on Fedora 8 Date: Fri, 02 May 2008 19:01:25 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7578722933411227746==" --===============7578722933411227746== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Greetings, I've been trying to get gretl running on my Fedora 8 Core 2 machine. The pre-compile rpm fails with: error: Failed dependencies: libreadline.so.4 is needed by gretl-1.7.4-1gtk2.i586 even though readline is installed: # rpm -qa | grep readline readline-devel-5.2-10.fc8 readline-5.2-10.fc8 readline-5.2-10.fc8 readline-devel-5.2-10.fc8 I've created a symlink to libreadline.so.4 libreadline.so.4 -> libreadline.so.5.2 but that doesn't move the process forward. I've tried compiling an rpm from source by taking gretl-1.7.4/redhat/gretl.spec.in and modifying it and placing it in /usr/src/redhat/SPECS, and the binary into /usr/src/redhat/SOURCES and issueng the following command: rpmbuild -bb --clean gretl.spec (when in the /usr/src/redhat/SPECS directory) I get the following two sets of errors: 1) checking for LAPACK... no *** Could not run LAPACK test program, checking why... *** The test program failed to compile or link. See config.log for the *** exact error that occured. This may mean LAPACK was incorrectly installed *** or that you have moved LAPACK since it was installed. LAPACK is installed: # rpm -qa | grep lapack lapack-devel-3.1.1-2.fc8 lapack-devel-3.1.1-2.fc8 lapack-3.1.1-2.fc8 lapack-3.1.1-2.fc8 2) The rpmbuild fails with the following: mkdir .libs gcc -o .libs/gretlcli gretlcli.o complete.o ../lib/.libs/libgretl-1.0.so -ldl -L/usr/local/lib -lz -lxml2 -lglib-2.0 -lgmp -lfftw3 -lm -lreadline -ltermcap ../lib/.libs/libgretl-1.0.so: undefined reference to `dtrcon_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dgels_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dspsv_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dpptri_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dpptrf_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dsycon_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dpocon_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dsyev_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dgeev_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dtrtri_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dgetrf_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dgelss_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dorgqr_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dsytri_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dpotrf_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dsytrf_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dpotri_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dgecon_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dgeqrf_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dpotrs_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dgesvd_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dgetrs_' ../lib/.libs/libgretl-1.0.so: undefined reference to `dgetri_' collect2: ld returned 1 exit status make[1]: *** [gretlcli] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/gretl-1.7.4/cli' make: *** [cli] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.19815 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.19815 (%build) It seems that these errors have been encountered before (http://aur.archlinux.org/packages.php?ID=13752), but there is no solution offered. The contents of my gretl.spec file is appended below. Any help is appreciated. Apologies if this has been covered elsewhere; if there are links showing information as to how to get through this, that would be great. Max Pyziur pyz(a)brama.com ###################### # cat gretl.spec %define name gretl %define ver 1.7.4 %define rel mp %define prefix /usr Summary: econometrics package Name: %{name} Version: %{ver} Release: %{rel} License: GPL Group: Applications/Math Source: ftp://ricardo.ecn.wfu.edu/pub/gretl/gretl-%{ver}.tar.bz2 Buildroot: %{_tmppath}/%{name}-%{ver}-%{rel}-root Packager: Allin Cottrell URL: http://gretl.sourceforge.net/ Vendor: Allin Cottrell Docdir: %{prefix}/share/doc Requires: gtk+ >= 1.2.3 %description gretl is a free econometrics package. It comprises a shared library, a command-line client and a gui client that uses GTK. gretl offers several least-squares based estimators. Besides reading data files in its own format it also reads RATS 4 databases. It has a built-in spreadsheet for editing data, and uses gnuplot for graphing. It can output regression results in LaTeX format. %prep %setup -q %build %configure make %install rm -fr %{buildroot} %makeinstall %post /sbin/ldconfig %clean rm -fr %{buildroot} %files %doc COPYING README INSTALL %{prefix}/lib/lib* %{prefix}/lib/gretl*/* %{prefix}/bin/gretlcli %{prefix}/bin/gretl_x11 %{prefix}/bin/gretl %{prefix}/share/gretl/* %{prefix}/share/locale/* %{prefix}/share/man/* --===============7578722933411227746==-- From cottrell@wfu.edu Fri May 2 19:14:45 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Problems building and installing on Fedora 8 Date: Fri, 02 May 2008 19:14:36 -0400 Message-ID: In-Reply-To: Pine.LNX.4.60.0805021837260.30928@brama.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8675082569507280180==" --===============8675082569507280180== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 2 May 2008, Max Pyziur wrote: > I've been trying to get gretl running on my Fedora 8 Core 2 machine. > > The pre-compile rpm fails with: > error: Failed dependencies: > libreadline.so.4 is needed by gretl-1.7.4-1gtk2.i586 The only RHEL system I have available to me, for building the gretl rpm, is a fairly conservative one that uses readline 4.0. On Fedora 8, my recommendation would be to ignore the rpm and build from the current CVS source. http://sourceforge.net/cvs/?group_id=36234 Allin Cottrell. --===============8675082569507280180==-- From pyz@brama.com Sat May 3 14:32:04 2008 From: Max Pyziur To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Problems building and installing on Fedora 8 Date: Sat, 03 May 2008 14:29:40 -0400 Message-ID: In-Reply-To: alpine.LRH.1.10.0805021908260.7821@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1822517895795258154==" --===============1822517895795258154== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 2 May 2008, Allin Cottrell wrote: > On Fri, 2 May 2008, Max Pyziur wrote: > >> I've been trying to get gretl running on my Fedora 8 Core 2 machine. >> >> The pre-compile rpm fails with: >> error: Failed dependencies: >> libreadline.so.4 is needed by gretl-1.7.4-1gtk2.i586 > > The only RHEL system I have available to me, for building the > gretl rpm, is a fairly conservative one that uses readline 4.0. > On Fedora 8, my recommendation would be to ignore the rpm and > build from the current CVS source. > > http://sourceforge.net/cvs/?group_id=36234 > > Allin Cottrell. Much thanks for your reply. I have an Fedora Core 2 machine which I use as a home server. Your latest rpm build of gretl does install on that machine. However, I still can't build it on that machine. I have installed gretl-1.7.4-1gtk2.i586.rpm on my Core 2 using the --nodeps flag. As yet, I haven't tried using it, other than bringing up the initial interface. I have tried setting the PKG_CONFIG_PATH variable both on the FC2 as well as the FC8 machine in the hopes of getting gretl to build. No luck. Any further guidance would be appreciated. Thanks! Max Pyziur pyz(a)brama.com --===============1822517895795258154==-- From cottrell@wfu.edu Sat May 3 15:25:36 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Problems building and installing on Fedora 8 Date: Sat, 03 May 2008 15:25:25 -0400 Message-ID: In-Reply-To: Pine.LNX.4.60.0805031410580.30839@brama.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5874224501980241026==" --===============5874224501980241026== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 3 May 2008, Max Pyziur wrote: > I have an Fedora Core 2 machine which I use as a home server. > Your latest rpm build of gretl does install on that machine. > However, I still can't build it on that machine. > > I have installed gretl-1.7.4-1gtk2.i586.rpm on my Core 2 using > the --nodeps flag. As yet, I haven't tried using it, other than > bringing up the initial interface. > > I have tried setting the PKG_CONFIG_PATH variable both on the > FC2 as well as the FC8 machine in the hopes of getting gretl to > build. No luck. I'll go back to your previous message... "I get the following two sets of errors: 1) checking for LAPACK... no *** Could not run LAPACK test program, checking why... *** The test program failed to compile or link. See config.log for the *** exact error that occured. This may mean LAPACK was incorrectly installed *** or that you have moved LAPACK since it was installed." Well, like it says, take a look at config.log. Lapack 3.1.1 is installed, according to rpm -qa, but maybe libblas is missing, or maybe none of libf2c/libg2c/libgfortran can be found? liblapack is not usable without libblas, and the lapack+blas combination in turn is useless without a basic fortran library. On recent Fedora I'd expect that to be libgfortran.so; on older systems it was libg2c.so, and on even older systems, libf2c.so. "2) The rpmbuild fails with the following: mkdir .libs gcc -o .libs/gretlcli gretlcli.o complete.o ../lib/.libs/libgretl-1.0.so -ldl -L/usr/local/lib -lz -lxml2 -lglib-2.0 -lgmp -lfftw3 -lm -lreadline -ltermcap ../lib/.libs/libgretl-1.0.so: undefined reference to `dtrcon_'" That's just the same error: dtrcon_ is defined by liblapack. On my system: waverley:~$ /bin/ls -1 /usr/lib/liblapack* /usr/lib/liblapack.so /usr/lib/liblapack.so.3 /usr/lib/liblapack.so.3.1 /usr/lib/liblapack.so.3.1.1 waverley:~$ /bin/ls -1 /usr/lib/libblas* /usr/lib/libblas.so /usr/lib/libblas.so.3 /usr/lib/libblas.so.3.1 /usr/lib/libblas.so.3.1.1 waverley:~$ locate libgfortran.so /opt/gcc4/lib/libgfortran.so /opt/gcc4/lib/libgfortran.so.3 /opt/gcc4/lib/libgfortran.so.3.0.0 Allin Cottrell --===============5874224501980241026==-- From pyz@brama.com Sat May 3 16:46:37 2008 From: Max Pyziur To: gretl-devel@gretlml.univpm.it Subject: Progress!, was [Gretl-devel] Problems building and installing on Fedora 8 Date: Sat, 03 May 2008 16:43:50 -0400 Message-ID: In-Reply-To: alpine.LRH.1.10.0805031509560.26145@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7422508592919858861==" --===============7422508592919858861== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fedora 8, libblas is installed separately. However, reviewing your notes below I also installed blas-devel. This caused the rpmbuild/compilation to go farther. (It might be worthwhile to this dependency in the spec file). The following message registered after the configuration (which didn't before blas-devel): Configuration: Installation path: /usr Use readline library: yes Use gnuplot for graphs: yes Use PNG for gnuplot graphs: yes Use LaTeX for typesetting output: yes Gnu Multiple Precision support: yes MPFR support: yes LAPACK support: yes FFTW3 support: yes Build with GTK version: 2.0 Script syntax highlighting: yes Use installed gtksourceview: no Use GTK printing apparatus: yes Build with gnome support: 2.0 Build gretl documentation: no Use Lucida fonts: no Build message catalogs: yes Gnome installation prefix: /usr X-12-ARIMA support: yes TRAMO/SEATS support: yes Experimental audio support: no Now type 'make' to build gretl. + make ... but then it failed with the following: gcc -o .libs/gretl_x11 about.o boxplots.o calculator.o callbacks.o clipboard.o cmdstack.o console.o database.o datafiles.o dialogs.o dlgutils.o filelists.o fileselect.o filters.o fncall.o fnsave.o graph_page.o gpt_control.o gpt_dialog.o gretl.o guiprint.o gui_recode.o gui_utils.o helpfiles.o library.o menustate.o model_table.o objectsave.o obsbutton.o selector.o series_view.o session.o settings.o ssheet.o textbuf.o textutil.o toolbar.o treeutils.o update.o gtkfontselhack.o -pthread -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lart_lgpl_2 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgconf-2 -lORBit-2 -lgthread-2.0 -lrt -L/usr/src/redhat/BUILD/gretl-1.7.4/gui2/gtksourceview -lgtksourceview-lite -L/usr/src/redhat/BUILD/gretl-1.7.4/gui2/gtkextra-lite -lgtkextra-lite ../lib/.libs/libgretl-1.0.so -L/usr/lib -llapack -lblas -lgfortran -L/usr/local/lib -lz -lxml2 -lgmp -lfftw3 -lm -lgdk_pixbuf-2.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 /usr/bin/ld: skipping incompatible /usr/lib/libgnomeui-2.so when searching for -lgnomeui-2 /usr/bin/ld: skipping incompatible /usr/lib/libSM.so when searching for -lSM /usr/bin/ld: skipping incompatible /usr/lib/libbonoboui-2.so when searching for -lbonoboui-2 /usr/bin/ld: skipping incompatible /usr/lib/libgnomevfs-2.so when searching for -lgnomevfs-2 /usr/bin/ld: skipping incompatible /usr/lib/libgnomecanvas-2.so when searching for -lgnomecanvas-2 /usr/bin/ld: skipping incompatible /usr/lib/libgnome-2.so when searching for -lgnome-2 /usr/bin/ld: skipping incompatible /usr/lib/libpopt.so when searching for -lpopt /usr/bin/ld: skipping incompatible /usr/lib/libpopt.so when searching for -lpopt /usr/bin/ld: cannot find -lpopt collect2: ld returned 1 exit status make[1]: *** [gretl_x11] Error 1 make[1]: Leaving directory `/usr/src/redhat/BUILD/gretl-1.7.4/gui2' make: *** [gui2] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.91719 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.91719 (%build) ... How should this be pursued? Much thanks for all of your help. Max Pyziur pyz(a)brama.com On Sat, 3 May 2008, Allin Cottrell wrote: > On Sat, 3 May 2008, Max Pyziur wrote: > >> I have an Fedora Core 2 machine which I use as a home server. >> Your latest rpm build of gretl does install on that machine. >> However, I still can't build it on that machine. >> >> I have installed gretl-1.7.4-1gtk2.i586.rpm on my Core 2 using >> the --nodeps flag. As yet, I haven't tried using it, other than >> bringing up the initial interface. >> >> I have tried setting the PKG_CONFIG_PATH variable both on the >> FC2 as well as the FC8 machine in the hopes of getting gretl to >> build. No luck. > > I'll go back to your previous message... > > "I get the following two sets of errors: > 1) checking for LAPACK... no > *** Could not run LAPACK test program, checking why... > *** The test program failed to compile or link. See config.log for the > *** exact error that occured. This may mean LAPACK was incorrectly installed > *** or that you have moved LAPACK since it was installed." > > Well, like it says, take a look at config.log. Lapack 3.1.1 is > installed, according to rpm -qa, but maybe libblas is missing, or > maybe none of libf2c/libg2c/libgfortran can be found? liblapack is > not usable without libblas, and the lapack+blas combination in > turn is useless without a basic fortran library. On recent Fedora > I'd expect that to be libgfortran.so; on older systems it was > libg2c.so, and on even older systems, libf2c.so. > > "2) The rpmbuild fails with the following: > mkdir .libs > gcc -o .libs/gretlcli gretlcli.o complete.o > ../lib/.libs/libgretl-1.0.so > -ldl -L/usr/local/lib -lz -lxml2 -lglib-2.0 -lgmp -lfftw3 -lm > -lreadline -ltermcap > ../lib/.libs/libgretl-1.0.so: undefined reference to `dtrcon_'" > > That's just the same error: dtrcon_ is defined by liblapack. > > On my system: > > waverley:~$ /bin/ls -1 /usr/lib/liblapack* > /usr/lib/liblapack.so > /usr/lib/liblapack.so.3 > /usr/lib/liblapack.so.3.1 > /usr/lib/liblapack.so.3.1.1 > waverley:~$ /bin/ls -1 /usr/lib/libblas* > /usr/lib/libblas.so > /usr/lib/libblas.so.3 > /usr/lib/libblas.so.3.1 > /usr/lib/libblas.so.3.1.1 > waverley:~$ locate libgfortran.so > /opt/gcc4/lib/libgfortran.so > /opt/gcc4/lib/libgfortran.so.3 > /opt/gcc4/lib/libgfortran.so.3.0.0 > > Allin Cottrell > > > > > _______________________________________________ > Gretl-devel mailing list > Gretl-devel(a)lists.wfu.edu > http://lists.wfu.edu/mailman/listinfo/gretl-devel > --===============7422508592919858861==-- From cottrell@wfu.edu Sat May 3 17:25:41 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: Progress!, was [Gretl-devel] Problems building and installing on Fedora 8 Date: Sat, 03 May 2008 17:25:31 -0400 Message-ID: In-Reply-To: Pine.LNX.4.60.0805031638341.17017@brama.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5830728665126961134==" --===============5830728665126961134== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 3 May 2008, Max Pyziur wrote: > On Fedora 8, libblas is installed separately. However, reviewing > your notes below I also installed blas-devel. This caused the > rpmbuild/compilation to go farther. (It might be worthwhile to > this dependency in the spec file). The difficulty here is this: liblapack is useless without _some_ form of libblas (BLAS = Basic Linear Algebra System), but there are various blas's. There's the libblas from the same (netlib) source as lapack itself, and there are versions that are tuned for best performance on a specific processor. I'd say that it's really up to the OS/distro to ensure that if you choose to install lapack, some suitable form of blas is pulled in as a dependency. Or in other words, this seems like a Fedora packaging bug to me. > The following message registered after the configuration (which > didn't before blas-devel): > Configuration... [snip] > Build with gnome support: 2.0 So far as the configure script is concerned, then, gnome is OK. > but then it failed with the following: > > gcc -o .libs/gretl_x11 [object modules] > -pthread -lgnomeui-2 -lSM -lICE -lbonoboui-2 > -lgnomevfs-2 -lgnomecanvas-2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation > -lart_lgpl_2 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangocairo-1.0 > -lpango-1.0 -lcairo -lgconf-2 -lORBit-2 -lgthread-2.0 -lrt > -L/usr/src/redhat/BUILD/gretl-1.7.4/gui2/gtksourceview -lgtksourceview-lite > -L/usr/src/redhat/BUILD/gretl-1.7.4/gui2/gtkextra-lite -lgtkextra-lite > ../lib/.libs/libgretl-1.0.so -L/usr/lib -llapack -lblas -lgfortran > -L/usr/local/lib -lz -lxml2 -lgmp -lfftw3 -lm -lgdk_pixbuf-2.0 -lgobject-2.0 > -lgmodule-2.0 -ldl -lglib-2.0 > /usr/bin/ld: skipping incompatible /usr/lib/libgnomeui-2.so when searching for > -lgnomeui-2 [ plus more "skipping incompatible" messages for gnome-related libraries.] But so far as the linker is concerned, gnome is a mess! Very weird. What's wrong with your gnome libraries that the linker finds them "incompatible"? Is this a 64-bit system? You could try passing the option "--without-gnome" to configure (or put it in the .spec file), since the linker is not barfing on the other libraries that gretl wants. And in fact, you don't lose much by dropping the gnome linkage. Allin Cottrell --===============5830728665126961134==-- From pyz@brama.com Sun May 4 14:42:18 2008 From: Max Pyziur To: gretl-devel@gretlml.univpm.it Subject: Re: Progress!, was [Gretl-devel] Problems building and installing on Fedora 8 Date: Sun, 04 May 2008 14:27:27 -0400 Message-ID: In-Reply-To: Pine.LNX.4.60.0805041256230.6532@brama.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3380095534547272678==" --===============3380095534547272678== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Trying to unravel my own thread, I appended the following lines to gretl.spec on the 64-bit machine: %{prefix}/share/gretl/* %{prefix}/share/locale/* %{prefix}/share/man/* %{prefix}/include/* %{prefix}/lib64/* and have reduced errors to the following two lines on the 64-bit machine: RPM build errors: File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/lib* File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/gretl*/* On the 32-bit laptop, I appended the following lines to the gretl.spec file: %{prefix}/include/* %{prefix}/lib/pkgconfig/* and the compilation is successful. The 32-bit laptop compilation did not use the "--without-gnome" directive in the "configure" section. The rpm installs successfully both on the 32-bit machine and the 64-bit machine. On the 64-bit machine, executing: "gretl" brings up the gretl window and has the following messages in the terminal window Gtk-Message: Failed to load module "gnomebreakpad": libgnomebreakpad.so: cannot open shared object file: No such file or directory setlocale(LC_NUMERIC, "en_US.UTF-8") returned en_US.UTF-8 "gretl_x11" produces the same results as "gretl" "gretlcli" produces a command-line interface w/ a "?" prompt. On the 32-bit machine, executing both "gretl" and "gretl_x11" brings up the gretl window and has the following message in the terminal window setlocale(LC_NUMERIC, "en_US.UTF-8") returned en_US.UTF-8 "gretlcli" produces a command-line interface on a second try. Initially, it produced the following: pyz(a)mercury ~> gretlcli gretl version 1.7.4 Copyright Ramu Ramanathan, Allin Cottrell and Riccardo "Jack" Lucchetti This is free software with ABSOLUTELY NO WARRANTY Current session: 2008/05/04 14:17 /home/pyz/.gretl/x12arima: No such file or directory /home/pyz/.gretl/tramo: No such file or directory No such file or directory No such file or directory No such file or directory No such file or directory Thanks! And what else is necessary to get the compilation to work on the 64-bit machine? Max Pyziur pyz(a)brama.com On Sun, 4 May 2008, Max Pyziur wrote: > Thanks again for your help. > > I'm now trying to compile/build rpms on two different Fedora 8 machines: > a 64-bit system Intel Core 2 Duo box, and > a Dell 600M Inspiron laptop w/ a Pentium M processor > > I've tried your suggestion of including "--without-gnome" in the "configure" > section of the spec file on the 64-bit machine. > > The rpm compilation/build proceeds further and ends with the output appended > below. > > On the laptop, no "--without-gnome" directive was used. However, on the rpm > build the results were similar to those for the 64-bit machine (see second > section below). > > Thanks in advance. > > Max Pyziur > pyz(a)brama.com > > > [...] > > >> But so far as the linker is concerned, gnome is a mess! Very >> weird. What's wrong with your gnome libraries that the linker >> finds them "incompatible"? Is this a 64-bit system? >> >> You could try passing the option "--without-gnome" to configure >> (or put it in the .spec file), since the linker is not barfing on >> the other libraries that gretl wants. And in fact, you don't lose >> much by dropping the gnome linkage. >> >> Allin Cottrell >> > > > ################ RPM build error on 64-bit machine ################### > RPM build errors: > File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/lib* > File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/gretl*/* > Installed (but unpackaged) file(s) found: > /usr/include/adf_kpss.h > /usr/include/bhhh_max.h > /usr/include/bootstrap.h > /usr/include/calendar.h > /usr/include/compare.h > /usr/include/compat.h > /usr/include/csvdata.h > /usr/include/dataio.h > /usr/include/dataset.h > /usr/include/dbread.h > /usr/include/describe.h > /usr/include/discrete.h > /usr/include/estimate.h > /usr/include/forecast.h > /usr/include/genfuncs.h > /usr/include/genmain.h > /usr/include/graphing.h > /usr/include/gretl_commands.h > /usr/include/gretl_errors.h > /usr/include/gretl_fft.h > /usr/include/gretl_func.h > /usr/include/gretl_intl.h > /usr/include/gretl_list.h > /usr/include/gretl_matrix.h > /usr/include/gretl_model.h > /usr/include/gretl_panel.h > /usr/include/gretl_paths.h > /usr/include/gretl_prn.h > /usr/include/gretl_restrict.h > /usr/include/gretl_string_table.h > /usr/include/gretl_utils.h > /usr/include/gretl_win32.h > /usr/include/gretl_www.h > /usr/include/gretl_xml.h > /usr/include/interact.h > /usr/include/johansen.h > /usr/include/kalman.h > /usr/include/libgretl.h > /usr/include/libset.h > /usr/include/matrix_extra.h > /usr/include/missing.h > /usr/include/modelprint.h > /usr/include/modelspec.h > /usr/include/monte_carlo.h > /usr/include/nls.h > /usr/include/nonparam.h > /usr/include/objstack.h > /usr/include/options.h > /usr/include/plotspec.h > /usr/include/plugins.h > /usr/include/printout.h > /usr/include/printscan.h > /usr/include/pvalues.h > /usr/include/qr_estimate.h > /usr/include/random.h > /usr/include/strutils.h > /usr/include/subsample.h > /usr/include/system.h > /usr/include/texprint.h > /usr/include/transforms.h > /usr/include/tsls.h > /usr/include/usermat.h > /usr/include/var.h > /usr/include/varprint.h > /usr/include/vartest.h > /usr/lib64/libgretl-1.0.la > /usr/lib64/libgretl-1.0.so > /usr/lib64/libgretl-1.0.so.0 > /usr/lib64/libgretl-1.0.so.0.0.44 > /usr/lib64/pkgconfig/gretl.pc > > > ################## RPM Build error on 32-bit machine ################# > RPM build errors: > Installed (but unpackaged) file(s) found: > /usr/include/adf_kpss.h > /usr/include/bhhh_max.h > /usr/include/bootstrap.h > /usr/include/calendar.h > /usr/include/compare.h > /usr/include/compat.h > /usr/include/csvdata.h > /usr/include/dataio.h > /usr/include/dataset.h > /usr/include/dbread.h > /usr/include/describe.h > /usr/include/discrete.h > /usr/include/estimate.h > /usr/include/forecast.h > /usr/include/genfuncs.h > /usr/include/genmain.h > /usr/include/graphing.h > /usr/include/gretl_commands.h > /usr/include/gretl_errors.h > /usr/include/gretl_fft.h > /usr/include/gretl_func.h > /usr/include/gretl_intl.h > /usr/include/gretl_list.h > /usr/include/gretl_matrix.h > /usr/include/gretl_model.h > /usr/include/gretl_panel.h > /usr/include/gretl_paths.h > /usr/include/gretl_prn.h > /usr/include/gretl_restrict.h > /usr/include/gretl_string_table.h > /usr/include/gretl_utils.h > /usr/include/gretl_win32.h > /usr/include/gretl_www.h > /usr/include/gretl_xml.h > /usr/include/interact.h > /usr/include/johansen.h > /usr/include/kalman.h > /usr/include/libgretl.h > /usr/include/libset.h > /usr/include/matrix_extra.h > /usr/include/missing.h > /usr/include/modelprint.h > /usr/include/modelspec.h > /usr/include/monte_carlo.h > /usr/include/nls.h > /usr/include/nonparam.h > /usr/include/objstack.h > /usr/include/options.h > /usr/include/plotspec.h > /usr/include/plugins.h > /usr/include/printout.h > /usr/include/printscan.h > /usr/include/pvalues.h > /usr/include/qr_estimate.h > /usr/include/random.h > /usr/include/strutils.h > /usr/include/subsample.h > /usr/include/system.h > /usr/include/texprint.h > /usr/include/transforms.h > /usr/include/tsls.h > /usr/include/usermat.h > /usr/include/var.h > /usr/include/varprint.h > /usr/include/vartest.h > /usr/lib/pkgconfig/gretl.pc > > --===============3380095534547272678==-- From pyz@brama.com Sun May 4 18:46:06 2008 From: Max Pyziur To: gretl-devel@gretlml.univpm.it Subject: Re: Progress!, was [Gretl-devel] Problems building and installing on Fedora 8 Date: Sun, 04 May 2008 13:10:07 -0400 Message-ID: In-Reply-To: alpine.LRH.1.10.0805031712060.21625@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0781297457480706409==" --===============0781297457480706409== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Thanks again for your help. I'm now trying to compile/build rpms on two different Fedora 8 machines: a 64-bit system Intel Core 2 Duo box, and a Dell 600M Inspiron laptop w/ a Pentium M processor I've tried your suggestion of including "--without-gnome" in the "configure" section of the spec file on the 64-bit machine. The rpm compilation/build proceeds further and ends with the output appended below. On the laptop, no "--without-gnome" directive was used. However, on the rpm build the results were similar to those for the 64-bit machine (see second section below). Thanks in advance. Max Pyziur pyz(a)brama.com [...] > But so far as the linker is concerned, gnome is a mess! Very > weird. What's wrong with your gnome libraries that the linker > finds them "incompatible"? Is this a 64-bit system? > > You could try passing the option "--without-gnome" to configure > (or put it in the .spec file), since the linker is not barfing on > the other libraries that gretl wants. And in fact, you don't lose > much by dropping the gnome linkage. > > Allin Cottrell > ################ RPM build error on 64-bit machine ################### RPM build errors: File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/lib* File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/gretl*/* Installed (but unpackaged) file(s) found: /usr/include/adf_kpss.h /usr/include/bhhh_max.h /usr/include/bootstrap.h /usr/include/calendar.h /usr/include/compare.h /usr/include/compat.h /usr/include/csvdata.h /usr/include/dataio.h /usr/include/dataset.h /usr/include/dbread.h /usr/include/describe.h /usr/include/discrete.h /usr/include/estimate.h /usr/include/forecast.h /usr/include/genfuncs.h /usr/include/genmain.h /usr/include/graphing.h /usr/include/gretl_commands.h /usr/include/gretl_errors.h /usr/include/gretl_fft.h /usr/include/gretl_func.h /usr/include/gretl_intl.h /usr/include/gretl_list.h /usr/include/gretl_matrix.h /usr/include/gretl_model.h /usr/include/gretl_panel.h /usr/include/gretl_paths.h /usr/include/gretl_prn.h /usr/include/gretl_restrict.h /usr/include/gretl_string_table.h /usr/include/gretl_utils.h /usr/include/gretl_win32.h /usr/include/gretl_www.h /usr/include/gretl_xml.h /usr/include/interact.h /usr/include/johansen.h /usr/include/kalman.h /usr/include/libgretl.h /usr/include/libset.h /usr/include/matrix_extra.h /usr/include/missing.h /usr/include/modelprint.h /usr/include/modelspec.h /usr/include/monte_carlo.h /usr/include/nls.h /usr/include/nonparam.h /usr/include/objstack.h /usr/include/options.h /usr/include/plotspec.h /usr/include/plugins.h /usr/include/printout.h /usr/include/printscan.h /usr/include/pvalues.h /usr/include/qr_estimate.h /usr/include/random.h /usr/include/strutils.h /usr/include/subsample.h /usr/include/system.h /usr/include/texprint.h /usr/include/transforms.h /usr/include/tsls.h /usr/include/usermat.h /usr/include/var.h /usr/include/varprint.h /usr/include/vartest.h /usr/lib64/libgretl-1.0.la /usr/lib64/libgretl-1.0.so /usr/lib64/libgretl-1.0.so.0 /usr/lib64/libgretl-1.0.so.0.0.44 /usr/lib64/pkgconfig/gretl.pc ################## RPM Build error on 32-bit machine ################# RPM build errors: Installed (but unpackaged) file(s) found: /usr/include/adf_kpss.h /usr/include/bhhh_max.h /usr/include/bootstrap.h /usr/include/calendar.h /usr/include/compare.h /usr/include/compat.h /usr/include/csvdata.h /usr/include/dataio.h /usr/include/dataset.h /usr/include/dbread.h /usr/include/describe.h /usr/include/discrete.h /usr/include/estimate.h /usr/include/forecast.h /usr/include/genfuncs.h /usr/include/genmain.h /usr/include/graphing.h /usr/include/gretl_commands.h /usr/include/gretl_errors.h /usr/include/gretl_fft.h /usr/include/gretl_func.h /usr/include/gretl_intl.h /usr/include/gretl_list.h /usr/include/gretl_matrix.h /usr/include/gretl_model.h /usr/include/gretl_panel.h /usr/include/gretl_paths.h /usr/include/gretl_prn.h /usr/include/gretl_restrict.h /usr/include/gretl_string_table.h /usr/include/gretl_utils.h /usr/include/gretl_win32.h /usr/include/gretl_www.h /usr/include/gretl_xml.h /usr/include/interact.h /usr/include/johansen.h /usr/include/kalman.h /usr/include/libgretl.h /usr/include/libset.h /usr/include/matrix_extra.h /usr/include/missing.h /usr/include/modelprint.h /usr/include/modelspec.h /usr/include/monte_carlo.h /usr/include/nls.h /usr/include/nonparam.h /usr/include/objstack.h /usr/include/options.h /usr/include/plotspec.h /usr/include/plugins.h /usr/include/printout.h /usr/include/printscan.h /usr/include/pvalues.h /usr/include/qr_estimate.h /usr/include/random.h /usr/include/strutils.h /usr/include/subsample.h /usr/include/system.h /usr/include/texprint.h /usr/include/transforms.h /usr/include/tsls.h /usr/include/usermat.h /usr/include/var.h /usr/include/varprint.h /usr/include/vartest.h /usr/lib/pkgconfig/gretl.pc --===============0781297457480706409==-- From cottrell@wfu.edu Sun May 4 20:29:08 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: Progress!, was [Gretl-devel] Problems building and installing on Fedora 8 Date: Sun, 04 May 2008 20:29:04 -0400 Message-ID: In-Reply-To: Pine.LNX.4.60.0805041256230.6532@brama.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8088780440240911760==" --===============8088780440240911760== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 4 May 2008, Max Pyziur wrote: > Thanks again for your help. > > I'm now trying to compile/build rpms on two different Fedora 8 machines: > a 64-bit system Intel Core 2 Duo box, and > a Dell 600M Inspiron laptop w/ a Pentium M processor > > I've tried your suggestion of including "--without-gnome" in the > "configure" section of the spec file on the 64-bit machine. > > The rpm compilation/build proceeds further and ends with the > output appended below. > > On the laptop, no "--without-gnome" directive was used. However, > on the rpm build the results were similar to those for the > 64-bit machine (see second section below). > > ################ RPM build error on 64-bit machine ################### > RPM build errors: > File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/lib* > File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/gretl*/* > Installed (but unpackaged) file(s) found: > /usr/include/adf_kpss.h > /usr/include/bhhh_max.h... I'm not an rpm expert, but it appears your .spec file must be wrong. RPM is apparently complaining about the fact that the libgretl headers (e.g. /usr/include/adf_kpss.h) are being installed but not packaged. That's to be expected, in a sense: the headers are installed by a normal "make install", but one would not expect them to be included in a binary .rpm, only in the associated "devel" .rpm. I suggest either (a) taking a closer look at the RPM documentation, or (b) ignoring RPM and just installing gretl independently of that mechanism. If you're looking to create an RPM that you can redistribute then (a) will be required, otherwise (b) will probably save you grief. Allin Cottrell --===============8088780440240911760==-- From cottrell@wfu.edu Sun May 4 20:49:54 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: Progress!, was [Gretl-devel] Problems building and installing on Fedora 8 Date: Sun, 04 May 2008 20:49:50 -0400 Message-ID: In-Reply-To: Pine.LNX.4.60.0805041407480.21325@brama.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0523759101422133688==" --===============0523759101422133688== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit This is in reverse order, but... On Sun, 4 May 2008, Max Pyziur wrote: > Trying to unravel my own thread, I appended the following lines > to gretl.spec on the 64-bit machine: > %{prefix}/share/gretl/* > %{prefix}/share/locale/* > %{prefix}/share/man/* > %{prefix}/include/* That last line is wrong, isn't it? You don't want the include directory in the spec if you're building a binary rpm. > On the 64-bit machine, executing: > "gretl" brings up the gretl window and has the following messages in the > terminal window > Gtk-Message: Failed to load module "gnomebreakpad": libgnomebreakpad.so: > cannot open shared object file: No such file or directory I have no idea about libgnomebreakpad.so; it's not referenced anywhere in the gretl build files. I suppose it's being dragged in by pkg-config, in which case the pkg-config setup is broken. Allin Cottrell. --===============0523759101422133688==-- From ignacio.diaz-emparanza@ehu.es Tue May 6 06:26:26 2008 From: Ignacio Diaz-Emparanza To: gretl-devel@gretlml.univpm.it Subject: [Gretl-devel] ARMAX and diffs Date: Tue, 06 May 2008 12:26:22 +0200 Message-ID: <200805061226.22766.ignacio.diaz-emparanza@ehu.es> In-Reply-To: alpine.LRH.1.10.0805042042250.3717@ricardo.ecn.wfu.edu Content-Type: multipart/mixed; boundary="===============4622637573314744714==" --===============4622637573314744714== Content-Type: application/x-gzip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="import-NE.gdt" MIME-Version: 1.0 H4sIAAAAAAAAA31ay45bxxHd6ysYLowECMdd1W9bIyMPBcjCjgE7C68CWkMJA0gamUMZ8SflO/Jj OcXb1RyJ9wRaaGZYrO6ux6lT1f38m3+/e7v59XB8vH94f7uVm7DdHN6/eri7f//mdvvPH/+2a9tv Xjx7/ru//uMvP/70/cvNm+Ph9PZuf9pvfvjphx9ffrvZzr/c3J3uti+ePXt+kXmiWLab9/t3h9vt /bsPD8fT7ruX283r4+GXj1juNwjodvN42h9PDz8/4rfe5Ksgtpe78x80hPxVSNvN6bcP0HG6f3fY PR6O94dHrPj81/3xfv/z28Pj5tXDx/en2216+tex7k/bZ5u3+58Pb2+3fz9vYf8KW8N3Du8Pxzf/ /c/p/tX+8Y+bb+9Nz91h8/Lj8eFx++zLa013/3qi63bz4YjdHPebu/vXhyNOc7+3r//5pdQgQSH5 YY8/Y1dP/nQ67t8/vn44voO2+9evV5f54bLI72GEL96cvv7il48Pp69hjPBV0OWXP6x+9/tPv3v7 9Ivxky9+OY2HXyB6OP66P8Ew05ba4ZqzLvjh9f7t42G7SL5IQWJqN7HmsPnuT5uAf8+/tA+Wj3PN peiNKD6WmqLEG0iGK7kSq4rc4KOwKZJTXzR+LlaDispNaTVvSuoSbsR+vBKrNfW2fFZzrGVRfC0W Sg03Dbvb7ErTur5obimWviy6k1ZikOVA14I15HzTTImWVtY3l6oqzldMw04ktVBudM0mEkqM+PC8 qYzD5rJuPJi1Q+N53V2BjTM5cBFtrd0E+0xa6LGtH6TE3BtcYIbRKDjv+ccrsRbFXGAqUhUdprwS 67CKLqvWlGTZ6EoEpFAXqV2OkvLy85WRpcUShpxID6muC9aYBZ4/f6ZSmpR1uVKgcWxvV2NMicjV EOPwacshrXs3txLi0LBD4AQlUdBh/rzYbtdzQLiumqUjfXznqWZtYV1OQgI8joVrbLGtn6Ih/9PQ t1MDAyZYUnU7J3iXWMU8Hru7TRXZuSrXQ8syXNpzr8QZHTFQh0OjalGyai0luJVLkhpJDKSMZT1Y YgAY0NNK1SVrxOJB1jMIfm/VgwVZEkNYF0SEBBl2iSkLi9LWsMexQ2RAJAeWgKR2dwAzNHRiwN5C cP8C+TLxW49FivvNMoDtLwJ2mlsQPwfi4FJ7V7eM5FAScXHtCKbxmYiBIZGDh2WautRI5BCAqKgj tBLyJbBgwGLdTYOgrUJsCPcjDn2HuTBEkNCKunGQBlFZLiFM/Jg7zUWZxhaAWQ5umhrzHlbWGoag VoR1YG4WnGV6RVKgXkmI7JkppQUSEL1qjMPCUmtjbgbHgTOG/zIymQUsDKxzYYBiJMAPIIyuD0aM WoiglfXuOwwtRhKxteUcPRATsJpssNXmYho0BmbqjOzNHq8oPmRZIHVJXoU7wJ2sm7UH3/oOYZEy 8UgOUsI0TE3M0gkqdEJ/DQyDAQwxqdtFaOFMASTLPQf2FjPzHNDVQ0abJBYyKO1t1k4pNXdykghL x8kBQDEDyROwDagZpm6JcQocsqVpQW2RuAR0LE0wxF4rWTaiTKgDSO+ZgLrBs+ejFoAJCwRwzrFz ySDAzL/gEjNgUDCoVUpAxiWngaIs8sF0Yx2LaQL407iaiQ6MyaikLLBi9fNKROFj5uvwbpvukNgJ rlqNdWIioTYGbhkh52iBIMgkM+HbC8JUOz3zWw8z4VqfdPRKrsFZQ0cUxoyMHPghStfOxKpIEY+p yviEAvE94pEatbOoSsHokNuudwZrySLTaxxaH2IToFOO86w80+DO7JkbM3gqS1zVC+jS1Ii5dY/Q Hco2g0h0l08iryoTy2D/rk46VQebVA8UdAzMJgDm6ABZU1HW0YBVTYqvNLvhdDfwruVGLQdSOgll B7MjuaihdYcodNyRLZtUJuGV2ipTCHYfPfHr/2nfYutOheBhxjKygCRdEBnNOZEruXqcJDTBrA5g 0eZZUUtiCJBR05z5oYCzgpZQVGbYVcAzUxdB6Ia9KhpVVs4a2mgvzKBDvGAAbBwLm3Zmk3ApsYKu PBGPxXxBzJ2kWBKDANjEawQYL2sVEiiFnxYJIsR4YIzBkyyio2WAV5Ox4bE9ZDktAg3qJhmAZ5g3 DLXdo+ifMuOPyIXifSKIJhprYmgUXBtBjZXF2jcWpbV59gPsOzNNilnzBG+DM+aRHJq7FVHa2boC Hjo2b/Mmlh3ZRjRjWWt3mIMBO90N2Honm0Mc5Tb5SipMLmvscxSB4lYYBgFatDvRBJdkYiGmPqFK GuUrAl959oJqsJlAQl/l3iglMRoMiI9zFtGDUmwJ6DbcZ9hdId5AL9ed3CIa2AgEZDlcOLDS+o3O oc95GY2nKNlrLCxMiW0J/dK7VyPelHBFZz47dDvKWvJqtWecVSuFtFRV0kzJ3lNlVkHhcNqGlpbu rxufHWUj0F43Gwe8LBsrk0PFnbNLrV0ZDwXyeX23Dpa6FqXC+S+SkzWwNvfwZbOFDVOHMHJ1oGks f5CAsycEScus0gP2cpz0HBDOZo1V0AVVx4tWCuMYzVw6FYIps4YErYUDAQK2MYJebLY1FkP/xfAb hkWZGuvaiIZVmALw9Owo6G9Y4UCV8q4fqhl7sK7FSy0KW61sooauVC6AgRrC/Nsnldt1YzqM8lll G/pQCWm3VDWnGS/aGH8osJiP0LQWdowMvnXJXeQQWxbdkodmrnROBSrnwI6SUTPTlp9eE+ArjJCi 6kwWar0wq33gC+kJWeqMZdidjVcUeXKnsaJQZxZBsLGoAhGuc5igPTEqjOZ1EgHkBhuJA2/zZfDb Ahu/onDn2UiW1hm1rhImtRZUDiGQizNMIiVo2xmUgmGEi1nQpNDrGFBb58JSWflDkaqeOBISZVQF 7pXZ+gl6KAJWqETNBYEFdF2tU0XOjFkX1AofqO8SQoAhqcGEA5+0zHLIEHfOjxEPLPiwt+xBqqKs l0SzV8NlINdY5QADn3INsMBsYm3h5aZNWZtTa5xzajiFDcErsuZS13phONWskfDIi0lpJBuG+Wmh nF6hxd79sxLp/QXAe1YUkA3GgpHQ82Kn1MIugBr4VJmtAbrjztqrXrMDZMnCIy/3NlFZwbCZM4Ak Dt9GnBmlQhlrF8BFAWE9ST9foA85Y9gs0VB6ZrlCs8YOjE8mPu5s+kXLmo25PDfQxzIAD6inQx/w p9FRAYLAl81aWNAbsMzLpIC6RilpmlcLO2yOOQ4IluvkmrEyam3wXS73KgAXytUvVAX51Fi1B7bP C0gEDOuuCmiZ9yx6vv8m8ZfKRCrkGmP+KKd9DgxRTJWFXzrfjc8wZRdidiXvxwCoNiKGCtXjnI/V wvWBHF7CvgD1WZ4DPS9lvCmLA2y+ZA8Esb6MCSYts3myRxqMQAg6XCN+53ckhrsglWXt2Yf1Yqgf yyMTLWq3CecvCf59qhFI3sYV+Q7lw/r48xsWuVLZUODGmwXUIzTyrvIzwQpuj5g/r20ZPd6zXCsE Lkjzxy4FvxBBKLSJwnlbaN9h+/WFSzj34stLDBuY1PEs43NJ2KPbBf15OXvKhG6+rh1azTXRXxPA in0897lauy+3+stbIA2lV3YaRGCEyvNp0Kuo3TWvnwdkQ3VY3PBQhFkcySRjPXRd1QdxV4IpZ5x9 7BKNTQPvIt5GcvnbJmD7ZQz5uWBD1137iDSxW9V1m4PYRXuKlAdOFOt01teupRUPXlD1yPYI9OxS XGMPFTYgp6kBgbicpts7CLLHFNucYgKStSA11v0N7tFdjXURMSbib7RnNhNenJOzXZqsxpqgG+3o iT18jWlQyY7jjlRE6BGxDJjK4ymc2HB72GpFUOzyZcBKI55G2bWMOq+1sx4gEtugYQPXGK7Q+Rrw +hitICBHNNqdCDM2UM+q93nlVJGSxH0NYOPmBVAG746uFS6XDZ6DNpMieyyxqGcrmHFnaQD6Yx8u ISBdgUPrZ0F5s/hbkloulxQrSd1bHk6JIL5Kd3h+sOeRiLrVSRbEBg/660JN3aaJRBKJgK5iyax0 ebu4kljVLmGHxWPpLFeTCni91xlwxRkgVyp7TWmguAJ5KoPcjIqUJv/Ubsi2HhdWWxxtrMQxAxUb 7I597VKZw85r3xjPLmNfMEJjtRCZahfvi3MA9tb7ETe2Fj0KgTv2pHBdZbMnom6TaD0kOXXPZ8qx LBfRYgeCUF3tLs9RrwBc1veoQTOid+wLEoUUJFQje5IzMhv9SSLlFdTE3qQuxSMlTSSzNQDocdDF MyglSQiWqWru3ixbj6jCSrsN8UdS7eBQJRCgMHJ0PoMGC8DMNLY0X2DYmx9dDzMY0Z4kLB9G0AGW CkjR8zOLZYvZHlNcr2z/zVfe9vt8r//i2f8ATJ6WAxAwAAA= --===============4622637573314744714==-- From cottrell@wfu.edu Tue May 6 09:12:54 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] ARMAX and diffs Date: Tue, 06 May 2008 09:12:46 -0400 Message-ID: In-Reply-To: 200805061226.22766.ignacio.diaz-emparanza@ehu.es MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3532640808853742385==" --===============3532640808853742385== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 6 May 2008, Ignacio Diaz-Emparanza wrote: > I was trying to estimate an ARIMA model with a intervention (a > level shift)... and found what I think is an inconsistency in > the treatment of the explanatory variable. > > Could you, Allin or Jack, please correct this behaviour? Thanks, Ignacio. I think I'm going to wait for Jack's reaction on this point rather than jumping in myself. But just to check my understanding: your point is that in an ARIMA model any exogenous variables should be subject to the same differencing that is applied to y(t)? Allin. --===============3532640808853742385==-- From r.lucchetti@univpm.it Tue May 6 09:24:19 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] ARMAX and diffs Date: Tue, 06 May 2008 15:24:16 +0200 Message-ID: In-Reply-To: 200805061226.22766.ignacio.diaz-emparanza@ehu.es MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5005175726708367178==" --===============5005175726708367178== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Tue, 6 May 2008, Ignacio Diaz-Emparanza wrote: > I was trying to estimate an ARIMA model with a intervention (a level shift). ... > Could you, Allin or Jack, please correct this behaviour? Ignacio, after some pondering, I believe you're right. What I would consider a proper fix for this issue, however, takes us right in the middle of the parallel discussion about backward-incompatible changes. Let me explain. To recap briefly what's in the manual already, what we currently have under the "arima" heading is in fact a pair of quite different things. On one hand, we have that ML estimation (carried out via the Kalman filter) estimates a model like (1) A(L) (y_t - x_t'\beta) = C(L) e_t If we believe that the differencing operator is part and parcel of the A(L) polynomial, we ought to difference x_t as well, not just y_t (contrary to what we do now). This would be, in itself, a backward-incompatible change already. Now consider the class of models that we handle via conditional ML: here we have (2) A(L) y_t = x_t'\beta + C(L) e_t. As the manual says, whenever x_t includes anything more than the constant, (1) and (2) are fundamentally different models, since the term x_t'\beta can be considered as the conditional mean of y_t with respect to two different information set. In the context of (2), the A(L) polynomial does _not_ apply to x_t, so there's no reason to difference x_t too. The important thing here is that (1) is the formulation generally adopted in the time-series literature, while (2) resembles more the models econometricians use, (ARDL models, GARCH models, and so on). If we implement the change proposed by Ignacio (which, I repeat, makes perfect sense for (1)), the two models would diverge in their behaviour and interpretation even more, to the point that I wouldn't find it inconceivable to have two separate commands and two different GUI menu entries for (1) and (2) (although, it must be said, it'd be relatively easy to estimate (1) via conditional ML if we wanted to). Opinions? Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti --===============5005175726708367178==-- From cottrell@wfu.edu Tue May 6 12:14:52 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] new tracker for incompatible changes Date: Tue, 06 May 2008 12:14:46 -0400 Message-ID: In-Reply-To: 481B2783.7080002@gmx.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5930380672659681799==" --===============5930380672659681799== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 2 May 2008, Sven Schreiber wrote: > quickly @b: I'm not sure right who may edit it. I have set some > permissions, where the six gretl developers I could identify in > the sourceforge list are made admins of that new tracker. I'm > not sure what that means for regular (logged-in) users, it would > be nice if someone who's not in the sourceforge gretl developers > list could test. I wonder if we might be better with a cvs-controlled log of incompatible changes, much like the current ChangeLog. I've done a mock-up of this; it's not linked to from the main page, but you can find it at: http://gretl.sourceforge.net/Backward.html Any thoughts on the relative merits of these approaches? Allin. --===============5930380672659681799==-- From svetosch@gmx.net Tue May 6 12:48:58 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] new tracker for incompatible changes Date: Tue, 06 May 2008 18:50:05 +0200 Message-ID: <48208C3D.2050800@gmx.net> In-Reply-To: alpine.LRH.1.10.0805061209230.18484@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2360413906034140860==" --===============2360413906034140860== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Allin Cottrell schrieb: > On Fri, 2 May 2008, Sven Schreiber wrote: > >> quickly @b: I'm not sure right who may edit it. I have set some >> permissions, where the six gretl developers I could identify in >> the sourceforge list are made admins of that new tracker. I'm >> not sure what that means for regular (logged-in) users, it would >> be nice if someone who's not in the sourceforge gretl developers >> list could test. > > I wonder if we might be better with a cvs-controlled log of > incompatible changes, much like the current ChangeLog. > > I've done a mock-up of this; it's not linked to from the main > page, but you can find it at: > > http://gretl.sourceforge.net/Backward.html > > Any thoughts on the relative merits of these approaches? your page looks good to me. I have no particular vested interested in the tracker solution, I just want a transparent documentation. cheers, sven --===============2360413906034140860==-- From r.lucchetti@univpm.it Tue May 6 12:52:41 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] new tracker for incompatible changes Date: Tue, 06 May 2008 18:52:37 +0200 Message-ID: In-Reply-To: alpine.LRH.1.10.0805061209230.18484@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7563538674890185062==" --===============7563538674890185062== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Tue, 6 May 2008, Allin Cottrell wrote: > On Fri, 2 May 2008, Sven Schreiber wrote: > >> quickly @b: I'm not sure right who may edit it. I have set some >> permissions, where the six gretl developers I could identify in >> the sourceforge list are made admins of that new tracker. I'm >> not sure what that means for regular (logged-in) users, it would >> be nice if someone who's not in the sourceforge gretl developers >> list could test. > > I wonder if we might be better with a cvs-controlled log of > incompatible changes, much like the current ChangeLog. > > I've done a mock-up of this; it's not linked to from the main > page, but you can find it at: > > http://gretl.sourceforge.net/Backward.html > > Any thoughts on the relative merits of these approaches? I like the Changelog-style better. Pros: a) no spam involved b) it's rather easy to look for stuff: you open the web page, and everything is there. If in the future the list greows, all you have to do is press Ctrl-F and you're pretty much done. c) requires very little maintenance, but more or less the same holds for the SF tracker d) optionally, it can be turned into an Emacs-style "forward-incompatible unfeatures" (if you have no idea of what I'm talking about, never mind, it's an in-joke) Cons: none I can see right now. While we're at it: the Changelog is nice, but not exactly newbie-friendly. For the next release, it'd be nice if someone volunteered to write a "Release Notes" page, more or less in the style of Abiword's (http://www.abiword.org/release-notes/2.6.0.phtml) or Gnumeric's (http://www.gnome.org/projects/gnumeric/announcements/1.8/gnumeric-1.8.shtml). There are several people on the devel list that I think would do an excellent job (Sven, Andreas, Talha, to name but a few). Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti --===============7563538674890185062==-- From andreas.rosenblad@ltv.se Wed May 7 05:11:27 2008 From: andreas.rosenblad@ltv.se To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] kalman filter status? Date: Wed, 07 May 2008 11:11:22 +0200 Message-ID: In-Reply-To: OFF582DD1D.F1829D45-ONC1257439.003BC4BF@LocalDomain MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8531800082263469920==" --===============8531800082263469920== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit svetosch(a)gmx.net @ INTERNET skrev 2008-04-28 12:52:49 : > Hi, > > I think I've asked about it before, but the "big" feature I'm > missing in gretl is the Kalman filter for state-space models. The "big" feature I am missing in gretl is quantile regression. Andreas --===============8531800082263469920==-- From r.lucchetti@univpm.it Wed May 7 05:39:15 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] kalman filter status? Date: Wed, 07 May 2008 11:39:10 +0200 Message-ID: In-Reply-To: OF030925FD.CDABE285-ONC1257442.00325D63-C1257442.00327B26@ltv.se MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0560889647314510063==" --===============0560889647314510063== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Wed, 7 May 2008, andreas.rosenblad(a)ltv.se wrote: > > svetosch(a)gmx.net @ INTERNET skrev 2008-04-28 12:52:49 : > >> Hi, >> >> I think I've asked about it before, but the "big" feature I'm >> missing in gretl is the Kalman filter for state-space models. > > The "big" feature I am missing in gretl is quantile regression. Both features are, at the moment, in the planning stage. My guess is that we'll release 1.7.5 quite soon to incorporate in the official version the bug fixes we've accumulated so far, plus a few extra features. If you look at the Changelog at http://gretl.sourceforge.net/ChangeLog.html, you'll see there's a hefty amount of stuff already. What I'd like to have in before releasing 1.7.5 are 1) we're working on an "ODBC connector", which enables gretl to fetch data from DBMSes like Oracle, MySQL, Postgres etcetera. The basic infrastructure is already in CVS: the missing bits are (a) documentation (b) thorough testing (c) a reasonable GUI interface. IMO, chances are this can be done within the end of May and the ODBC facility (marked as "experimental") can be included in 1.7.5; 2) I haven't had time to look at geno's anova patch (sorry, geno!), but it seems likely that it shouldn't take long to incorporate it into CVS. IMO, once this is done we may release 1.7.5 and concentrate on kalman + quantile regression (and more). Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti --===============0560889647314510063==-- From cottrell@wfu.edu Wed May 7 07:58:39 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] kalman filter status? Date: Wed, 07 May 2008 07:58:32 -0400 Message-ID: In-Reply-To: OF030925FD.CDABE285-ONC1257442.00325D63-C1257442.00327B26@ltv.se MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1163940697328421687==" --===============1163940697328421687== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 7 May 2008, andreas.rosenblad(a)ltv.se wrote: > The "big" feature I am missing in gretl is quantile regression. I'm actually working on that at present, and may have something to report before too long. Allin. --===============1163940697328421687==-- From svetosch@gmx.net Thu May 8 05:31:42 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] new tracker for incompatible changes Date: Thu, 08 May 2008 11:32:53 +0200 Message-ID: <4822C8C5.8040309@gmx.net> In-Reply-To: alpine.DEB.1.10.0805061832210.16965@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8973951766223541974==" --===============8973951766223541974== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Riccardo (Jack) Lucchetti schrieb: > > While we're at it: the Changelog is nice, but not exactly > newbie-friendly. For the next release, it'd be nice if someone > volunteered to write a "Release Notes" page, more or less in the style > of Abiword's (http://www.abiword.org/release-notes/2.6.0.phtml) or > Gnumeric's > (http://www.gnome.org/projects/gnumeric/announcements/1.8/gnumeric-1.8.shtml). > > > There are several people on the devel list that I think would do an > excellent job (Sven, Andreas, Talha, to name but a few). > If writing the release notes is not strictly tied to the release date (but for example could happen a week after release), then I guess I would be willing to do that. OTOH, I seem to remember that Allin said it would be easier if he or you do it. Just let me know. -sven --===============8973951766223541974==-- From svetosch@gmx.net Thu May 8 05:34:25 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] kalman filter status? Date: Thu, 08 May 2008 11:35:37 +0200 Message-ID: <4822C969.1010605@gmx.net> In-Reply-To: alpine.DEB.1.10.0805071114480.24982@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1419377711270454020==" --===============1419377711270454020== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Riccardo (Jack) Lucchetti schrieb: > > 1) we're working on an "ODBC connector", which enables gretl to fetch > data from DBMSes like Oracle, MySQL, Postgres etcetera. The basic > infrastructure is already in CVS: the missing bits are (a) documentation > (b) thorough testing (c) a reasonable GUI interface. IMO, chances are > this can be done within the end of May and the ODBC facility (marked as > "experimental") can be included in 1.7.5; in principle this sounds cool, but what actually is the pressing need for it? Or to put it differently: should 1.7.5 really be delayed for that reason? > > IMO, once this is done we may release 1.7.5 and concentrate on kalman + > quantile regression (and more). > let me repeat my other question: do you want/need suggestions for the Kalman "API"/syntax/interface? thanks, sven --===============1419377711270454020==-- From ignacio.diaz-emparanza@ehu.es Thu May 8 05:42:14 2008 From: Ignacio Diaz-Emparanza To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] ARMAX and diffs Date: Thu, 08 May 2008 11:42:10 +0200 Message-ID: <200805081142.10971.ignacio.diaz-emparanza@ehu.es> In-Reply-To: alpine.DEB.1.10.0805061443180.14342@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5555462491031084314==" --===============5555462491031084314== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable El Tuesday 06 May 2008 15:24:16 Riccardo (Jack) Lucchetti escribi=C3=B3: > > Ignacio, > > after some pondering, I believe you're right. What I would consider a > proper fix for this issue, however, takes us right in the middle of the > parallel discussion about backward-incompatible changes. Let me explain. > > To recap briefly what's in the manual already, what we currently have > under the "arima" heading is in fact a pair of quite different things. On > one hand, we have that ML estimation (carried out via the Kalman filter) > estimates a model like > > (1) A(L) (y_t - x_t'\beta) =3D C(L) e_t > > If we believe that the differencing operator is part and parcel of the > A(L) polynomial, we ought to difference x_t as well, not just y_t > (contrary to what we do now). This would be, in itself, a > backward-incompatible change already. I think by default we should not do any "backward incomptible" changes unless 1) We are correcting an error, or 2) We are making a great improvement of some command or feature With respect to the gretl native command "arima" I think we are not in any of= =20 these cases, so I propose we should re-think how to solve this in another=20 way. > > Now consider the class of models that we handle via conditional ML: here > we have > > (2) A(L) y_t =3D x_t'\beta + C(L) e_t. > > As the manual says, whenever x_t includes anything more than the constant, > (1) and (2) are fundamentally different models, since the term x_t'\beta > can be considered as the conditional mean of y_t with respect to two > different information set. In the context of (2), the A(L) polynomial does > _not_ apply to x_t, so there's no reason to difference x_t too. The question here is the interpretation about where the unit root is. It can = go as a multiplicative factor in A(L), as it seems yo are thinking,=20 A(L)=3DA(L)'*(1-L) having A(L)' the roots outside the unit circle, or it can = go=20 as a denominator of C(L)=3DC'(L)/(1-L) havin C'(L) its roots outside the unit= =20 circle. In equation (1) being (1-L) in A(L) or in C(L) has the same effect, but not i= n=20 equation (2). In the context of transfer function models is very common to write the=20 equation as (3) y_t =3D v(L)*x_t + Nt where the noise Nt is in general Nt=3DC(L)/A(L)*(1-L)^d. I am working with th= is=20 type of models so I thought was natural that the xt variable I was puting in = the equation was no differenced. > > The important thing here is that (1) is the formulation generally adopted > in the time-series literature, while (2) resembles more the models > econometricians use, (ARDL models, GARCH models, and so on). If we > implement the change proposed by Ignacio (which, I repeat, makes perfect > sense for (1)), the two models would diverge in their behaviour=20 No, please. > and=20 > interpretation even more, to the point that I wouldn't find it > inconceivable to have two separate commands and two different GUI menu > entries for (1) and (2) (although, it must be said, it'd be relatively > easy to estimate (1) via conditional ML if we wanted to). I think we shoud leave the things as simple as possible. Your interpretation = about the model is reasonable, so we only need that the user can know this=20 interpretation. If the gretl native command is left how it is now, we only=20 need that the user know what gretl is doing with the xt variable. So the=20 problem is solved if we only add a paragraph in the manual explaining how the= =20 differences are applied to the model when there are independent variables. But when you use the option --x12-arima the model that gretl estimates is=20 different that the one being estimated without this option. And I think this = is an inconsistency that should be corrected, in spite of it implies=20 a "backward incompatible" change. --=20 Ignacio Diaz-Emparanza =20 DEPARTAMENTO DE ECONOM=C3=8DA APLICADA III (ECONOMETR=C3=8DA Y ESTAD=C3=8DSTI= CA) =20 UPV/EHU Avda. Lehendakari Aguirre, 83 | 48015 BILBAO T.: +34 946013732 | F.: +34 946013754 www.et.bs.ehu.es=20 --===============5555462491031084314==-- From svetosch@gmx.net Fri May 9 17:41:34 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] new tracker for incompatible changes Date: Fri, 09 May 2008 23:41:26 +0200 Message-ID: <4824C506.9000109@gmx.net> In-Reply-To: alpine.LRH.1.10.0805061209230.18484@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2606571556605802594==" --===============2606571556605802594== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Am 06.05.2008 18:14, Allin Cottrell schrieb: > On Fri, 2 May 2008, Sven Schreiber wrote: > >> quickly @b: I'm not sure right who may edit it. I have set some >> permissions, where the six gretl developers I could identify in >> the sourceforge list are made admins of that new tracker. I'm >> not sure what that means for regular (logged-in) users, it would >> be nice if someone who's not in the sourceforge gretl developers >> list could test. > > I wonder if we might be better with a cvs-controlled log of > incompatible changes, much like the current ChangeLog. > > I've done a mock-up of this; it's not linked to from the main > page, but you can find it at: > > http://gretl.sourceforge.net/Backward.html > It seems everybody agrees to have that cvs-based thing on the webpage. So I guess it should be linked to from the main page. And the new tracker must be removed, but it looks as if only Allin has the permissions to do it, I just tried but couldn't find any relevant button. -sven --===============2606571556605802594==-- From cottrell@wfu.edu Fri May 9 23:28:00 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] kalman filter status? Date: Fri, 09 May 2008 23:27:40 -0400 Message-ID: In-Reply-To: 4822C969.1010605@gmx.net Content-Type: multipart/mixed; boundary="===============3274299171833104426==" --===============3274299171833104426== Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Kalman.tex" MIME-Version: 1.0 XGRvY3VtZW50Y2xhc3NbYTRwYXBlciwxMXB0XXthcnRpY2xlfQ0KDQpcdXNlcGFja2FnZXtibX0N Clx1c2VwYWNrYWdle3ZlcmJhdGltfQ0KDQpcbmV3Y29tbWFuZHtcb2JzdmVjfXtcZW5zdXJlbWF0 aFxtYXRoYmZ7eX19DQpcbmV3Y29tbWFuZHtcb2JzbWF0fXtcZW5zdXJlbWF0aFxtYXRoYmZ7SH19 DQpcbmV3Y29tbWFuZHtcb2JzZGlzdH17XGVuc3VyZW1hdGhcbWF0aGJme3d9fQ0KXG5ld2NvbW1h bmR7XG9ic3Zhcn17XGVuc3VyZW1hdGhcbWF0aGJme1J9fQ0KDQpcbmV3Y29tbWFuZHtcc3RhdGV2 ZWN9e1xlbnN1cmVtYXRoe1xibVx4aX19DQpcbmV3Y29tbWFuZHtcc3RybWF0fXtcZW5zdXJlbWF0 aFxtYXRoYmZ7Rn19DQpcbmV3Y29tbWFuZHtcc3RyZGlzdH17XGVuc3VyZW1hdGhcbWF0aGJme3Z9 fQ0KXG5ld2NvbW1hbmR7XHN0cnZhcn17XGVuc3VyZW1hdGhcbWF0aGJme1F9fQ0KXG5ld2NvbW1h bmR7XGhhdHN0YXRldmFyfXtcZW5zdXJlbWF0aFxtYXRoYmZ7UH19DQoNClxuZXdjb21tYW5ke1xw cmVkZXJyfXtcZW5zdXJlbWF0aFxtYXRoYmZ7ZX19DQpcbmV3Y29tbWFuZHtccHJlZHZhcn17XGVu c3VyZW1hdGh7XGJtXFNpZ21hfX0NCg0KXG5ld2NvbW1hbmR7XGV4b2d9e1xlbnN1cmVtYXRoe1xt YXRoYmZ7en19fQ0KXG5ld2NvbW1hbmR7XHBhcmFtfXtcZW5zdXJlbWF0aHtcYm1cdGhldGF9fQ0K DQpcdGl0bGV7UkZDOiBJbXBsZW1lbnRhdGlvbiBpbiBcdGV4dHR0e2dyZXRsfSBvZiB0aGUgS2Fs bWFuIGZpbHRlcg0KICBhdCB0aGUgdXNlciBsZXZlbH0NClxhdXRob3J7SmFja30NCg0KXGJlZ2lu e2RvY3VtZW50fQ0KDQpcbWFrZXRpdGxlDQoNClRoZSBLYWxtYW4gZmlsdGVyIGlzIG9uZSBvZiB0 aG9zZSBmdW5jdGlvbmFsaXRpZXMgdGhhdCBtYXkgY29tZSBpbg0KaGFuZHkgaW4gYSBudW1iZXIg b2YgY2FzZXM6IG9mIGNvdXJzZSB3ZSBhbHJlYWR5IHVzZSBpbnRlcm5hbGx5IGl0IGZvcg0KQVJN QSBlc3RpbWF0aW9uLCBidXQgZm9yIGV4YW1wbGUsIGl0J2QgYmUgbmljZSB0byBoYXZlIGEgdG9v bCBsaWtlDQp0aGF0IGZvciBwZW9wbGUgd2hvIGRvIERTR0UgbW9kZWxzIG9yIG1heWJlIGZvciBw ZW9wbGUgd2hvIHdvdWxkIGxpa2UNCnRvIGltcGxlbWVudCBBUk1BIGVzdGltYXRpb24gd2l0aCBz ZXJpZXMgd2l0aCBtaXNzaW5nIHZhbHVlcyBhbmQgc28NCm9uLg0KDQpcc2VjdGlvbip7Tm90YXRp b259DQoNCk5vdGF0aW9uIFxlbXBoe2lzfSBhIHByb2JsZW0uIEl0IHNlZW1zIHRoYXQgaW4gZWNv bm9tZXRyaWNzIGV2ZXJ5b25lDQppcyBoYXBweSB3aXRoICR5ID0gWCBcYmV0YSArIHUkLCBidXQg d2UgY2FuJ3QsIGFzIGEgY29tbXVuaXR5LCBtYWtlIHVwDQpvdXIgbWluZHMgb24gYSBzdGFuZGFy ZCBmb3Igc3RhdGUtc3BhY2UgbW9kZWxzLiBIYXJ2ZXkgKDE5OTEpLA0KSGFtaWx0b24gKDE5OTQp LCBIYXJ2ZXkgXCYgUHJvaWV0dGkgKDIwMDUpIGFuZCBQb2xsb2NrICgxOTk5KSBhbGwgdXNlDQpk aWZmZXJlbnQgY29udmVudGlvbnMuIFRoZSBub3RhdGlvbiBoZXJlIHdpbGwgYmUgYmFzZWQgb24g SGFtaWx0b24ncywNCndpdGggc2xpZ2h0IHZhcmlhdGlvbnMuDQoNCkEgc3RhdGUtc3BhY2UgbW9k ZWwgY2FuIGJlIHdyaXR0ZW4gZG93biBhcw0KXGJlZ2lue2VxbmFycmF5fQ0KICBcbGFiZWx7ZXE6 b2JzZXF9DQogIFxvYnN2ZWNfdCAmID0gJiBcb2JzbWF0X3QgXHN0YXRldmVjX3QgKyBcbWF0aGJm e2R9X3QgKyBcb2JzZGlzdF90IFxcDQogIFxsYWJlbHtlcTpzdHJhbmVxfQ0KICBcc3RhdGV2ZWNf e3R9ICYgPSAmIFxzdHJtYXRfe3R9IFxzdGF0ZXZlY197dC0xfSArIFxtYXRoYmZ7Y31fdCArIFxz dHJkaXN0X3QNClxlbmR7ZXFuYXJyYXl9DQpUaGUgc3ltYm9sICRUJCAobm90IGluIGJvbGQpIGlu ZGljYXRlcyB0aGUgc2FtcGxlIHNpemUuIFRoZQ0Kb2JzZXJ2YWJsZXMgJFxvYnN2ZWNfdCQgYXJl IGFuICRuJC12ZWN0b3IgKGluIG1hbnkgY2FzZXMsICRuPTEkLA0KYnV0IG5vdCBuZWNlc3Nhcmls eSksIHdoaWxlIHRoZSB1bm9ic2VydmFibGUgdmVjdG9yIG9mIHN0YXRlcw0KJFxzdGF0ZXZlY190 JCBoYXMgJG0kIGVsZW1lbnRzLiU7IHVzdWFsbHksIGlmIG5vdCBhbHdheXMsICRuIDwgbSQuDQpU aGUgY292YXJpYW5jZSBtYXRyaWNlcyBmb3IgJFxvYnNkaXN0X3QkIGFuZCAkXHN0cmRpc3RfdCQg YXJlICRcb2JzdmFyX3QkIGFuZA0KJFxzdHJ2YXJfdCQsIHJlc3BlY3RpdmVseS4NCg0KSW4gdGhl IHNwZWNpYWwgY2FzZSB3aGVuICRcc3RybWF0X3QgPSBcc3RybWF0JCwgJFxvYnNtYXRfdCA9DQpc b2JzbWF0JCBhbmQgc28gb24sIHRoZSBtb2RlbCB3aWxsIGJlIGNhbGxlZCBcZW1waHt0aW1lLWlu dmFyaWFudH0uDQoNCldlIGhhdmUgdHdvIG9wdGlvbnM6IHdlIG1heSBnbyBmb3J3YXJkIGluIHRp bWUgYW5kIGRvIHRoZQ0KXGVtcGh7ZmlsdGVyaW5nfSBwcm9wZXIsIG9yIGFmdGVyIHRoYXQgd2Ug Z28gYmFjayBhbmQgZG8gdGhlDQpcZW1waHtzbW9vdGhpbmd9LiANCg0KVG8gcXVvdGUgZnJvbSBQ b2xsb2NrICgxOTk5KSwgcC4gMjQxICh3aXRoIGRpZmZlcmVudCBub3RhdGlvbiksIA0KXGJlZ2lu e3F1b3RlfQ0KW1xsZG90c10gaXQgaXMgYXNzdW1lZCB0aGF0IHByaW9yIGluZm9ybWF0aW9uIG9u IHRoZSBwcmV2aW91cyBzdGF0ZSB2ZWN0b3INCiRcc3RhdGV2ZWNfMCQgaXMgYXZhaWxhYmxlIGlu IHRoZSBmb3JtIG9mIGFuIHVuYmlhc2VkIGVzdGltYXRlICRcaGF0e1xzdGF0ZXZlY31fMCQgd2hp Y2ggaGFzIGJlZW4gZHJhd24gZnJvbQ0KYSBkaXN0cmlidXRpb24gd2l0aCBhIG1lYW4gb2YgJFxz dGF0ZXZlY18wJCBhbmQgYSBkaXNwZXJzaW9uIG1hdHJpeCBvZiAkXGhhdHN0YXRldmFyXzAkLg0K XGVuZHtxdW90ZX0NCg0KSXQgbWF5IGhhcHBlbiB0aGF0ICRcaGF0c3RhdGV2YXJfezB9IFx0byBc aW5mdHkkIGZvciBkaWZmdXNlIHByaW9ycy4gSW4NCnRoaXMgY2FzZSwgd2UgbmVlZCB0byBjaGVj ayBLb29wbWFuICgxOTk3KTsgaW4gdGhlIHN0YW5kYXJkIGNhc2UsDQpob3dldmVyLCB0aGUgcHJl ZGljdGlvbiBlcXVhdGlvbnMgYXJlOg0KXGJlZ2lue2VxbmFycmF5fQ0KICBcbGFiZWx7ZXE6Zmls dHN0YXRlc30NCiAgRV97dC0xfShcc3RhdGV2ZWNfdCkgPSBcaGF0e1xzdGF0ZXZlY31fe3R8dC0x fSAmID0gJiANCiAgXHN0cm1hdF90IFxoYXR7XHN0YXRldmVjfV97dC0xfSArIFxtYXRoYmZ7Y31f dCAgXGxhYmVse2VxOnN0YXRlcHJlZH1cXA0KICBWX3t0LTF9KFxzdGF0ZXZlY190KSA9IFxoYXRz dGF0ZXZhcl97dHx0LTF9ICYgPSAmDQogIFxzdHJtYXRfdCBcaGF0c3RhdGV2YXJfe3QtMX0gXHN0 cm1hdCdfdCArIFxzdHJ2YXJfdCBcbGFiZWx7ZXE6UHByZWR9XFwNCiAgRV97dC0xfShcb2JzdmVj X3QpID0gXGhhdHtcb2JzdmVjfV97dHx0LTF9ICYgPSAmIFxvYnNtYXRfdCBcaGF0e1xzdGF0ZXZl Y31fe3R8dC0xfSArIFxtYXRoYmZ7ZH1fdCAgXFwNCiAgXHByZWRlcnJfdCAmID0gJiBcb2JzdmVj X3QgLSBcaGF0e1xvYnN2ZWN9X3t0fHQtMX0gXFwNCiAgVl97dC0xfShccHJlZGVycl90KSA9IFxw cmVkdmFyX3QgJiA9ICYgXG9ic21hdF90IFxoYXRzdGF0ZXZhcl97dHx0LTF9IFxvYnNtYXRfdCcg KyBcb2JzdmFyX3QNCiBcZW5ke2VxbmFycmF5fQ0Kc28gdGhlIHVwZGF0aW5nIGVxdWF0aW9ucyBh cmU6DQpcYmVnaW57ZXFuYXJyYXl9DQogIFxoYXR7XHN0YXRldmVjfV90ICYgPSAmIA0KICBcaGF0 e1xzdGF0ZXZlY31fe3R8dC0xfSArIA0KICBcbWF0aGJme0t9X3t0fSBccHJlZGVycl90IFxsYWJl bHtlcTpzdGF0ZXVwZH1cXA0KICBcaGF0c3RhdGV2YXJfe3R9ICYgID0gJiANCiAgXGhhdHN0YXRl dmFyX3t0fHQtMX0gLSANCiAgXGhhdHN0YXRldmFyX3t0fHQtMX0gXG9ic21hdF90JyBcbWF0aGJm e0Z9XnstMX1fdCBcb2JzbWF0X3QgXGhhdHN0YXRldmFyX3t0fHQtMX0gXGxhYmVse2VxOlB1cGR9 DQpcZW5ke2VxbmFycmF5fQ0Kd2hlcmUgJFxtYXRoYmZ7S31fe3R9ID0gXGhhdHN0YXRldmFyX3t0 fHQtMX0gXG9ic21hdF90Jw0KXG9ic3Zhcl90XnstMX0kIGlzIHRoZSBLYWxtYW4gZ2Fpbi4gIEVx dWF0aW9ucw0KKFxyZWZ7ZXE6c3RhdGVwcmVkfSktLShccmVme2VxOnN0YXRldXBkfSkgYW5kDQoo XHJlZntlcTpQcHJlZH0pLS0oXHJlZntlcTpQdXBkfSkgY2FuIGJlIHdyaXR0ZW4gYXMgYSBzaW5n bGUgc2V0IG9mDQpyZWN1cnNpb25zIGdvaW5nIGRpcmVjdGx5IGZyb20gJFxoYXR7XHN0YXRldmVj fV97dC0xfSQgdG8gJFxoYXR7XHN0YXRldmVjfV90JA0KYW5kIGZyb20gJFxoYXRzdGF0ZXZhcl97 dC0xfSQgdG8gJFxoYXRzdGF0ZXZhcl97dH0kLg0KDQpOb3RlIHRoYXQgaW4gcHJhY3RpY2Ugd2Ug bWF5DQp3YW50IHRvIGltcGxlbWVudCBzb21ldGhpbmcgY29tcHV0YXRpb25hbGx5IHNtYXJ0ZXIs IGxpa2UgdGhlDQppbmZvcm1hdGlvbiBmaWx0ZXIgKHNvbWUgYmlibGlvZ3JhcGhpYyBzZWFyY2gg aXMgbmVlZGVkIGhlcmUsIEkgY2FuJ3QNCnJlbWVtYmVyIGV4YWN0bHkgd2hhdCBpdCBsb29rcyBs aWtlKS4NCg0KSSBjYW4ndCBiZSBib3RoZXJlZCByaWdodCBub3cgdG8gd3JpdGUgdGhlIHNtb290 aGluZyByZWN1cnNpb25zLCBidXQNCml0J3Mgbm90IHRlcnJpYmx5IGltcG9ydGFudC4NCg0KXHNl Y3Rpb24qe1VzZXIgc3ludGF4fQ0KDQpUaGUgaWRlYSBpcyB0byBkZWZpbmUgYSBjb21tYW5kIGJs b2NrIGxpa2Ugd2UgZG8gd2l0aCBcdGV4dHR0e21sZX0gb3INClx0ZXh0dHR7Z21tfToNClxiZWdp bnt2ZXJiYXRpbX0NCmxpc3QgeSA9IHgxIHgyDQojIG9yIHBvc3NpYmx5DQptYXRyaXggWSA9IHsg eDEgeDIgfQ0KDQprYWxtYW4gWyAtLXNtb290aCBdDQogIG9ic3kgeQ0KICBvYnNtYXQgSA0KICBv YnNleCBkDQogIG9ic3ZhciBPbWVnYQ0KICBzdHJtYXQgUGhpDQogIHN0cmV4IGMNCiAgc3RydmFy IFBzaQ0KICBpbmlzdGF0ZSB4MA0KICBpbmlwcmVjIFAwDQplbmQga2FsbWFuDQpcZW5ke3ZlcmJh dGltfQ0Kd2hlcmUgXHRleHR0dHtvYnN5fSBzdGFuZHMgZm9yIGBgb2JzZXJ2YWJsZSAkXG9ic3Zl YyQnJywNClx0ZXh0dHR7b2JzbWF0fSBzdGFuZHMgZm9yIGBgbWF0cml4IGluIHRoZSBvYnNlcnZh dGlvbiBlcXVhdGlvbicnDQooXHJlZntlcTpvYnNlcX0pLCBcdGV4dHR0e29ic2V4fSBmb3IgYGBl eG9nZW5vdXMgdGVybSBpbiB0aGUNCm9ic2VydmF0aW9uIGVxdWF0aW9uJycgYW5kIFx0ZXh0dHR7 b2JzdmFyfSBmb3IgYGB2YXJpYW5jZSBvZiB0aGUNCm9ic2VydmF0aW9uIGVxdWF0aW9uJycuIEEg c2ltaWxhciBjb252ZW50aW9ucyB3b3VsZCBob2xkIGZvciB0aGUgc3RhdGUNCnRyYW5zaXRpb24g ZXF1YXRpb24gKFxyZWZ7ZXE6c3RyYW5lcX0pLCB3aXRoIFx0ZXh0dHR7c3RyfSByZXBsYWNpbmcN Clx0ZXh0dHR7b2JzfS4gVGhlIHN0cmluZ3MgXHRleHR0dHtpbmlzdGF0ZX0gYW5kIFx0ZXh0dHR7 aW5pcHJlY30NCnNob3VsZCBiZSBzZWxmLWV4cGxhbmF0b3J5Lg0KDQpUaGUgZWxlbWVudHMgXHRl eHR0dHtvYnNleH0sIFx0ZXh0dHR7c3RyZXh9IGFuZCBcdGV4dHR0e2luaXN0YXRlfSBuZWVkDQpu b3QgYmUgY29tcHVsc29yeS4gSWYgYWJzZW50LCB0aGV5IGFyZSB1bmRlcnN0b29kIHRvIGJlIDAu IE1vcmUgb3INCmxlc3MgdGhlIHNhbWUgbWF5IGdvIGZvciBcdGV4dHR0e2luaXByZWN9LCBpZiB0 aGUgaW5pdGlhbGlzYXRpb24gaXMNCmRvbmUgdmlhIGEgZGlmZnVzZSBwcmlvciAodGhlIHNpbXBs ZXN0IHRoaW5nIHdvdWxkIGJlIHRvIHVzZSBzb21laGluZw0KbGlrZSAkUF8wID0gMTBeezMwfVxj ZG90IEkkLCBidXQgc21hcnRlciBtZXRob2RzIGFyZSBhdmFpbGFibGUgLS0NCmFnYWluLCBLb29w bWFuICgxOTk3KSBzaG91bGQgY29tZSB0byB0aGUgcmVzY3VlKS4NCg0KRm9yIHRpbWUtaW52YXJp YW50IG1vZGVscywgdGhlIGFyZ3VtZW50cyB0byBcdGV4dHR0e29ic21hdCwgc3RybWF0fQ0KZXRj ZXRlcmEgbXVzdCBiZSBtYXRyaWNlcyBvZiB0aGUgYXBwcm9wcmlhdGUgc2l6ZS4gSW4gdGhlIGNh c2Ugb2YNCnRpbWUtdmFyeWluZyBtb2RlbHMsIHRoZSBiZXN0IGlkZWEgSSd2ZSBiZWVuIGFibGUg dG8gY29tZSB1cCB3aXRoIHNvDQpmYXJcZm9vdG5vdGV7QW5vdGhlciBzb2x1dGlvbiBpcyB0byBw YXNzIG1hdHJpY2VzIHdpdGggJFQkIHJvd3MgYW5kIGFuDQogIGFwcHJvcHJpYXRlIG51bWJlciBv ZiBjb2x1bW5zLCB3aGVyZSBlYWNoIHJvdyBpcyB0aGUgdmVjdG9yaXphdGlvbg0KICBvZiB0aGUg Y29ycmVzcG9uZGluZyBtYXRyaXggYXQgdGltZSAkdCQ7IGZvciBleGFtcGxlLCBpZiAkXHN0cm1h dF90JA0KICBpcyB0aW1lLXZhcnlpbmcsIHRoZW4gdGhlIGFyZ3VtZW50IHRvIFx0ZXh0dHR7c3Ry bWF0fSB3aWxsIGhhdmUgdG8NCiAgYmUgYSAkVCBcdGltZXMgbV4yJCBtYXRyaXguIEl0J2xsIGJl IGdyZXRsJ3Mgam9iIHRvIHJlc2hhcGUgdGhlDQogIHBlcnRpbmVudCByb3cgb2Ygc3VjaCBhIG1h dHJpeCwgYnV0IHRoZSBtb3JlIEkgdGhpbmsgdGhlIG1vcmUgSSBmaW5kDQogIGl0IHVnbHkufSBp cyB0byBwYXNzIG1hdHJpY2VzIHdoaWNoIHJlc3VsdCBmcm9tIHVzZXItZGVmaW5lZA0KZnVuY3Rp b25zLiBUaGlzIGlzIHZlcnkgZ2VuZXJhbCBhbmQgZWxlZ2FudDsgc2V2ZXJhbCBpbnRlcmVzdGlu Zw0KcG9zc2liaWxpdGllcyBhcmUgb3BlbmVkIGhlcmUsIHN1Y2ggYXMgYWxsb3dpbmcsIHNheSwg dGhlIGVsZW1lbnRzIG9mDQokXG9ic21hdF90JCB0byBkZXBlbmQgb24gJFxwcmVkZXJyX3t0LTF9 LCBcb2JzdmVjX3t0LTF9JCwgc3RydWN0dXJhbA0KcGFyYW1ldGVycyAoYXMgY2FuIGJlIHRoZSBj YXNlIHdpdGggRFNHRSBtb2RlbHMpIGFuZCBzbyBvbi4gDQoNCkhlbmNlLCB5b3Ugd291bGQgaGF2 ZSBzb21ldGhpbmcgbGlrZQ0KXFsNCiAgXG9ic21hdF90ID0gXG9ic21hdChcZXhvZ190LCBccGFy YW0pLA0KXF0NCndoZXJlICRcb2JzbWF0JCBjb3JyZXNwb25kcyB0byBhIHVzZXItd3JpdHRlbiBm dW5jdGlvbiBvZiB0aGUga2luZA0KXGJlZ2lue3ZlcmJhdGltfQ0KICAgIGZ1bmN0aW9uIE15T2Jz TWF0KGxpc3QgWCwgbWF0cml4IHRoZXRhKQ0KXGVuZHt2ZXJiYXRpbX0NCndob3NlIGNvbnRlbnQg ZGVwZW5kcyBvbiB0aGUgY29udGV4dCAocmVjdXJzaXZlIE9MUywgQVJNQXMsIHlvdSBuYW1lDQpp dCksIHRvIGJlIGNhbGxlZCBhcw0KXGJlZ2lue3ZlcmJhdGltfQ0KICAgIGxpc3QgWiA9IHgxIHgy IHgzDQogICAgbWF0cml4IHBhcm0gPSB7IDAuNSwgLTAuOCB9DQogICAga2FsbWFuDQogICAgICBv YnNtYXQgTXlPYnNNYXQoWiwgcGFybSkNCiAgICAgIC4uLg0KICAgIGVuZCBrYWxtYW4NClxlbmR7 dmVyYmF0aW19DQoNCk9mIGNvdXJzZSwgb25lIGFsc28gbmVlZHMgdG8gcmV0cmlldmUgdGhlIGlu dGVyZXN0aW5nIHF1YW50aXRpZXM6IHRoaXMNCmNvdWxkIGJlIGRvbmUgdmlhIHZpYSB0aGUgZXhp c3RpbmcgYWNjZXNzb3JzIFx0ZXh0dHR7XCR1aGF0fSBmb3INCiRccHJlZGVycl90JCBhbmQgXHRl eHR0dHtcJHNpZ21hfSAob3RoZXIgY2FuZGlkYXRlcyBtYXkgYmUNClx0ZXh0dHR7XCR2Y3Z9IGFu ZCBcdGV4dHR0e1wkaH0gLS0tIGJ1dCBJIHBlcnNvbmFsbHkgbGlrZQ0KXHRleHR0dHtcJHNpZ21h fSBiZXR0ZXIpIGZvciAkXHByZWR2YXJfdCQuIFdoZW4gJG4gPSAxJCwgdGhlc2Ugd291bGQgYmUN CnNlcmllczsgb3RoZXJ3aXNlIFx0ZXh0dHR7XCR1aGF0fSB3b3VsZCBiZSBhICRUIFx0aW1lcyBu JCBtYXRyaXggKGENCmJpdCBsaWtlIHdlIGRvIGZvciBzaW5nbGUgZXF1YXRpb24vbXVsdGlwbGUg ZXF1YXRpb25zIG1vZGVscyksIHdoaWxlDQpcdGV4dHR0e1wkc2lnbWF9IHNob3VsZCBiZSBhICRU IFx0aW1lcyBcZnJhY3tuIChuKzEpfXsyfSQgbWF0cml4LCB3aXRoDQp0aGUgJHQkLXRoIHJvdyBo b2xkaW5nICRcbWF0aHJte3ZlY2h9KFxwcmVkdmFyX3QpJyQuIE5ldyBhY2Nlc3NvcnMNCnNob3Vs ZCBiZSBkZXZvdGVkIHRvIHJldHVybmluZyB0aGUgc3RhdGVzIGFuZCB0aGVpciB2YXJpYW5jZXM6 DQpzdWl0YWJsZSBjYW5kaWRhdGVzIGNvdWxkIGJlIGFuZCBcdGV4dHR0e1wkc3RhdGVzfSBmb3Ig JFxzdGF0ZXZlY190JCBhbmQNClx0ZXh0dHR7XCRzdHZhcnN9IGZvciAkXG1hdGhybXt2ZWNofShc aGF0c3RhdGV2YXJfdCknJC4NCg0KTW9yZW92ZXIsIGl0IGlzIHByb2JhYmx5IHVzZWZ1bCB0byBh bHNvIHJldHVybiB0aGUgc2VyaWVzDQpcWw0KICBcZWxsX3QgPSAtMC41IFxsZWZ0WyANCiAgICBu IFxsbigyIFxwaSkgKyBcbGVmdHxccHJlZHZhcl90XHJpZ2h0fCArIA0KICAgIFxwcmVkZXJyX3Qn XHByZWR2YXJfdF57LTF9IFxwcmVkZXJyX3QNCiAgXHJpZ2h0XSAsDQpcXQ0KcG9zc2libHkgaW4g dGhlIGFjY2Vzc29yIFx0ZXh0dHR7XCRsbmx9LCB3aGljaCB3b3VsZCB5aWVsZCB0aGUNCmxpa2Vs aWhvb2QuIEl0IHRoZW4gYmVjb21lcyB0cml2aWFsIHRvIGluc2VydCB0aGUgd2hvbGUgdGhpbmcg aW4gYW4NClx0ZXh0dHR7bWxlfSBibG9jayB0byBlc3RpbWF0ZSBhbGwgc29ydHMgb2YgbW9kZWwu IE5vdGUsIGhvd2V2ZXIsIHRoYXQNCnRoZSBcdGV4dHR0e2thbG1hbn0gYmxvY2sgaXRzZWxmIHdv dWxkIHBlcmZvcm0gbm8gb3B0aW1pc2F0aW9uDQp3aGF0c29ldmVyOiBpdHMgam9iIHdvdWxkIG9u bHkgYmUgdGhlIGZpbHRlcmluZyAob3IgdGhlIHNtb290aGluZywNCndpdGggdGhlIFx2ZXJifC0t c21vb3RofCBvcHRpb24pLg0KDQpcc2VjdGlvbip7UmVmZXJlbmNlc30NCg0KSGFtaWx0b24sIEph bWVzIEQuICgxOTk0KSwgXGVtcGh7VGltZSBTZXJpZXMgQW5hbHlzaXN9LCBQcmluY2V0b24NClVu aXZlcnNpdHkgUHJlc3MuDQpcc21hbGxza2lwDQoNClxub2luZGVudA0KSGFydmV5LCBBLkMuICgx OTkxKSwgXGVtcGh7Rm9yZWNhc3RpbmcsIFN0cnVjdHVyYWwgVGltZSBTZXJpZXMgTW9kZWxzDQog IGFuZCB0aGUgS2FsbWFuIEZpbHRlcn0sIENhbWJyaWRnZSBVbml2ZXJzaXR5IFByZXNzLg0KXHNt YWxsc2tpcA0KDQpcbm9pbmRlbnQNCkhhcnZleSwgQS5DLiBhbmQgVC4gUHJvaWV0dGkgKDIwMDUp LCBcZW1waHtSZWFkaW5ncyBpbiBVbm9ic2VydmVkDQogIENvbXBvbmVudCBNb2RlbHN9LCBPeGZv cmQgVW5pdmVyc2l0eSBQcmVzcy4NClxzbWFsbHNraXANCg0KXG5vaW5kZW50DQpLb29wbWFuLCBT LiBKLiAoMTk5NyksIGBgRXhhY3QgSW5pdGlhbCBLYWxtYW4gRmlsdGVyaW5nIGFuZCBTbW9vdGhp bmcNCmZvciBOb25zdGF0aW9uYXJ5IFRpbWUgU2VyaWVzIE1vZGVscycnLCBKb3VybmFsIG9mIHRo ZSBBbWVyaWNhbg0KU3RhdGlzdGljYWwgQXNzb2NpYXRpb24sIFZvbC4gOTIsIE5vLiA0NDAsIHBw LiAxNjMwLS0xNjM4IFxzbWFsbHNraXANCg0KXG5vaW5kZW50DQpQb2xsb2NrLCBELlMuRy4gKDE5 OTkpLCBcZW1waHtBIEhhbmRib29rIG9mIFRpbWUtU2VyaWVzIEFuYWx5c2lzLA0KICBTaWduYWwg UHJvY2Vzc2luZyBhbmQgRHluYW1pY3N9LCBBY2FkZW1pYyBQcmVzcy4NCg0KDQpcZW5ke2RvY3Vt ZW50fQ0KDQolJSUgTG9jYWwgVmFyaWFibGVzOiANCiUlJSBtb2RlOiBsYXRleA0KJSUlIFRlWC1t YXN0ZXI6IHQNCiUlJSBFbmQ6IA0K --===============3274299171833104426==-- From r.lucchetti@univpm.it Sat May 10 05:26:00 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] kalman filter status? Date: Sat, 10 May 2008 11:25:55 +0200 Message-ID: In-Reply-To: alpine.LRH.1.10.0805092320271.30820@ricardo.ecn.wfu.edu Content-Type: multipart/mixed; boundary="===============5866647211392915187==" --===============5866647211392915187== Content-Type: text/x-tex Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Kalman.tex" MIME-Version: 1.0 XGRvY3VtZW50Y2xhc3NbYTRwYXBlciwxMXB0XXthcnRpY2xlfQ0KDQpcdXNlcGFja2FnZXtibX0N Clx1c2VwYWNrYWdle3ZlcmJhdGltfQ0KDQpcbmV3Y29tbWFuZHtcb2JzdmVjfXtcZW5zdXJlbWF0 aFxtYXRoYmZ7eX19DQpcbmV3Y29tbWFuZHtcb2JzbWF0fXtcZW5zdXJlbWF0aFxtYXRoYmZ7SH19 DQpcbmV3Y29tbWFuZHtcb2JzZGlzdH17XGVuc3VyZW1hdGhcbWF0aGJme3d9fQ0KXG5ld2NvbW1h bmR7XG9ic3Zhcn17XGVuc3VyZW1hdGhcbWF0aGJme1J9fQ0KDQpcbmV3Y29tbWFuZHtcc3RhdGV2 ZWN9e1xlbnN1cmVtYXRoe1xibVx4aX19DQpcbmV3Y29tbWFuZHtcc3RybWF0fXtcZW5zdXJlbWF0 aFxtYXRoYmZ7Rn19DQpcbmV3Y29tbWFuZHtcc3RyZGlzdH17XGVuc3VyZW1hdGhcbWF0aGJme3Z9 fQ0KXG5ld2NvbW1hbmR7XHN0cnZhcn17XGVuc3VyZW1hdGhcbWF0aGJme1F9fQ0KXG5ld2NvbW1h bmR7XGhhdHN0YXRldmFyfXtcZW5zdXJlbWF0aFxtYXRoYmZ7UH19DQoNClxuZXdjb21tYW5ke1xw cmVkZXJyfXtcZW5zdXJlbWF0aFxtYXRoYmZ7ZX19DQpcbmV3Y29tbWFuZHtccHJlZHZhcn17XGVu c3VyZW1hdGh7XGJtXFNpZ21hfX0NCg0KXG5ld2NvbW1hbmR7XGV4b2d9e1xlbnN1cmVtYXRoe1xt YXRoYmZ7en19fQ0KXG5ld2NvbW1hbmR7XHBhcmFtfXtcZW5zdXJlbWF0aHtcYm1cdGhldGF9fQ0K DQpcdGl0bGV7UkZDOiBJbXBsZW1lbnRhdGlvbiBpbiBcdGV4dHR0e2dyZXRsfSBvZiB0aGUgS2Fs bWFuIGZpbHRlcg0KICBhdCB0aGUgdXNlciBsZXZlbH0NClxhdXRob3J7SmFja30NCg0KXGJlZ2lu e2RvY3VtZW50fQ0KDQpcbWFrZXRpdGxlDQoNClRoZSBLYWxtYW4gZmlsdGVyIGlzIG9uZSBvZiB0 aG9zZSBmdW5jdGlvbmFsaXRpZXMgdGhhdCBtYXkgY29tZSBpbg0KaGFuZHkgaW4gYSBudW1iZXIg b2YgY2FzZXM6IG9mIGNvdXJzZSB3ZSBhbHJlYWR5IHVzZSBpbnRlcm5hbGx5IGl0IGZvcg0KQVJN QSBlc3RpbWF0aW9uLCBidXQgZm9yIGV4YW1wbGUsIGl0J2QgYmUgbmljZSB0byBoYXZlIGEgdG9v bCBsaWtlDQp0aGF0IGZvciBwZW9wbGUgd2hvIGRvIERTR0UgbW9kZWxzIG9yIG1heWJlIGZvciBw ZW9wbGUgd2hvIHdvdWxkIGxpa2UNCnRvIGltcGxlbWVudCBBUk1BIGVzdGltYXRpb24gd2l0aCBz ZXJpZXMgd2l0aCBtaXNzaW5nIHZhbHVlcyBhbmQgc28NCm9uLg0KDQpcc2VjdGlvbntOb3RhdGlv bn0NCg0KTm90YXRpb24gXGVtcGh7aXN9IGEgcHJvYmxlbS4gSXQgc2VlbXMgdGhhdCBpbiBlY29u b21ldHJpY3MgZXZlcnlvbmUNCmlzIGhhcHB5IHdpdGggJHkgPSBYIFxiZXRhICsgdSQsIGJ1dCB3 ZSBjYW4ndCwgYXMgYSBjb21tdW5pdHksIG1ha2UgdXANCm91ciBtaW5kcyBvbiBhIHN0YW5kYXJk IGZvciBzdGF0ZS1zcGFjZSBtb2RlbHMuIEhhcnZleSAoMTk5MSksDQpIYW1pbHRvbiAoMTk5NCks IEhhcnZleSBcJiBQcm9pZXR0aSAoMjAwNSkgYW5kIFBvbGxvY2sgKDE5OTkpIGFsbCB1c2UNCmRp ZmZlcmVudCBjb252ZW50aW9ucy4gVGhlIG5vdGF0aW9uIGhlcmUgd2lsbCBiZSBiYXNlZCBvbiBI YW1pbHRvbidzLA0Kd2l0aCBzbGlnaHQgdmFyaWF0aW9ucy4NCg0KQSBzdGF0ZS1zcGFjZSBtb2Rl bCBjYW4gYmUgd3JpdHRlbiBkb3duIGFzDQpcYmVnaW57ZXFuYXJyYXl9DQogIFxsYWJlbHtlcTpv YnNlcX0NCiAgXG9ic3ZlY190ICYgPSAmIFxvYnNtYXRfdCBcc3RhdGV2ZWNfdCArIFxtYXRoYmZ7 ZH1fdCArIFxvYnNkaXN0X3QgXFwNCiAgXGxhYmVse2VxOnN0cmFuZXF9DQogIFxzdGF0ZXZlY197 dH0gJiA9ICYgXHN0cm1hdF97dH0gXHN0YXRldmVjX3t0LTF9ICsgXG1hdGhiZntjfV90ICsgXHN0 cmRpc3RfdA0KXGVuZHtlcW5hcnJheX0NClRoZSBzeW1ib2wgJFQkIChub3QgaW4gYm9sZCkgaW5k aWNhdGVzIHRoZSBzYW1wbGUgc2l6ZS4gVGhlDQpvYnNlcnZhYmxlcyAkXG9ic3ZlY190JCBhcmUg YW4gJG4kLXZlY3RvciAoaW4gbWFueSBjYXNlcywgJG49MSQsDQpidXQgbm90IG5lY2Vzc2FyaWx5 KSwgd2hpbGUgdGhlIHVub2JzZXJ2YWJsZSB2ZWN0b3Igb2Ygc3RhdGVzDQokXHN0YXRldmVjX3Qk IGhhcyAkbSQgZWxlbWVudHMuJTsgdXN1YWxseSwgaWYgbm90IGFsd2F5cywgJG4gPCBtJC4NClRo ZSBjb3ZhcmlhbmNlIG1hdHJpY2VzIGZvciAkXG9ic2Rpc3RfdCQgYW5kICRcc3RyZGlzdF90JCBh cmUgJFxvYnN2YXJfdCQgYW5kDQokXHN0cnZhcl90JCwgcmVzcGVjdGl2ZWx5Lg0KDQpJbiB0aGUg c3BlY2lhbCBjYXNlIHdoZW4gJFxzdHJtYXRfdCA9IFxzdHJtYXQkLCAkXG9ic21hdF90ID0NClxv YnNtYXQkIGFuZCBzbyBvbiwgdGhlIG1vZGVsIHdpbGwgYmUgY2FsbGVkIFxlbXBoe3RpbWUtaW52 YXJpYW50fS4NCg0KV2UgaGF2ZSB0d28gb3B0aW9uczogd2UgbWF5IGdvIGZvcndhcmQgaW4gdGlt ZSBhbmQgZG8gdGhlDQpcZW1waHtmaWx0ZXJpbmd9IHByb3Blciwgb3IgYWZ0ZXIgdGhhdCB3ZSBn byBiYWNrIGFuZCBkbyB0aGUNClxlbXBoe3Ntb290aGluZ30uIA0KDQpUbyBxdW90ZSBmcm9tIFBv bGxvY2sgKDE5OTkpLCBwLiAyNDEgKHdpdGggZGlmZmVyZW50IG5vdGF0aW9uKSwgDQpcYmVnaW57 cXVvdGV9DQpbXGxkb3RzXSBpdCBpcyBhc3N1bWVkIHRoYXQgcHJpb3IgaW5mb3JtYXRpb24gb24g dGhlIHByZXZpb3VzIHN0YXRlIHZlY3Rvcg0KJFxzdGF0ZXZlY18wJCBpcyBhdmFpbGFibGUgaW4g dGhlIGZvcm0gb2YgYW4gdW5iaWFzZWQgZXN0aW1hdGUgJFxoYXR7XHN0YXRldmVjfV8wJCB3aGlj aCBoYXMgYmVlbiBkcmF3biBmcm9tDQphIGRpc3RyaWJ1dGlvbiB3aXRoIGEgbWVhbiBvZiAkXHN0 YXRldmVjXzAkIGFuZCBhIGRpc3BlcnNpb24gbWF0cml4IG9mICRcaGF0c3RhdGV2YXJfMCQuDQpc ZW5ke3F1b3RlfQ0KDQpJdCBtYXkgaGFwcGVuIHRoYXQgJFxoYXRzdGF0ZXZhcl97MH0gXHRvIFxp bmZ0eSQgZm9yIGRpZmZ1c2UgcHJpb3JzLiBJbg0KdGhpcyBjYXNlLCB3ZSBuZWVkIHRvIGNoZWNr IEtvb3BtYW4gKDE5OTcpOyBpbiB0aGUgc3RhbmRhcmQgY2FzZSwNCmhvd2V2ZXIsIHRoZSBwcmVk aWN0aW9uIGVxdWF0aW9ucyBhcmU6DQpcYmVnaW57ZXFuYXJyYXl9DQogIFxsYWJlbHtlcTpmaWx0 c3RhdGVzfQ0KICBFX3t0LTF9KFxzdGF0ZXZlY190KSA9IFxoYXR7XHN0YXRldmVjfV97dHx0LTF9 ICYgPSAmIA0KICBcc3RybWF0X3QgXGhhdHtcc3RhdGV2ZWN9X3t0LTF9ICsgXG1hdGhiZntjfV90 ICBcbGFiZWx7ZXE6c3RhdGVwcmVkfVxcDQogIFZfe3QtMX0oXHN0YXRldmVjX3QpID0gXGhhdHN0 YXRldmFyX3t0fHQtMX0gJiA9ICYNCiAgXHN0cm1hdF90IFxoYXRzdGF0ZXZhcl97dC0xfSBcc3Ry bWF0J190ICsgXHN0cnZhcl90IFxsYWJlbHtlcTpQcHJlZH1cXA0KICBFX3t0LTF9KFxvYnN2ZWNf dCkgPSBcaGF0e1xvYnN2ZWN9X3t0fHQtMX0gJiA9ICYgXG9ic21hdF90IFxoYXR7XHN0YXRldmVj fV97dHx0LTF9ICsgXG1hdGhiZntkfV90ICBcXA0KICBccHJlZGVycl90ICYgPSAmIFxvYnN2ZWNf dCAtIFxoYXR7XG9ic3ZlY31fe3R8dC0xfSBcXA0KICBWX3t0LTF9KFxwcmVkZXJyX3QpID0gXHBy ZWR2YXJfdCAmID0gJiBcb2JzbWF0X3QgXGhhdHN0YXRldmFyX3t0fHQtMX0gXG9ic21hdF90JyAr IFxvYnN2YXJfdA0KIFxlbmR7ZXFuYXJyYXl9DQpzbyB0aGUgdXBkYXRpbmcgZXF1YXRpb25zIGFy ZToNClxiZWdpbntlcW5hcnJheX0NCiAgXGhhdHtcc3RhdGV2ZWN9X3QgJiA9ICYgDQogIFxoYXR7 XHN0YXRldmVjfV97dHx0LTF9ICsgDQogIFxtYXRoYmZ7S31fe3R9IFxwcmVkZXJyX3QgXGxhYmVs e2VxOnN0YXRldXBkfVxcDQogIFxoYXRzdGF0ZXZhcl97dH0gJiAgPSAmIA0KICBcaGF0c3RhdGV2 YXJfe3R8dC0xfSAtIA0KICBcaGF0c3RhdGV2YXJfe3R8dC0xfSBcb2JzbWF0X3QnIFxtYXRoYmZ7 Rn1eey0xfV90IFxvYnNtYXRfdCBcaGF0c3RhdGV2YXJfe3R8dC0xfSBcbGFiZWx7ZXE6UHVwZH0N ClxlbmR7ZXFuYXJyYXl9DQp3aGVyZSAkXG1hdGhiZntLfV97dH0gPSBcaGF0c3RhdGV2YXJfe3R8 dC0xfSBcb2JzbWF0X3QnDQpcb2JzdmFyX3Reey0xfSQgaXMgdGhlIEthbG1hbiBnYWluLiAgRXF1 YXRpb25zDQooXHJlZntlcTpzdGF0ZXByZWR9KS0tKFxyZWZ7ZXE6c3RhdGV1cGR9KSBhbmQNCihc cmVme2VxOlBwcmVkfSktLShccmVme2VxOlB1cGR9KSBjYW4gYmUgd3JpdHRlbiBhcyBhIHNpbmds ZSBzZXQgb2YNCnJlY3Vyc2lvbnMgZ29pbmcgZGlyZWN0bHkgZnJvbSAkXGhhdHtcc3RhdGV2ZWN9 X3t0LTF9JCB0byAkXGhhdHtcc3RhdGV2ZWN9X3QkDQphbmQgZnJvbSAkXGhhdHN0YXRldmFyX3t0 LTF9JCB0byAkXGhhdHN0YXRldmFyX3t0fSQuDQoNCk5vdGUgdGhhdCBpbiBwcmFjdGljZSB3ZSBt YXkNCndhbnQgdG8gaW1wbGVtZW50IHNvbWV0aGluZyBjb21wdXRhdGlvbmFsbHkgc21hcnRlciwg bGlrZSB0aGUNCmluZm9ybWF0aW9uIGZpbHRlciAoc29tZSBiaWJsaW9ncmFwaGljIHNlYXJjaCBp cyBuZWVkZWQgaGVyZSwgSSBjYW4ndA0KcmVtZW1iZXIgZXhhY3RseSB3aGF0IGl0IGxvb2tzIGxp a2UpLg0KDQpJIGNhbid0IGJlIGJvdGhlcmVkIHJpZ2h0IG5vdyB0byB3cml0ZSB0aGUgc21vb3Ro aW5nIHJlY3Vyc2lvbnMsIGJ1dA0KaXQncyBub3QgdGVycmlibHkgaW1wb3J0YW50Lg0KDQpcc2Vj dGlvbntJbnRlbmRlZCB1c2FnZX0NCg0KSW4gbXkgdmlldywgdGhlIEthbG1hbiBmaWx0ZXIgY291 bGQgYmUgdXNlZCBpbiB0aHJlZSB3YXlzOiB0d28gb2YNCnRoZXNlIGFyZSB0aGUgY2xhc3NpYyBm b3J3YXJkcyBhbmQgYmFja3dhcmRzIHBhc3MsIG9yIGZpbHRlcmluZyBhbg0Kc21vb3RoaW5nIGlm IHlvdSBwcmVmZXIuIFRoZSBvdGhlciBjYXNlIGlzIFxlbXBoe3NpbXVsYXRpb259LiBUaGF0IGlz LA0Kd2hpbGUgaW4gdGhlIGZpbHRlcmluZy9zbW9vdGhpbmcgY2FzZSB5b3UgaGF2ZSB0aGUgZGF0 YSAkXG9ic3ZlY190JA0KYW5kIGEgcHJpb3IgYW5kIHlvdSB3YW50IHRvIHJlY29uc3RydWN0IHRo ZSBzdGF0ZXMgJFxzdGF0ZXZlY190JCAoYW5kDQp0aGUgZm9yZWNhc3QgZXJyb3JzIGFzIGEgYnkt cHJvZHVjdCksIHdlIG1heSBoYXZlIGEgY29tcHV0YXRpb25hbA0KYXBwYXJhdHVzIGRvaW5nIHRo ZSByZXZlcnNlOiBnaXZlbiBvbmUgb3IgbW9yZSBhcnRpZmljaWFsbHktZ2VuZXJhdGVkDQpzZXJp ZXMgJFxvYnNkaXN0X3QkIGFuZCAkXHN0cmRpc3RfdCQsIHdlIHdhbnQgdG8gZ2VuZXJhdGUgdGhl IHN0YXRlcw0KJFxzdGF0ZXZlY190JCAoYW5kIHRoZSBvYnNlcnZhYmxlcyAkXG9ic3ZlY190JCBh cyBhIGJ5LXByb2R1Y3QpLg0KDQpUaGUgdXNlZnVsbmVzcyBvZiB0aGUgY2xhc3NpY2FsIGZpbHRl ciBpcyB3ZWxsIGtub3duOyB0aGUgdXNlZnVsbmVzcw0Kb2YgdGhlIEthbG1hbiBmaWx0ZXIgYXMg YSBzaW11bGF0aW9uIHRvb2wgbWF5IGJlIGh1Z2UgdG9vLiBUaGluayBmb3INCmluc3RhbmNlIG9m IE1vbnRlIENhcmxvIGV4cGVyaW1lbnRzLCBzaW11bGF0aW9uLWJhc2VkIGluZmVyZW5jZSAoc2Vl DQpHb3VyaWVyb3V4LU1vbmZvcnQgKDE5OTYpKSBvciBCYXllc2lhbiBtZXRob2RzLg0KDQpcc2Vj dGlvbntVc2VyIHN5bnRheH0NCg0KVGhlIGlkZWEgaXMgdG8gZGVmaW5lIGEgY29tbWFuZCBibG9j ayBsaWtlIHdlIGRvIHdpdGggXHRleHR0dHttbGV9IG9yDQpcdGV4dHR0e2dtbX06IHRoZSBnZW5l cmFsIGZvcm1hdCBvZiB0aGUgYmxvY2sgd291bGQgYmUgc2xpZ2h0bHkNCmRpZmZlcmVudCBpbiB0 aGUgdHdvIGNhc2VzIG9mIGZpbHRlcmluZyBhbmQgc2ltdWxhdGlvbi4NCg0KDQpcc3Vic2VjdGlv bntGaWx0ZXJpbmd9DQoNCldoZW4gdXNpbmcgdGhlIEthbG1hbiBmaWx0ZXIgYXMgYSBmaWx0ZXJp bmcgdG9vbCwgdGhlIHR5cGljYWwgc3ludGF4DQp3b3VsZCBiZSBtb3JlIG9yIGxlc3Mgc29tdGhp bmcgbGlrZQ0KXGJlZ2lue3ZlcmJhdGltfQ0KbGlzdCB5ID0geDEgeDINCiMgb3IgcG9zc2libHkN Cm1hdHJpeCBZID0geyB4MSB4MiB9DQoNCmthbG1hbiBbIC0tc21vb3RoIF0NCiAgb2JzeSB5DQog IG9ic21hdCBIDQogIG9ic2V4IGQNCiAgb2JzdmFyIE9tZWdhDQogIHN0cm1hdCBQaGkNCiAgc3Ry ZXggYw0KICBzdHJ2YXIgUHNpDQogIGluaXN0YXRlIHgwDQogIGluaXByZWMgUDANCmVuZCBrYWxt YW4NClxlbmR7dmVyYmF0aW19DQp3aGVyZSBcdGV4dHR0e29ic3l9IHN0YW5kcyBmb3IgYGBvYnNl cnZhYmxlICRcb2JzdmVjJCcnLA0KXHRleHR0dHtvYnNtYXR9IHN0YW5kcyBmb3IgYGBtYXRyaXgg aW4gdGhlIG9ic2VydmF0aW9uIGVxdWF0aW9uJycNCihccmVme2VxOm9ic2VxfSksIFx0ZXh0dHR7 b2JzZXh9IGZvciBgYGV4b2dlbm91cyB0ZXJtIGluIHRoZQ0Kb2JzZXJ2YXRpb24gZXF1YXRpb24n JyBhbmQgXHRleHR0dHtvYnN2YXJ9IGZvciBgYHZhcmlhbmNlIG9mIHRoZQ0Kb2JzZXJ2YXRpb24g ZXF1YXRpb24nJy4gQSBzaW1pbGFyIGNvbnZlbnRpb25zIHdvdWxkIGhvbGQgZm9yIHRoZSBzdGF0 ZQ0KdHJhbnNpdGlvbiBlcXVhdGlvbiAoXHJlZntlcTpzdHJhbmVxfSksIHdpdGggXHRleHR0dHtz dHJ9IHJlcGxhY2luZw0KXHRleHR0dHtvYnN9LiBUaGUgc3RyaW5ncyBcdGV4dHR0e2luaXN0YXRl fSBhbmQgXHRleHR0dHtpbmlwcmVjfQ0Kc2hvdWxkIGJlIHNlbGYtZXhwbGFuYXRvcnkuDQoNClRo ZSBlbGVtZW50cyBcdGV4dHR0e29ic2V4fSwgXHRleHR0dHtzdHJleH0gYW5kIFx0ZXh0dHR7aW5p c3RhdGV9IG5lZWQNCm5vdCBiZSBjb21wdWxzb3J5LiBJZiBhYnNlbnQsIHRoZXkgYXJlIHVuZGVy c3Rvb2QgdG8gYmUgMC4gTW9yZSBvcg0KbGVzcyB0aGUgc2FtZSBtYXkgZ28gZm9yIFx0ZXh0dHR7 aW5pcHJlY30sIGlmIHRoZSBpbml0aWFsaXNhdGlvbiBpcw0KZG9uZSB2aWEgYSBkaWZmdXNlIHBy aW9yICh0aGUgc2ltcGxlc3QgdGhpbmcgd291bGQgYmUgdG8gdXNlIHNvbWVoaW5nDQpsaWtlICRQ XzAgPSAxMF57MzB9XGNkb3QgSSQsIGJ1dCBzbWFydGVyIG1ldGhvZHMgYXJlIGF2YWlsYWJsZSAt LQ0KYWdhaW4sIEtvb3BtYW4gKDE5OTcpIHNob3VsZCBjb21lIHRvIHRoZSByZXNjdWUpLg0KDQpG b3IgdGltZS1pbnZhcmlhbnQgbW9kZWxzLCB0aGUgYXJndW1lbnRzIHRvIFx0ZXh0dHR7b2JzbWF0 LCBzdHJtYXR9DQpldGNldGVyYSBtdXN0IGJlIG1hdHJpY2VzIG9mIHRoZSBhcHByb3ByaWF0ZSBz aXplLiBJbiB0aGUgY2FzZSBvZg0KdGltZS12YXJ5aW5nIG1vZGVscywgdGhlIGJlc3QgaWRlYSBJ J3ZlIGJlZW4gYWJsZSB0byBjb21lIHVwIHdpdGggc28NCmZhclxmb290bm90ZXtBbm90aGVyIHNv bHV0aW9uIGlzIHRvIHBhc3MgbWF0cmljZXMgd2l0aCAkVCQgcm93cyBhbmQgYW4NCiAgYXBwcm9w cmlhdGUgbnVtYmVyIG9mIGNvbHVtbnMsIHdoZXJlIGVhY2ggcm93IGlzIHRoZSB2ZWN0b3JpemF0 aW9uDQogIG9mIHRoZSBjb3JyZXNwb25kaW5nIG1hdHJpeCBhdCB0aW1lICR0JDsgZm9yIGV4YW1w bGUsIGlmICRcc3RybWF0X3QkDQogIGlzIHRpbWUtdmFyeWluZywgdGhlbiB0aGUgYXJndW1lbnQg dG8gXHRleHR0dHtzdHJtYXR9IHdpbGwgaGF2ZSB0bw0KICBiZSBhICRUIFx0aW1lcyBtXjIkIG1h dHJpeC4gSXQnbGwgYmUgZ3JldGwncyBqb2IgdG8gcmVzaGFwZSB0aGUNCiAgcGVydGluZW50IHJv dyBvZiBzdWNoIGEgbWF0cml4LCBidXQgdGhlIG1vcmUgSSB0aGluayB0aGUgbW9yZSBJIGZpbmQN CiAgaXQgdWdseS59IGlzIHRvIHBhc3MgbWF0cmljZXMgd2hpY2ggcmVzdWx0IGZyb20gdXNlci1k ZWZpbmVkDQpmdW5jdGlvbnMuIFRoaXMgaXMgdmVyeSBnZW5lcmFsIGFuZCBlbGVnYW50OyBzZXZl cmFsIGludGVyZXN0aW5nDQpwb3NzaWJpbGl0aWVzIGFyZSBvcGVuZWQgaGVyZSwgc3VjaCBhcyBh bGxvd2luZywgc2F5LCB0aGUgZWxlbWVudHMgb2YNCiRcb2JzbWF0X3QkIHRvIGRlcGVuZCBvbiAk XHByZWRlcnJfe3QtMX0sIFxvYnN2ZWNfe3QtMX0kLCBzdHJ1Y3R1cmFsDQpwYXJhbWV0ZXJzIChh cyBjYW4gYmUgdGhlIGNhc2Ugd2l0aCBEU0dFIG1vZGVscykgYW5kIHNvIG9uLiANCg0KSGVuY2Us IHlvdSB3b3VsZCBoYXZlIHNvbWV0aGluZyBsaWtlDQpcWw0KICBcb2JzbWF0X3QgPSBcb2JzbWF0 KFxleG9nX3QsIFxwYXJhbSksDQpcXQ0Kd2hlcmUgJFxvYnNtYXQkIGNvcnJlc3BvbmRzIHRvIGEg dXNlci13cml0dGVuIGZ1bmN0aW9uIG9mIHRoZSBraW5kDQpcYmVnaW57dmVyYmF0aW19DQogICAg ZnVuY3Rpb24gTXlPYnNNYXQobGlzdCBYLCBtYXRyaXggdGhldGEpDQpcZW5ke3ZlcmJhdGltfQ0K d2hvc2UgY29udGVudCBkZXBlbmRzIG9uIHRoZSBjb250ZXh0IChyZWN1cnNpdmUgT0xTLCBBUk1B cywgeW91IG5hbWUNCml0KSwgdG8gYmUgY2FsbGVkIGFzDQpcYmVnaW57dmVyYmF0aW19DQogICAg bGlzdCBaID0geDEgeDIgeDMNCiAgICBtYXRyaXggcGFybSA9IHsgMC41LCAtMC44IH0NCiAgICBr YWxtYW4NCiAgICAgIG9ic21hdCBNeU9ic01hdChaLCBwYXJtKQ0KICAgICAgLi4uDQogICAgZW5k IGthbG1hbg0KXGVuZHt2ZXJiYXRpbX0NCg0KT2YgY291cnNlLCBvbmUgYWxzbyBuZWVkcyB0byBy ZXRyaWV2ZSB0aGUgaW50ZXJlc3RpbmcgcXVhbnRpdGllczogdGhpcw0KY291bGQgYmUgZG9uZSB2 aWEgdmlhIHRoZSBleGlzdGluZyBhY2Nlc3NvcnMgXHRleHR0dHtcJHVoYXR9IGZvcg0KJFxwcmVk ZXJyX3QkIGFuZCBcdGV4dHR0e1wkc2lnbWF9IChvdGhlciBjYW5kaWRhdGVzIG1heSBiZQ0KXHRl eHR0dHtcJHZjdn0gYW5kIFx0ZXh0dHR7XCRofSAtLS0gYnV0IEkgcGVyc29uYWxseSBsaWtlDQpc dGV4dHR0e1wkc2lnbWF9IGJldHRlcikgZm9yICRccHJlZHZhcl90JC4gV2hlbiAkbiA9IDEkLCB0 aGVzZSB3b3VsZCBiZQ0Kc2VyaWVzOyBvdGhlcndpc2UgXHRleHR0dHtcJHVoYXR9IHdvdWxkIGJl IGEgJFQgXHRpbWVzIG4kIG1hdHJpeCAoYQ0KYml0IGxpa2Ugd2UgZG8gZm9yIHNpbmdsZSBlcXVh dGlvbi9tdWx0aXBsZSBlcXVhdGlvbnMgbW9kZWxzKSwgd2hpbGUNClx0ZXh0dHR7XCRzaWdtYX0g c2hvdWxkIGJlIGEgJFQgXHRpbWVzIFxmcmFje24gKG4rMSl9ezJ9JCBtYXRyaXgsIHdpdGgNCnRo ZSAkdCQtdGggcm93IGhvbGRpbmcgJFxtYXRocm17dmVjaH0oXHByZWR2YXJfdCknJC4gTmV3IGFj Y2Vzc29ycw0Kc2hvdWxkIGJlIGRldm90ZWQgdG8gcmV0dXJuaW5nIHRoZSBzdGF0ZXMgYW5kIHRo ZWlyIHZhcmlhbmNlczoNCnN1aXRhYmxlIGNhbmRpZGF0ZXMgY291bGQgYmUgYW5kIFx0ZXh0dHR7 XCRzdGF0ZXN9IGZvciAkXHN0YXRldmVjX3QkIGFuZA0KXHRleHR0dHtcJHN0dmFyc30gZm9yICRc bWF0aHJte3ZlY2h9KFxoYXRzdGF0ZXZhcl90KSckLg0KDQpNb3Jlb3ZlciwgaXQgaXMgcHJvYmFi bHkgdXNlZnVsIHRvIGFsc28gcmV0dXJuIHRoZSBzZXJpZXMNClxbDQogIFxlbGxfdCA9IC0wLjUg XGxlZnRbIA0KICAgIG4gXGxuKDIgXHBpKSArIFxsZWZ0fFxwcmVkdmFyX3RccmlnaHR8ICsgDQog ICAgXHByZWRlcnJfdCdccHJlZHZhcl90XnstMX0gXHByZWRlcnJfdA0KICBccmlnaHRdICwNClxd DQpwb3NzaWJseSBpbiB0aGUgYWNjZXNzb3IgXHRleHR0dHtcJGxubH0sIHdoaWNoIHdvdWxkIHlp ZWxkIHRoZQ0KbGlrZWxpaG9vZC4gSXQgdGhlbiBiZWNvbWVzIHRyaXZpYWwgdG8gaW5zZXJ0IHRo ZSB3aG9sZSB0aGluZyBpbiBhbg0KXHRleHR0dHttbGV9IGJsb2NrIHRvIGVzdGltYXRlIGFsbCBz b3J0cyBvZiBtb2RlbC4gTm90ZSwgaG93ZXZlciwgdGhhdA0KdGhlIFx0ZXh0dHR7a2FsbWFufSBi bG9jayBpdHNlbGYgd291bGQgcGVyZm9ybSBubyBvcHRpbWlzYXRpb24NCndoYXRzb2V2ZXI6IGl0 cyBqb2Igd291bGQgb25seSBiZSB0aGUgZmlsdGVyaW5nIChvciB0aGUgc21vb3RoaW5nLA0Kd2l0 aCB0aGUgXHZlcmJ8LS1zbW9vdGh8IG9wdGlvbikuDQoNClxzdWJzZWN0aW9ue1NpbXVsYXRpb259 DQoNCkZvciB1c2luZyB0aGUgS2FsbWFuIGZpbHRlciBhcyBhIHNpbXVsYXRpb24gdG9vbCwgb25s eSBzbGlnaHQNCnZhcmlhdGlvbnMgd2l0aCByZXNwZWN0IHRvIHRoZSBhYm92ZSB3b3VsZCBiZSBu ZWVkZWQ6IA0KXGJlZ2lue3ZlcmJhdGltfQ0Ka2FsbWFuIC0tc2ltdWxhdGUNCiAgb2JzeSB5DQog IG9ic21hdCBIDQogIG9ic2V4IGQNCiAgb2JzaW5ub3Ygdw0KICBzdHJtYXQgUGhpDQogIHN0cmV4 IGMNCiAgc3RyaW5ub3Ygdg0KICBpbmlzdGF0ZSB4MA0KICBpbmlwcmVjIFAwDQplbmQga2FsbWFu DQpcZW5ke3ZlcmJhdGltfQ0KDQpJbiBwcmFjdGljZSwgdGhlIGRpZmZlcmVuY2VzIHdpdGggdGhl IGZpbHRlcmluZyB1c2FnZSB3b3VsZCBiZQ0KXGJlZ2lue2l0ZW1pemV9DQpcaXRlbSB5b3UgZG9u J3QgcGFzcyB0byBcdGV4dHR0e2thbG1hbn0gdGhlIHZhcmlhbmNlcyBvZiB0aGUNCiAgaW5ub3Zh dGlvbnMgJFxvYnNkaXN0X3QkIGFuZCAkXHN0cmRpc3RfdCQsIGJ1dCByYXRoZXIgdGhlIGlub292 dGlvbnMNCiAgdGhlbXNlbHZlcyAod2hpY2ggaGF2ZSB0byBiZSBnZW5lcmF0ZWQgcHJldmlvdXNs eSkgaW4gYSBzZXJpZXMsIGENCiAgbWF0cml4IG9yIGEgbGlzdCB0aHJvdWdoIHRoZSBrZXl3b3Jk cyBcdGV4dHR0e29ic2lubm92fSBhbmQNCiAgXHRleHR0dHtzdHJpbm5vdn0uDQpcaXRlbSB0aGUg YXJndW1lbnQgdG8gdGhlIFx0ZXh0dHR7b2JzeX0ga2V5d29yZCB3b3VsZCBiZSByZXBsYWNlZCwg b24NCiAgZXhpdCwgd2l0aCB0aGUgcmVzdWx0IG9mIHRoZSBzaW11bGF0aW9uLiBJIGRvbid0IHRo aW5rIGl0J3MNCiAgbmVjZXNzYXJ5IHRvIGRlZmluZSBhIGtleXdvcmQgZm9yIHJldHJpZXZpbmcg dGhlIHN0YXRlIHZlY3Rvcg0KICAkXHN0YXRldmVjX3QkOiBpZiBhbnkgZWxlbWVudHMgb2YgJFxz dGF0ZXZlY190JCBhcmUgbmVlZGVkLCBvbmUgbWF5DQogIHNpbXBseSBkZWZpbmUgb25lIG9yIG1v cmUgZXh0cmEgcm93cyBpbiB0aGUgJFxvYnNtYXQkIG1hdHJpeCBhcyBuZWVkZWQuDQpcZW5ke2l0 ZW1pemV9DQoNClxzZWN0aW9uKntSZWZlcmVuY2VzfQ0KDQpHb3VyaWVyb3V4LCBDaHJpc3RpYW4g YW5kIEFsYWluIE1vbmZvcnQgKDE5OTYpLCBcZW1waHtTaW11bGF0aW9uLUJhc2VkDQpFY29ub21l dHJpYyBNZXRob2RzfSwgT3hmb3JkIFVuaXZlcnNpdHkgUHJlc3MuDQpcc21hbGxza2lwDQoNClxu b2luZGVudA0KSGFtaWx0b24sIEphbWVzIEQuICgxOTk0KSwgXGVtcGh7VGltZSBTZXJpZXMgQW5h bHlzaXN9LCBQcmluY2V0b24NClVuaXZlcnNpdHkgUHJlc3MuDQpcc21hbGxza2lwDQoNClxub2lu ZGVudA0KSGFydmV5LCBBLkMuICgxOTkxKSwgXGVtcGh7Rm9yZWNhc3RpbmcsIFN0cnVjdHVyYWwg VGltZSBTZXJpZXMgTW9kZWxzDQogIGFuZCB0aGUgS2FsbWFuIEZpbHRlcn0sIENhbWJyaWRnZSBV bml2ZXJzaXR5IFByZXNzLg0KXHNtYWxsc2tpcA0KDQpcbm9pbmRlbnQNCkhhcnZleSwgQS5DLiBh bmQgVC4gUHJvaWV0dGkgKDIwMDUpLCBcZW1waHtSZWFkaW5ncyBpbiBVbm9ic2VydmVkDQogIENv bXBvbmVudCBNb2RlbHN9LCBPeGZvcmQgVW5pdmVyc2l0eSBQcmVzcy4NClxzbWFsbHNraXANCg0K XG5vaW5kZW50DQpLb29wbWFuLCBTLiBKLiAoMTk5NyksIGBgRXhhY3QgSW5pdGlhbCBLYWxtYW4g RmlsdGVyaW5nIGFuZCBTbW9vdGhpbmcNCmZvciBOb25zdGF0aW9uYXJ5IFRpbWUgU2VyaWVzIE1v ZGVscycnLCBKb3VybmFsIG9mIHRoZSBBbWVyaWNhbg0KU3RhdGlzdGljYWwgQXNzb2NpYXRpb24s IFZvbC4gOTIsIE5vLiA0NDAsIHBwLiAxNjMwLS0xNjM4IFxzbWFsbHNraXANCg0KXG5vaW5kZW50 DQpQb2xsb2NrLCBELlMuRy4gKDE5OTkpLCBcZW1waHtBIEhhbmRib29rIG9mIFRpbWUtU2VyaWVz IEFuYWx5c2lzLA0KICBTaWduYWwgUHJvY2Vzc2luZyBhbmQgRHluYW1pY3N9LCBBY2FkZW1pYyBQ cmVzcy4NCg0KDQpcZW5ke2RvY3VtZW50fQ0KDQolJSUgTG9jYWwgVmFyaWFibGVzOiANCiUlJSBt b2RlOiBsYXRleA0KJSUlIFRlWC1tYXN0ZXI6IHQNCiUlJSBFbmQ6IA0K --===============5866647211392915187==-- From cottrell@wfu.edu Wed May 14 15:23:49 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: [Gretl-devel] Quantile regression in gretl Date: Wed, 14 May 2008 15:23:33 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4677744741793467920==" --===============4677744741793467920== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I'm not finished with this yet, but I'm far enough along that it would be good to get some comments. There's a document describing the current state (in CVS and Windows snapshot) at http://www.ecn.wfu.edu/~cottrell/gretl/QReg.pdf Allin. --===============4677744741793467920==-- From andreas.rosenblad@ltv.se Thu May 15 03:34:49 2008 From: andreas.rosenblad@ltv.se To: gretl-devel@gretlml.univpm.it Subject: [Gretl-devel] Bug in the new quantile regression function Date: Thu, 15 May 2008 09:34:43 +0200 Message-ID: In-Reply-To: OF68E931FE.2D4EC052-ONC1257449.006AAF49@LocalDomain MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2556904729305818787==" --===============2556904729305818787== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit First, thanks for the new quantile regression function in gretl. It looks great. However, I found a bug (using the Windows snapshot from 2008-05-14): 1. Using the GUI, open the Ramanathan data file "data 4-1". 2. Choose Model > Robust estimation > Quantile regression... 3. Set price as dependent and srft, bedrms, baths as independent 4. Set 0.25 0.50 0.75 as desired quantiles 5. Press OK: The program freezes Best regards Andreas --===============2556904729305818787==-- From andreas.rosenblad@ltv.se Thu May 15 05:06:15 2008 From: andreas.rosenblad@ltv.se To: gretl-devel@gretlml.univpm.it Subject: [Gretl-devel] Another quantile regression bug Date: Thu, 15 May 2008 11:06:10 +0200 Message-ID: In-Reply-To: OF68E931FE.2D4EC052-ONC1257449.006AAF49@LocalDomain Content-Type: multipart/mixed; boundary="===============0598698127302432434==" --===============0598698127302432434== Content-Type: application/pdf Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="graph.pdf" MIME-Version: 1.0 JVBERi0xLjQNCiW17a77DQoyIDAgb2JqDQo8PCAvTGVuZ3RoIDMgMCBSDQogICAvRmlsdGVyIC9G bGF0ZURlY29kZQ0KICAgL1R5cGUgL1hPYmplY3QNCiAgIC9TdWJ0eXBlIC9Gb3JtDQogICAvQkJv eCBbIDAgMCAzNjAgMjE2IF0NCj4+DQpzdHJlYW0NCnicxZ3fjiu5cYfvD3DeQS+wcvNvk0CQiwSJ AQO+sL13hi/Ws7veGOfE2E0Av37YEtn1K7LYRcSjsY2xxa9HVd80pSaLEvv8fDOP//7yl9uvvttu f/mfz5+223ZzcbtZE2+//HD78fOn333+9PNte/z3978+fy/c/v75k7395njGXz9/+uOfbtt9u33/ +ZPZbr+9/Xy0wuM53zwf3UMJGcr/vn39/Mnv7p7Lf1y+ueTt8Tjt6fb1Ftx+37bNWMsOfLn94fa7 l5jsmxEzfr3FHETJ0QXO3r99+/nTr/79u//65W//+bf//t9vtm+2cna/LScx3uPxn/3xhLOx300K 1pib3e4l3Zb97dsi9cd/OYzKjy0/7vj51z/dvi1/4H98+/LusMm288G7Aw58UHcwFdYdly7//+4w /p4261y6+Xw/znxO1B/+Q/vB7tYcf+IWDe8HPPAx/cBVsB+uXf6Rt0WwbrflQZEIzmyGd8PHvy3K 1XDr+uEgH9QBz+TszMvZ3+GUmy3cywn3KfJzHj78nJuQU3vMTj0e+Jge4CrYEdcu79Efzt1NMMHy 7ogf3x1b6QFpoMYDH9QdTIV1x6XLe3RHNHe78ZH66I/9w/vD77s4UAP/mN5gItgZlybv0Rcp320Y R+n08bMmNnPEA3t65SgxezkAD/59B4oy4jvj4h7KlemfMUcyezpPNT/t7MhrzzumYiceD7z3mU+l T53PW3yeeeNz6M58+cnHUP3aHihdfs76eA+wI6/tAUzFegAPvHcPlFN+d6ULzPzFX7tgf/Glp+Tq LzoP9OLLzZGDX2gO8v6XGH/fUznNtp5mYyen+bvXnuawb7t8rWFHXnvSMRUf8+HAu3dB2u4mwcUm GCN3wZ9f2wXz9Rl25LVdMJ3t4IH37gLn091HF2OZ1R5/ts/99d7+c+aak3nPl9usr/gRNiuUc7zr NTs9Xr+xeJSZe7l4w8T9rfx8X35+kE/kP5A0pHtMwe6leN/M3dgYnaO8Pz5X94w5/tz6444Rvf7/ wUP18/V3Q30MbXMUgW+D+z2Wn2wfD+BPCPGejlPtb6EYPUbI4yIi0C+3MrGO/kGN8/d4/MLOMP7y T7PYPypGUrivs9zldXF34fE72d3DYzmC485Jjq45ifG+TrOHcH+ujNzy1n6BYWfvKZDUJLxqJQX8 Ok2f9vtRAxVsyvsrCdyV90KoSnJsVakP9nWa19rjwmKiv7vni6QhF4j8JIbULPo4X8Vkwd5NfSn4 lmGKf5Kiqh5SrK/zzO5uni9sfNEiDnfv6yv/p2l43UoI+HWaPgXpWoC4XODgHTYJr1pJAb/O0juT pIvOBP80Df/je82MjiVvc7xE4z2kzefzsm6ONaAfnkNKu3w/LufpeUl/XL5Nu2zXY7kOQW9w7Pi9 757HH/zPlb09p13m+9qGXObH184FYjDxrOyCx88D0m6kIy8svo2lubfdI7nMjnzhawM2wUzDeljT T/aYw2EJWUZuWFB0u490ZIcjz/KrdGd5HDZYqA8O5kE4ZS9+xxW4zPDIzJi1xeSwt0tTefHXIfIo CIBurlSqxzvgEtXnviEtI9TxUs8YT2Lw7Nd8Smy2OO3oNOnoj3nRmdmLzrkLF+jAMlwbunr5OsoA 3e4+lWj7MR26Yuez3zhN5uivG8sjsfPZL+rC3Yrvu2Oy4CfvyI9YtHPWTlbtyltkrQ45pnJ1irP7 e6iTxEbK9Kd0lS1FRxkvLuHx3DdGwv3oqFI7YEARPp/7mq6zbucXxjJE+9xfK1/VWeyyvMdndrxS iwV/N2Wu8/TSuTSRB2zu3j0uiaZMqi7hGeCtw/vxjnI3nkyEZ4DX9JbbnDhmfS2DSpiMZh+xNmvj hi54ZLdrH9WZlO5ua71zTugQl2lm7bRyIbmEZ4A3hu3d1k6DqCKEAC/qyZjEOUY5e2mbzD5e1pNs vmPQBY/six+6lrlzmWg8ijRzlAzueTUs5VbfOk7v88Fj3n2sozyey1sv6wPvfJ3NHUvc8ZzZvXRh 3ZUJ/7mQb4NyfTuKrzr/Kq/Os2zn2KTHG+AoHxVYA7wxnO/BPN4AGFWEEOBFPVImxdKcusx6jZnM tl+2Io/ze7+jC5v557XvDNp0zr3Le/qx7IHoKDOfb4wUruHjyW8dyub5hmFJRGhfN5cI0fO65yhW Yl8KfcQnKHbfQvfZSZnJSNmhh8q7/5wy5zamHyMr4fIGON5W5rEwcQnPAG+I43a3x9sKg0oMn/6a vopuEwvSUup7u1iqvp8LFMdbQBdWNu9rZbNzoS0auUQLVoj3+56Oq6M71p4v2Pn0N4ZLP5lHnYwx RQgBXtSPka6F3ZLNHsQjL+zHSNdC5xO64JG4veTrpLYU5XH35RVT3uv3zdts6cOY47uktkzOrV1b oXu/1TnzmtW5fdv6ZbkD9Sf0/bLj12RDgDni5MCXx0elnESY2fID+/lNb34A5pz8QNomWeGM8AMZ 6kp24HhZyEnMFpOcpcxGQo/sNslsyjR+ktq5WWqXZ6l9HFIHN0sd8uQElmvV5Aya3fUdZ/Y86TmT 4qTrTLaz1GyWh0fsFvvUtpw9ObUtGeTU1oZJalum3APKk5NnfZj0W5k+T/rNhjTpNxvDkBq+Wd8f SbPUKcxSZzNLnVOfuoyzk5NXxvzJyXPHp+xigkch0yFnJv3mXJql9n6WOphZ6pCG1NHPUu9mlnrf JyfPJT+cvGwm/ebyPuk3v/lJv3mzTVJ7s/epvfWT1N5ts9Run6X2bpY6zK7V5U0xOYc+zq7Wfp9d rv2+993nk5ulztssdY6T1GFzs/GpXPgHFCepg51dqYOdXamDG67Uwc+u1AFXXfmREGepo52ljnlI vcdZ6mRnqVOepc7DlTpusyt13GZX6mhmV+po7aTfos1DahdmqY9qRk7t0yx1CLPU0Q6p4+xKjRPw 7kiaXaljGq7UpScn/cZ2D7Ej/SQQ1yHOb9uY8op+LEMAMe2zC+sUaB8fSiBx7bMLDChCO3ygwRUT uSWWfx9aVYOnSkNLyViC1pXflhjJmdFtCnymQXJqYEARaoq+LUmfikDIximwKgIhG69ATXFvX8k4 FYGQTVRgVQRCNrsCFcUyeBr+6kdy2vhNgc80SE4bDChCTfH85OlUBEI2ToFVEQjZeAVqintbCD4V gZBNVGBVBEI2uwIVRfrQuykiOW3CpsBnGiSnDQYUoabo2+LQqQiEbJwCqyIQsvEK1BT3+2MLUNWr LbKIE1CVaosy7xOgaBwTF/6WQHJmj5sCn2mQnCYYUISaom/fzDwVgZCNU2BVBEI2XoGa4k5fua2K QMgmKrAqAiGbXYGK4r7dM39LICGbrMCqCOS0wYAi1BT98RHKqVdbp8XuJuAZtrUos58ATWPvRwkk lD0qsGpFYUDAgCJUFNPWTweQkE1WYFXMwsiPAUWoKfp+OoDktElOgc80SMjGK1BT3O/0cqsNcohi u+o8G5R0F9tK/ryd3/auEkgoc1ZgdQJyimBAEWqKvn3v5lQEctpkp8BnGiRk4xWoKZ5fqDwVgZBN VGBVBEI2uwIVxfKn9JUhQ+STFVgls1AFsogyVTU9+LETZfirz8Brx/AX1/OJXVNNvPdFIkOQN2q0 SUWhJmRBZaqZmq2vFRkCp6zRZpqF0pAFlalq6voxgiFyMlaj1RQRODmNqqY7jvtnE1zijDSz2A31 Z5CRaDbH1hU+/DMEDlmjzS4Loz0LKlPV1PW1IkPkRF94ndFqigicnEZV070vGRkCp6jRZhqFCpEF lalm6ra+cmQInLJGm2kWCkUWVKaqqcMC8mySSzkyIdWsNSG/mxHVZu/rSIbAIWq02UWhbGRBZaqZ +q0vJxkCp6zRZpqF6pEFlalq6vqqkiFy8laj1RQRODmNqqaxLy4ZAqeg0WYahFqSBZWpZho2Nta0 JrjkGWlmuR9ZWpCRqDZumE0EaZXZHN8pvabVDhH4SGvSQ/ZL0zjMJoK02Hx8Z1+hzTRI84YgLU0P 2a9M49YXngyBU9ZoM81CncmCylQ1dVB/thaZRCuDalVbkNrJQNWIfRnKEOQPGm1qQag6WVCZaqb7 1lejDIFT1mgzzULxyYLKVDV1fVHKEDntVqPVFBE4OY2qpnEoTRGBU9BoMw1SHYpBZaqZpo0UH4/B Io/NZpNZwscTu6aa2A3VKSLKm6xGqxQikHEaVU3jMJ4gAqeg0WYapJEDg8pUNc3DjCFJS8/HziGF NtMkzQ2StFA9ZL8yzY7NGHK/Cn18VW5CqllrUv7cr1WzLJc2cahOs7QQbXLQaLMLUh2apWXrIful aR6qU0TglDTaTJNUh2JQmSqmdnN9dcoQfStisxp9pmKIvi2BQWWqmsa+OmUInIJGm2kQ6lAWVKaq acbq9GyCS5qRZpa6WvQMMhLN5rgFF3/XMEQOx3cYr2m1Q0Q+GFSmqmnsq1OGwClotJkGoQ5lQWWq mua+OmUInJJGm2kS6lAWVKaa6fGF4u5dg4icrNFoNUVEThhUpqpp7GcaDIFT0GgzDcKcggWVqWqa +5kGQ+CUNNpMkzCnYEFlqpk621euDME38IxGqykicnLS6viQ/dI09pUrQ+AUNNpMg1CjsqAyVU0z VK6tBSZJBs0q8UK1BRiApuFtX7kyRPm90WhVQ0Q6GFSmqmnsK1eGwClotJkGoUZlQWWqmua+cmUI nJJGm2kSalQWVKaaKe2zPk0RkRPdaGdGqykicsKgMlVNodsD79kQxmaz4e+JEMemmjgP4wkiyJs0 2qSSNHJgUJlqptEOs4korWrbaDRaTRGRU5RWwIfsl6ZhmE1EaVXbRq/RZuqleUOUVsCH7JemGSvX swkuaUaaWerq1DPISDSb3faVK0PksBuNVjtE5INBZaqahr5yZQicvEabqRdqVBZUpqppHipXROCU NNpMk1SjYlCZaqbJDpUrInI67h90TaspInLCoDJVTQOrXFsTXPyMNDPf16ktyEhUmzxUrojAIWm0 2SWpRsWgMtVMsx0qV0TklI1GqykicsKgMlVNwzDWIAInr9Fm6qVRBYPKVDXNoJi5RRqbzYZv0sl5 bCqJjztY9Lt2Nmlx223yZp5h8w1DpwwLKlPVNPSFKEPgJO7p2YY9OAyBk7QQPmS/NE3DHh5E4CRu 7dmGrTgMgVPSqGZqbF+IMkRORtrhw2g1NdLOHRZUpqppgEK0tcDEy6BZeV53tgADUDVSX4gyBPl3 jTa1XSg5WVCZaqbW9oUoQ+RkjUarKSJywqAyVU1DX4gyBE5eo83UCyUnCypT1TT1hShD4LRrtJnu QsnJgspUM3WWFB+PycKZsVltHo8pobNjU00c+skBQ5BX2trDaJOStuywoDJVTVM/OWAInKQdPow2 U2nnDgsqU83Um74QZYicvLTRh9Fq6qUNPCyoTFXTgIXo2QSXfq/PSZpZv5fnDDIS1Sb1hShD4CBt +2G02UnbeVhQmWqmxy2Hu3cNInIKm0arKSJywqAyVVcN2zXIn8tiuPu90Oe9s2lTu4zOG2IDde3W 2RBPYvDsq/3vzDCBx94/JhmWMXWNlbzunP1iekafmWmDu4zOVEBPG4gnsSXRc/LLRJFWK3eNSJQo SflLtiR6zn2ZKNJqFa8RiRIlqf2SrYjS/nQUZfRpRVveZXSmAnpKQTyJLYmeu9SZKNJq5a4RiRIl KX/JlkTPvepMFGm1iteIRImS1H7JVkRpxzqKMlr/SYHtGtG/MkD0lIJ4ElsSPfetM1Gk1cpdIxIl SlL+ki2JPna1M8lGzn+cQWziv9NwEAf/HoPUXpGhPewoxOjTgrbFy+hMBfQUgngSWxI958pMFGm1 cteIRImSlL9kS6LnVJmJIq1W8RqRKFGS2i/ZiijtakdRRqtVvkYkSvSUgngSWxJ9TJyZZCNPm+e2 +bF5hq6EBLzYXpLZpRGG0WoRrxHJxXE0gXgSWxGlfe4oymi1yteIRPM4kYB4ElsS9dLkgtGnFW2g l9GZCihJ+Uu2JHrsiGeOFVSXKLVI6gEo9y40Vyxo5zuqMFoN8jUiM6KnD8ST2JLouf+diSJ9WtGW ehmdqYCSlL9kS6LnLngmirRaxWtEokRJar9kK6KwER5NOa5e+RqRKtFTCwOKcE3Wd5Zw2gy+Kk33 ijLsVfd4Hm+tpd+lcpXjlj8qDNTiWJ5iTBEu+dK+eObLcHPLCgPfPFapGFOEa75OGl84rm606X7C yBcwqLlruOa797MIQs0pTtrgF/nMocUYwJIT7ZRnXgw3l6wwcMzj5AFjinDN10lVK8fVjbbhTxj5 AgY1dw3XfHepeOW4uUWFgW8ci1WMKcIlX9o7z3wZbm5ZYeCbx5oVY4pwzdf1pSyh6uTspE1+FYGG k8Ga0y5VtBw3l6gwcIxjBYsxRbjkS7vpmS/DzS0rDHzzWMhiTBGu+TqpvuW4unmrMPIFDGruGq75 RqnM5bi5BYWBbxjLWowpwiXf57575nqi5pQnbfDL3bBUYwxgzUlYFWf7/MmFNu9PGDkCBi1hqV3M v7bTn/uOy+iwhX/CwDcI05AgrLiL+df2+zPfOK6mw0b+CQPfPJa8GFOEa76uq4RPUo0eG/vHJrk9 CRg4qb0mE6WCmOPmERQGgmEsgDGmCJd8aQ8+82W4uWWFgW8e62CMKcI1XyeVxxxXN9rgP2HkCxjU 3DVc8z3343NfxM0tKAx8CYNavIZLvmnjos92s8lDA5wy5j2ex1tr6Z1YJzNc89OW/wkjNcDg5K7h mm8UxyKGm1tQGPgGYdiBmCJc8xWWytmdAsAtKQx8kzDVSML6u5hfv1cAc818fb3eDEBok19FpJGd DNachIVzdtcAcAkKA8cglMRZWI0X86/dN4D75rEmphsCTBj4JqEkhpgiXPGF/fvoy3H9VgndFmDC znSI6csmEFOEa75RqpM5bm5BYeAbxpIYY4pwzTf3dTKh5pQmbfBLvCxuMQaw5EQ7+pkXw9WFbhQw YeQImLQgpgjXfKNUJ3Pc3ILCwDeMJTHGFOGab5bqZI6bW1IY+KaxJMaYIlzypT3+zJfh6ka3Dpgw 8gVMahBThGu+wgI9u9cAuAWFgW8YpygYU4RrvsICPbvjALglhYFvGqcoGFOES75OWKBn9x0gN7qZ wISRL2BSc8Kiv5h/7c4D3DcO9TLcUmDCwDeM5TLGFOGab+5q6JM0oyQ2wS2xmrk+v28vyXgr1dAc Vw+6vcCEkSBgsoKYIlzzjVINzXFzCwoD3zCWyxhThGu+WaqhOW5uSWHgm8ZyGWOKcMmX7gzAfBmu bnTDgQkjX8CkBjFFuObbvRAC9nYIQwOc2FsmxL61lj6LYxHDLX9SGKglYdiBmCJc8qV7BTBfhqsb 3YJgwsgXMKlBTBGu+QqL8OyeBeDmFQa+XpiGRGFhX8yv37WAu/I1+3pbAqENfomXzC3GAJac6O4B zIvh6kI3JZgwcgRMWhBThGu+QaqhOW5uXmHg68dyGWOKcM03izU0w80tKQx8k1AuQ0wRLvnS/QSY L8PVjW5TMGHkC5jUIKYI13zDUEOfqDn5SRv8fFcy1xgDWHPKYg3NcHNJCgPHJJTLEFOES750hwHm y3B1oxsXTBj5AiY1iCnCNd8gjlMMNzevMPD1wpAEMUW45ps70Yw2aWiAE9uRlXPfWkkP9xxAC46f +eFWBhN2pkN8OmFMEa75Cmvx7N4H4Cbs3trE3VaIQU1Y3xfzr939gPumofyF2xpMGPhK+7MgpgiX fOkuBMyX4epmxr1cnJGvEbZpYUwRrvmGriQ+STPyYhPcPCuB6/P79ppMkkpijpvHrjAQ3MfqF2OK cMmX7kvAfBmubnS7gwkjX8CkBjFFuOYbpJKY4+bmFQa+fqx+MaYI13zPexRwX8TNbVcY+BIGtXQN l3yd5aLPdrVxZmiQ09GmvMfzeGstvbDezu6YAPnHTVycgZqwPwtjinDNV1hvZ/dNALdxLxdn4Cts 08KYIlzy9cJ6O7t7Arn5cUsXZ+Trhd1aGFOEa76hL4kJNSc/aYNft3GrxRjAmlOSSmKOm8u4wYsz cBT2bmFMES750t0MmC/D1Y1ukjBh5AuY1CCmCCe+2+33v6aNrre/lznx7TefP223v37+9Mc/3bb7 dvv+2Jtx++3t56MVHs/55vmoDM32MUC/fT02SLv7kcEdO5b3e8lqrH1skT65S0WjPEx7un257Zs5 f21+BGJ9uck5vtz+cPvd42/6P37TLvMNCmVuZHN0cmVhbQ0KZW5kb2JqDQozIDAgb2JqDQogICA2 MTUwDQplbmRvYmoNCjQgMCBvYmoNCjw8IC9UeXBlIC9QYWdlDQogICAvUGFyZW50IDEgMCBSDQog ICAvTWVkaWFCb3ggWyAwIDAgMzYwIDIxNiBdDQogICAvQ29udGVudHMgWyAyIDAgUiBdDQogICAv R3JvdXAgPDwNCiAgICAgIC9UeXBlIC9Hcm91cA0KICAgICAgL1MgL1RyYW5zcGFyZW5jeQ0KICAg ICAgL0NTIC9EZXZpY2VSR0INCiAgID4+DQo+Pg0KZW5kb2JqDQo1IDAgb2JqDQo8PCAvRmlsdGVy IC9GbGF0ZURlY29kZQ0KICAgL0xlbmd0aCAxMDQwMQ0KICAgL0xlbmd0aDEgMTYwNjQNCj4+DQpz dHJlYW0NCnictXsJfBzFlXdVd09r7p7R3DOSekajuyWNpBnNaCTZ0zp9yEY+ZFuSLVuyJfnAxnJs DBgTmy8JdozDmmOxCXzA5iAJ4RjLB7IRWAGHX0JwMIaQDwKJIWAIGwUvh5cFe7SvqntkGci3++X7 bWu6+9XVXfXeq/97r6qFMEJIj3YiFvlXbegbwos/siFUzkHut1dt3eK/fuDmi5DejRBzbnBo9YZa pvczhCqHEOLrV6+/YVBoPrkW6j6CUFnnmoG+/tNn9usRikEaRddAhmmcc0H6HUjnrdmw5fr9s0zw /BotpPeu37iqDzEvvALpuyC9b0Pf9UPs6xnw7HgepP1D3xgYWl6+6lFINyOkuQExpLMZiEfQ2wxk f4JnOETO0Kk3T9FLZUXAGrDmwwVDrc93atAX5I6AIAdG3UwlcxtzDtpnyzrcyOyAPMSMTIwdMlpj TEgKh3pQaLyyAgeqA8xtl15gIkzlEajzNrxyRPMqMqIb5XzNUZ7XsQZ2BGtDCD8OxRqMdAat0cjU GfzYz+5kGXZk4m+HTSamDoiUbCBFrNFgoOlPDhuNPCVks8nE0wK4smaTNTMekujREx6X4lUh6M8m lLhUnwiTXgWgV9ZAdVU0FrYG2JFLJdic+uie23X3Yu0B9tzuJTd8/gxi0MKJtziD5kNkQEH0jOyI 4DpDC55t2GbV1DqqA7MdLQFONzJxXnabhRhrgYvjmI4JHGP1QsCCdsADRiZeoV0H4vxh0nMgXj1M Og/EWdp5SpC+A3FRLiX9R8gXeJAf4xneQhrzFtKSd5JmvJFU5Y2kJT8y8fZhUp8nXDdZY7w6Yqln PJwe/DhKjCfGgais6MEWJpjLWC2Z4apMHI1WRwoKCwqCuXwGzzvsTpfTGa6Kcoa/fHzhHDknULbb nZOztmPh1WKO0+bPvnrxwquZv6Q2pr6Lv4l34zvxtalvXjw6++3v3/N225z29qvmvH/HfWcWzl3Y TvVjA0IcpzmPCtA2OezNzXdJohSo10Rd8eAcTatrVrDD1R1Ymjvg6vVtcV3nu9G/I9dmt5uPexgm /zjW5sOYZNFgiRUUaAOJrPYsJstL2JDlzHdmsSEGjzGYapveRLStZ5MrHAopAwcpVyWAgBGDmKPR 2JVDzQhCXrjK6bDTFPwCHHdx7apkx8PbC3ODy2LVG6pKrnIbpr+56vRfi/Py19Quf6+FeeOl5Y/0 PPnW9dOXizk5Pru1wvqKWPfmU0vuSjTsnD74hkzH3DfxFvsBjFlGo/KQ01ygK3YUB6O6qszaYKSs urZF15w5O9hc1ly7SNft7A4uKl1WubB2la7XvEro96wNXqsbMm8SbghmO+zR6mO9NbimJmDIyEDH DUx+fvHxgD5apyXirwtYo3YrmxcKJHw7fYzPSRjjI7OBqAgQn8lUTXxan7Y3D+cRNhlMsTzgT5hw iahFpiseGpdCiDCKnGS+QG48TvTkCj6BXhBWOZxpiueDuQWF1WGqL5eZG6yGpELjiej6SMWMLGPD nwYG9k9rbPrBptDV5eW1LYmGkWuH3mgzJ15ZN+3G4qKSUEnJ5qZFjbt+VppbsEzT5HXYS20vB+PF UsXupTce95h1pZK0q2/gZw3NrdGCl8s7CktL182fvyYnx/XQzm01891eO/CdQUWga5LmJUBfE/qm nA2Dj/EZdhiCkc/QmY5hzHFsBstqEZdhpNwhDDP6MfJrsXZk4o90jgLxEZ2j2vTUBOLcE4SRWq2J D4WVOdUTrr8kxeuBcwlgWb3lUr01Ht+lKZe4mywnAe6C1iAACw5bwwEr5qSDY5euYb4/cjD1Tyk9 g1LQ2TPMxMUXmdZLxxUc3Q468zH0vQzdJ1eVaGu1UXvcM1vbZJ/t6dZ22Ls967TbtEa/P/tYURGf dzzA6vXW47w+GHQFEtCcwI+BQoxRxZdP0vjyyRMUTPL9/jSC+sngKYL6kb9Xh3VEM3SmmE7RDEka D6XhQ1UMGOKlKjKT8BWCd31J9qAw1oAD1FJVGPbjlumJJ7dc/eIcs2txpG7ltPpvFOcXSsXSTXPn /6iSrby0L681+xv3z5rdjl9fP9LUfFWo4GWrZHO4pIrSrfPaBwMFosfATDye2sJxBbGan8JAnwZm PYqzwd7ky3pmMRgMMBVlGDBQ1pNxbsQ7MINDPdJ4D/QdED5oDeNHP/wQmlAdWQRY7tOMo3xUi34t t+iyNEGXxZPlCMaLqiJVtbOKGiPNtV3MEsuC4IK8/mB/3pZIZjZfeszv5zOdTu/xTKbmGK93uIk+ OBwFAPCYgvnfh3fZQmE9O4SqAg8ax4yMkWCaE8yjkeK6keK6keI6FL0jG8g4jHTqGifxO1xVNSkU iYA5yINMVhDNFWIpYKojmbFoHhGAI6jIJC2OjK9Fet8cuemh/oEfJ+YumbdwPkY/rVoc0PkGa4+/ 65hxd9eSb81YMO83FdHCVZHWb8sMM61MWlp9/T/jP29+pqFlRnPTfCw89wyOb9m0Q284IXi++Peq aLB6+tO7l20v9dtLipzF4r1PV4YKHiEexuyJP3J2zcfIjLJRLRaPOmCQPBkz2G8gDGlCnyZ0xKKv IlSJtUJbYa7wVFXJWtksexqrunC3pkO7wtqducLV4enIXli8MNwT69cPuNYHegtWla6q6I+ujW/P 3Fq6uUIsdBirdZl8DvtEOeMbydEjf2VljaNIEgIRowUAVjG+TB0QZ6jgSM4RIoEannSG2l/id1ip 3Q1INZI78GDeWB6TR4VptsbyqDDz6PTLo8LMI8Knwsyjwsy7LExwPiSJInA8Pg7AYYUMaqEBj0Gc tBqOEFEpcnJFozYqvEIqORAbJrIuqI5EY9X0ployB8FmxEq3XLfh1hkzxB2RJdOzZq7O3TRjYecP b/zmgdT7G4/KiYabb7xmXerZ33x67TX/65bUv3Jb+2+5fnD2YLG13tr0vUublq2vsZXmxP5l9a7k /tQrjdPrf7zsht/U8/KBb/z07O8e6j8Z46c99t0TqRTFLcfEB8zDmvuRD43I+dmyxcLUYb/OEAOs 5KbrMzRutz2BdIls7EYGi8FvYA1pd81A2EPnrMGQrTcBe98HzCYOjYk6fiZvhsCLvJ9lebaAPJc4 focFQSVUV/Aj2SAIxOOjfh8UHKWu34EsyycKt6t66sHASZZ6K0G2nvoe4heEEvWX6olrgCQsaXIL qq1gtqxhCl7piRELO3gev/79R3bsGMXdqYd4u3VOQ/lim6F6g/Pxp5ir78MNqRP3XRpftKwoGPTp fiZYCb7UAo4f4q4HvzaK7zzIM00dnceQceKDtG/3gWKTETbpbeI0TLSHDtqCMcJw2AoS5Zy+wRbV 2vTVURFFyRQwkBpRIxlolHAtl4wxGq2JZXiMFgtf56FFHuoOepzk+Z6RiTco7ns8NbFJJ/iUSp0e s5wCw2UZp8jeA2AJBdY4YYfkO1ojU0AaoZ0GOaQJlCZKAecOOT2xcnLX6WMSjOIITAE8TSTjyTKa YqJoK28vwSUlZDjIDMOBMenpcD6TZ5HnR73VXiLMaurPVfPkwdUbazwWsyXmsYAGSTK5SBk+j5PU 8/jJnPLQ2p5MUtszFFOErLi5lgtwuSTV15OJZA2HieXqoQOGuVZZQaeU1IWtvAp/IGIXPwmbdCpF 82KXLdkUv8caZD5rOpVoW7l+Tde+hGtuXlVPR8v2UFl05brlGN1VlJe3JtaQ7DREnlmx+f7EtPon sQ1HeYfNtWJR78q5/dZpmd6sSKh8V9uWH1ZIAW1e43ynSyjMPyHk5YXK71h7iVN8gJ2gO3/jepAH V6U1B6mTxUPUIJNQbo1Rg7Uuxt6o0btAf87JBqICmCEqgJWZQQmlIZ6cZRj7vGaYdJ8rM8ZA9RDS zz+hzEGfV9WOU5P6MkbMfziRSIBDA5pxDPmIupK5qNPepL1Bt8XJjWiw+8oOfXaUiAh7EfGoSF2U nrdoqibJFmogN/rMdLabvdCVC7KHNDBQZTBwNPzjSTXDNV4qXhClInKQs9q3ehrSSF2BYPWkKGEm T85ia5j92+iS+3pn3VxRUT1qcrnaZ7fc1zC6fU57RSRy/ybmd5e+3XVtqVR0VZxtBBk0TrzLPaL5 KwqjX8hxLZdh1Va4Oa/TXiI580pqneGSVuvMUDfTzS3RL7FarrHtsDE2mzdiZHrLhsqYsrKCCNLb yqlDlUMmyAtyJmFveXm1UI2FarF6RTXrJ0KIEPb7HdfxmKeOO0/1m3dSU2MmIuXNRE6klKf5NMI7 S/GNH4yk8Y3YE6mnh6Ib5Umoh16AK5rL/oCqydQl+KoPAOUU7SCPefOOT7u6Vq5Y2vXJ/rZv1VQM VFq8C+rit3SueFhOtM6Wp/90+eI74rF5LqFyyfSGjb6VfX04d/RJ7Fzdv9ZpFcp8H7qbA2LRVXPm nNt3z5tzZreV+MUG119dJXaHk+BjHPwvkdsOsbQL+xQtl02OBKsVEjrOiDJ56kSR4QPx18OEAzRH hc/308HyGdmvxMhu3kKZZafMyqRscqtx8Vmq2jzvcU+qtFW9W04RCBwnLqJPjnhkCjEyEUGdOWKJ 2OucbeZmS7O9zUl7Bj3UG31IS/U5V1Xms2ll/lwOU7dPUelNHtGDM328k1TmKXjxXipW7xRBD7kV jQZHNU2o/cFg/7uwBQVzkdWCwlWITXsCxF0TU+ff/kvqU2x7621seeb+O+584IE7b3+AKU+dS53C 07AFu3E09ZvUe6+9/PJrZ177HeF53cQ5DgHPc8Da9ag8d0r1ZjPKn8Zzfjd2uz1WsNIe0URgg7CT gj7hqIr+lFDCISBeVRDFZCorlcwE0XNIVTNLJcE6qUGmkmBz1IUZxRixbFnppCTelMYuG6bn6Gwm qkt8WiITfxk1Q/lCmTcitAhdufdwD3MZ+W4wLp4KoxAD8X52RLDEYBzE6HgzbQAiyojU4aw2Yo9H 9BKfmuKQkYBlhLrcm8oSZVgyWxTkYamkWCoplkqKpZJiqaTYoVJVQAA6VFZkein9pd0l9kVSQEjj V0RGrYYjYP/S5LJNmXwZzIbUp6nXcM57ax6sr5cvfn7y0enXVYRbXYbAysJY1wHGnxNYPadtrVRS yntxGXZgK26ql+Vjtww++9ssp0uynTIVGgQL88s51xSUlJZJpVfPAPyCMId5hc9BbvSeKumA2wFx ccKBDObpVq3GqjFpdTpk1t5tQAISrAavmQCvlYjOnEflSP0IsxJCAkFFND5G1gws7xKRgeuQsFwa S4xDCBInsqrX2uN2ZvIt2iveIYhCSGDpq5QFPS8yW8x+M2umbIf3fE6tAyUI883EXlDJqBGPVE9U I2R5R305+G4JGo5iQLkurEQ5wG5w3oLEkVPcYRfzit6zPP+6ARxLvTi6Y8czRyL9xZpenfXqvQX3 XUywv7gv//kzhgyYHzvA+C7S/IGsgWJJ5ZpO08yzDBg2jqzHFRBGcEjDEC5p9IRLGo4ouIYnvNJw pFyDyNKBilifHaFAReyw7KIGWksNNG2FjappPvOEYpl12stTQZKeUxDqOYkwmk6Gqb0BbgHbCCEX EC5xD2gYkqOh9lLTiyiXkbcdJ/EYPo05TK2REIP7RToRiJdApixQDGE45qnF5oi2k760K0sCwwYh JvVMWUEdlz4hFjjdrS4SW8eA33jm6Kjp1Ve5niefpX5M3cR77G3cdagQG1VuRkOWhIWxCK6EkcvN 9gcqAkwgG6aokJtbXOTlMymCU9zgs640dyqCFxdd6cQmDW3EPcqd+KCmi3gpp3oy44nx+Kkewi1z nafSN9cj+7qYRXo+l8CD3mxl6nJl8C0DJKkzmGIWGS4CSXnAd7VYBJnUoV0MBHKV3pHSAl12DLq5 ohh7fWk0pwiuoLmC7ENFqitKDXF9Gh3CkroCC/DQpbnsZ0bT4bkCBwq0T5rg5s1jLS1z2hsbf7lp 2c+bDPZEWeG6yjsO/vzAsodkQ1ZHbsUcz4yZM/9w152vzprVHsl92Vrqsue8+fxzb86pf9mUrzML IIPdEHBfAMx3Yn/ayhos2kYbZ+ax1qS9QkPPUsjHyvy70nd8J+07ul0WY7qN0USDEmoetKptULxI k8ntUgU1Bd5PUY0B8VQR6dhYh9Ox1cFaTLQ7GmzSEq9RNqluo/MrPqO6ssWrSysfyFbFdXRb0ohi mvQdTVSjTbSuiSH1TNe4FPy+JFWpTtM4dKg+kVDWTogaX16+ApV2KOvC7IVRweFaMKP1n2eMjnb8 aOmPjzPb536nqKS4rf7i01zP9rZ5r/1W8dubJt5lr4aYL4oPqLzOqrR6i7hsFAjkT8/mOM4wHen8 Vro3Ya0kFpUwvJI674SLlbSkkhjWIGFjZWVNjC3ycqSWl8Z2XjohvBQ3vOlp4fVOje1OXmb3ySnr uS6K0NuUoK6Gejh6Nx/yuh2hgoziYDQjHpzNtIhdTJe7Q5wXWssMiANlq0I3MFvFb4vfDjo9do+r 2F7sqrPXuXi7y3VYKrdLUvm10q3SreWsVO6ycyh7XwBPHSrrJ/msn/dafZUUfZyxSkXPGDLMT6ho gfibTFdNKulGDoy6yOelEaTZEfNmkjpeGul5qYfszSS1vMpwx63qzKJL2JcXsHvIiHt2mcsl802W k2gTtcsSnXtfs2JZmF47Sa+Vqcst6RVufHToWVnvbohWbJ5eNugJirN68rZU7tzyzlM9o7J+5sHu np1zOkpWx7ffFI/V7/fV575sK/c4cx0WVyTS1OzSuc35916z/+ny4K/jjVe1t7Y4DQ6zuG/7zJvL qyLKemRj6nrNes15VIRq0Xm5viMwELg2wBYV5UVYQw6v0+l4h0fndHTpFjv4UMTB1ER0+hwbj1Ax TzSi2OHT8dmscIMP+4heqSv/imfqIx400RgfcYHoVgB4YrKd6I5vdb1QL9Yn6nfUc0I9riYzkIYk 1Y7rBCzQAESgAYhAmS9QX0ig4YlAQxIhi1QX0iGJMFinuknpkMRyTqGtrrhlHIBQXeICpI4n1NVk JWLLzQ1+OVLJdFiYjElxhdmpK5d040qzPnpd3U9e0pvcuv0fL168rGfx4o/vPvBJx6Llb5/UZLt8 c5uK1rt9L8u1dT9Zs/5fptclLrz44qepu8zm0cdWr1qFc58YxVmDq1av612Z+uPx1J9Su5tqurxi tkfPPnjXO21z57a1zzl3e+oPqV/hGjrH98JlJm8HH+EXyhw/zGCs/cctvoabavERCbF9spM+8+vs 91Gw3+0afKUJ9/09E67hNGn7PfmWHiIU+h5qt4nN5u0KfoGt4GvAVpTjsyp+uXMC+jxnRmOhszFQ yAW4LB5pBa1PCwHtxaNkJOXInCbNgjdNen0kRFMWJJBW5UuKwDdQJenITdmPQCGBcIr6nQLlkUDD Nsg9TWsIQshHrACp4KNVyQN9VO19jKrWL9CqPl9F6MsR3uVAT/1RG0QWvSyAHeFMCovVFRQWNUFN iSPoKCkIFpTExQx9XqEnJ8PZWAgD1yDBpy2jIikD26SapItf2mz5QKbYhPbr87zp9QyBeGgBIiyB NhOooMgg4ZrjpbW8Xp8ScdHJmpJLSUUfXf7w0Qo+uvzh248Ei+AX9glJQSMIFSF/xY4KhrpmPZ9I adumWDZrPP7JpI2rp85yOAwDVldJLps6uq71dZbPdXndS7PdaLPPTtR+ZwZmRyk57ZbE6Ojs25es uqdo0Q9WzNxaWlbJ3DL3W/lFBTOarCH/pYCamlNHjeTs+d2rV6wsqwof2HwpQHQtByHNGa4HGfEm RdeOsm69lS5EvX+YEFqiQQFKGViW1xg1Og2vYbQaLTIa+AwzkXeGdkpIaTKk7aHBYAK3eIIinR4I RfF0dKGLbuuphKKBWu2UzwOItpDT8qZ0yvKm6l0aJz6p6Tql6I1iSCW6Cqaf+IwCLZ3qW+n6FIY+ ZgBcG3zYwTsyXDqPoRSXMPlcgSZPKxkiuE7TjNs0S3CXZolhLRrE65h+bo2mX7tO16+/2rCd2cxd r9mq3abbor/BUIhYC1vIskYvMCzDy2t4rc6AGGAGr9FodXpgCyJm0qJzxBAyC2bRnDD3mjk+RL1P 6Cn02Ur6i3dZLsEP9ShrCjhIfmEbDmOb5kzq3cdSH6b+7dHU2yd/iXX3YstxrueLH7I9F3/I9Vx8 gO0jZxof2AsAFl/1JfHf9yU/+3/3Jfn/X18Sgy/JTPqSzP+oL1n/3/Ilrf8NX5K3XzqlOpMM+JJ/ 5nSaD5Ed/IHnZJmr1Nc4K701xfnTmGnaasNcpk3bYuhwdeZ31yyNX12zPr6NGcq1VfmEY9XVhfwx HyNJoeOF+qpMFLCAU5bemgyktyYD6a3JQHqHK1BClojzCVkSKNEFhhw7HQ86xhycgxp7BzX/Drqj 5ZjcnnTQTU2HalpIsCMpwfqlqiplg2X88uZk5HKYM+l/5U+GQWDr7cwVXxNkxtIruaxcU1naHb3x jopoQW9MviuG2UtsW8P0Q8tW/2Ta3EUL5y/+t4NF3YV6z7rYybPCvNsXLdzdMm8Bu+HAiUhFXvIn y7eVio6yfKHy/s1PtzTObmlYkLrwm2OpIxu2bNMZT5i9mDkfrcqLTHuS2EENGpz4c8ZazTgiCyM+ VIjC6Li8W6fl9To37xWq3VqX3u12eYu1Bfpid4G31TRTkKsXmzqFtWabAChTYxbsZrNwg7g1/wZp ayWXPxpi21mGZcVRHSOwZq006vfIHsbjqRy16fOMkpkxmstLQEudjNNZVGI084JFhjg5q0RAIihD bokFWXg/X8GzMLfD4fFQD/zAfyKO7nhIWYUCikwIcofol3yCsOumk5hsCQMPFe82n0z8KWk8ZUFx Ks0WHvn5Y4eO/vyxYeb7Fz/5MWtk5qYzvjDOWL16ZvPVq2dwjZNU5K3X3njz7OtvjH0e0rz0xQtq Ch8/cN/9++++//4UUgkYyu6Jt7hKwBAjysbTVBTJ5N1so49zYoc2w6aXLXpkSi/+mog5UNcfX08v O55PL0SeUZTQZBJz3Bk2MMcUSmyOSShx0LDUkYYSh0PMuQwlU5Yd0/sb48Q+TkV9n1wh0jVhkUZM tThsjJrbcKOxxbw4azDr2gzdV/pOcMdGYcVnogbfROeMKf09CV039VNE2SRCtync2LwOauEdFGoc 1+QQeCGbWJZJIz6lhzSUUQSWYVVmElkmLijMSENNJrtx2665/1uecU3jvh89k7rwq6U3J4zJ0RkP rX3qdabqVy/OjF3aGcx+4V9Tf0sNlxVEAHpekTtSLymxSN3EW+w7ICMPKsBFqozs3jxG63LZ3Sin 0c5hbV6jlgz1gmyniO/yYrroi3l1+2nKrlOugvZFhQEzrWOmS/Rm2tBM41lz2oqbzUWFX9mlBEmd op860P28KhhhmGB+SZEiEnaaP5JbW9Dub869ISvDy2h9tJcN6V5C1yZFgr2Ixi9Ir+L+3+Q8agc2 FgV8ZiotM61g9irOG12HHCpUN52u2FpUdhcve1Rk3+nKXUQKa9Ywa52yuMO+M1oqS0WL40vvjcbq 5zRNe3RFx/aW0dHWjQ23/+ibt86++xv5FXabY86s2a99787fz5u1ML8Qv/P5Rebbud7XTv3ypSYa K068pVkNsaILFaNfgo+k0zi8OoejW7fIwedAbFgIsaGbGlG343oWs+mAkE0HhGw6IKSEumOuBoTs akmQRCkh7ZA4QSJfi6kBYR4NCCcDv8lQcGqIaKf+u1P139MBYcmXA8ILaVoJBME/mQr+UwJA21fi Pe7wouXLliz9+I79Hy2ZjPbiV4Z3mgISzB1JvbFqzarBgSlB3qWVV8R0v8Yx6tfsJ36N5iVA/kVH GZarpvHc2CG9NQb3pxVvBaEMzo7THxxQj0/ZbzWo7s2v6GBxP6/qCl2XIOMjX5eSTwrYCxf/5Tnm Hs1Ln/8J3jl34l2ukewv4jlya8hUbJekOBM3RbOqC2czLfrZxpasWXnNhd3MYn2X0O1elLU8b4Bf Z1vvGHQPZA0W9ZauqdialbXNvKWIKZKsZg55c4gr6CCdEHNCOTty2Jyc3IiX2aTBJAiUAzpDTCPT 9WmNNoL0tFW5KydH3QB2lNP1UZ09Vk5XYcrTH6uWpyG4nHw3RoO+kYlzVGuAOC0Lk/ua7dUMx+UT 1lSQ0nzHg66ki3HR3TAXDZFcRvJEF1UWFw2FXfTtLlA/usngUr8YdoWmaExY8Wcl1c9SVrOoyYNi avEkutqjbnWqnyJOruzQ6Zj39xd3mOgP/txvXvnZ5h/9tLO35RuL524LlYex9w83/WmFMOOP2/Y8 3L8icbT++7fNkGce8TVVfrZs4LtDXUM+u9dpn15V+Z0lRz6tKh9v6Lt57Yohr1XKDD1965KH6xpa 6YfRMFtZereT76HhiCAO+eHOwR/knM+dmIArmpiwILUGj+bRe5DqJmnPgWbyKANpkQ7pwSsxIhMy g29iQVaUiWzwbAdyAhq4AbG94LFkoWyIr0R4TwDl8jm8XXNe8xK3nethz0AbNPHexFup61P9qS72 XvBuELobPYyOoefQb1H6GEXP0PtWNIzG0G/Q1ONmdBd6CL2AXkcfTuYdQPejn6MkUPuBugkP4u1o H839EfoZegwdQsfRs+i/Ol5WPs6D41nGjpUe/AUZmZfwZnwbPHk/aoS/56a02I12ojj8/QMHnmBm sQmmm3mB+S6zkYkpucw2GN0Ye4b9CZoDf2PoVfKl4VeOm/F/4P9AW9C7wLfn8T8zz6FH0E/Qd6A/ t8OofwypjWgX+id0L3rwy035PRor99EVWSPoUXQLWob+AJw+CS1uQQsR4eTtcL0JJO5FoqZXrfsw +sE/Mtr/iYNbzhwBbt3FnGIbmVEmyYYYjh3Ft4O+fc5yqBf+uqD/c4APg6gN+PEQ+ilo1k208V7Q rGF0G+gHOTbB3/fRZ+hbzMNQ/1p0LXsfWwllo2gaWolvBEDeBVI+iu9Hb6Nu+BtCj6O38bPAfWjJ jaI1CMnTOupq4zUxmPdhiAlD5WWlUklxUWFBfl4wN+AXc7KzfF6P2wWT3pZptQhmk9Gg12kzeA3H MhiV4qS7qfOgJ0PyBQKBrjI17b0ynWTzLR8Fkijzikq+LzXK+lI6+0vpnMn0VUlkT7YGm5rJgw+i 1nNJZEtiexKRt2DbXHiT2qilf12wZW3S09Tf2wstmoMWf7L1fEjtCn32QYO+Kdg0oC8rRQf1BiAN QEHdoYO4dTqmBNPaUnuQQVpTWWkyU0oy+S3kXJeUb+0FItgMT4IS2+USgOO9U4sQNEtTNoXCSb4p mUHf61+blPuS6Fb/wdKxPXtHLGhlr2TsD/b3LQPO9UEfDyI2v2VNB+FjCzl71/iTHDycXnyQ429Z 498TJOxoWdML12AztPrafMjWNXXuCoz5kplwb0lapeQMqDFj2zs+dk+Le62fJPfs2eVPPji/c2pp gFy7urrc0OE9LUF4IDysZV0jDMUdKitVxqQyoL93HXnnuj7Sz5Z1/j23DtC+7qV9oFVb1oBg+v6r Wnv2tPQHW/r7+huVpzcl5Q56Qx3dnXSAwLrmLjVLrQAlHC3pbe4KKMxuW9DZRDoW7Gv2KWKfzOlV cyCjJV3oJz2YBQ9I+lf5k2hBZxCq1pDLQA3as6qGKk+gC0OreZdbJTX5lqB/z6coiXuD43+9MqdP zeHzLZ8iQrYGW3v37GkN+lv39O7pG5nYuTLotwT3HGxr2zPU0gtvndcJrUYmjt/qS7bu7Upaetfg WuA90YDWBZ0JX8DalU7OSycRqBQoloEOB7gAv1nqDbiMOjoDfmDUos4uH/Cpk9AdQCt3okiguDUg Y5VthEcDNZPsaVLJQIBo560jMloJieTO+Z1K2o9W+oaRHJJAHr2kZCxd4lhESnamSyab9wbhLYep BXcktQWTP8HitLWsqU1i5/+leEApT9qaOlkf06VQjI8llF6CmV6fdElAF0l7QAing0mLlNR0jvnq u/wWKyAAkd7CYNv87k5/y55JLVBy1JESPQBVD/at2aNOJaL0X5/btjDNcKKxMKVvBY7vXLkOlAZ+ fXsJ/AT2WJKtFwK+wB5rMNMfD5Gukjhx6lvTwASA03gwiHfPPyjj3Qu7O4+BD+Lf3dE5zGCmqbex 62AelHUe8wOG01yG5JJMkvCTBGojWj7MaGl93zEZoZ20lKMZNL1qBCOap03nYbRqhFHyLOk8BvI4 JU+meeQoo4Jhg79fVbX2uRVC/afIp6Vm6bGx41nkPvrvG7Z9EUl16o9oiVung8covhpctTjVhZDB /0Xk8236I2r+5SOoJU7c+6ibW47ehnMhs5NYTrQBzj44i+DczqxHT8N9EZyzmUeRgwujWm4r2sn9 FjVynSjORVEdsxdl41fQDvYgqoOy3ewdqEnzM9QIeXv5EbQb4sEckg/PaMo4jQa59UCvR3WkDvsF 2s9di+aqfQJ2oeuh83ng7/QqJ9sBvXoBIQ3ZAwI/jj8PI1uPkB7qGsAfNe1FSAC5WYYQsr6DkO00 aDKHkBPauf4PQp5mhHwwsuwiBN0g/2KIUC48P7gPoXwjQgVgoYvgXvwIQiUXEZKGyP81Um4FwRew oH7wbhm4y2gR9CbK14PfyxzskEfwxkNFZVFyH3b5oiN40yG2NrCvwYs3QesKuM6DcwjOB+A8Aeef 4OSRANcEnCvg3AEnNzGGFw5nZUePAbFqONNGiauGwxGVyCuAh191qN4pCk/hpehDOBkk4+5DHi95 e/chh4Pehy0W2qLrkE5PMobU7g2R7pGCnmGHQqwctjtUQn3vgjSxejgUVQlzASUGh3UmSvSliYHh cFQlikpUItsPnRwY9npEpWr7fLXN9IRKeJQX9B2y0e72HTKYyH3FcFEVLWgfXtytEIfiddGKBidu h1G2AxfbgeNDcN0JJwPa0Y8scDLoNFzPEgr3Dw/10xe3DtvsUYVwOlUCuEGIxmErYe1JIPRmmjN9 2OWmxLRhAxC4AodkQ5X43vv94vtnKkT/KI6DHOPw/Pgw6xYb9LgOV4EmiDgGdxPcq3HVsF0MNRgh jXEUhyH6EXEE7na4V+LwsEWUj+MatA/XyCFG+HPoz4z8em5e9KXfJ8RXf+8Vd/4O/w5u4u/x0O/x 878uEZ//dbzmeWz4VfOvyD8NHn1DZ422n6Ef4ecMF1dFLcP+YXl43vDQ8M7hB4eTw6eHzw7rx4bP D5Pa8o1HYEBiMxYWi4uZ9kUrFjE1J0rEjSfwAyceP8HEjjnE0JN49GmX+NTTTvHppxzi8WMLxKPH isUnjlWJI3Aeq46L9YkqcVpimjg9ERCbEtliY2KB2ACnDGeiukqsCveL4eqIWB3pECPVOeLpyNnI +Qj559dDh/Nnkq//Dx22BKNkBct8WCdED3tniqevwWc30VHoDhDl3ATDGpn4hawbygRl2AgaQb+Q vEaXGR26B8urodnQ4M7BBweTg9zjAycG6Oj+2A+tNt65405m4z48dBvesfeBvczOBzFaOW/l2EpW 7hvqYyxL/Uv3LWXX2GeKh+Ass1vFUnu+KNnjYondJv6p6MMi5sUicmOL7Bbxfn+TKNpzRDDZot9e Lz7gXSB6fTNEn7de9NqrRAe0s9kbxEy7V7TCOWTHsr2hKYp4LGD4hXACk//nehyfwC/iD/EE1gsI CyiEEhBn7YBY4AR6EaLRCaTX62KiwAgs8yLzIjvBTLCc0RTXcHGWiWMUn6fBI9A6mdmG2joakzYM 94WNB3VVUluyf0Hjd773vezk3cTf2JndNaKFOuC4JPFtXUktsYmURGQNYvMW+G3ekmRbknzLmr4k H2zeTBJmkjCDm2luSQqEFoLNOGlvWZO0B5ulzdLUA56h3NVDIr8pJeha6WuOLfTd9P0S3iIhaERz 6IPIRUpfJl+z5WsfpJbS4UiAqi1r4ALDUGoDLP8n4eKWww0KZW5kc3RyZWFtDQplbmRvYmoNCjYg MCBvYmoNCjw8IC9MZW5ndGggNyAwIFINCj4+DQpzdHJlYW0NCi9DSURJbml0IC9Qcm9jU2V0IGZp bmRyZXNvdXJjZSBiZWdpbg0KMTIgZGljdCBiZWdpbg0KYmVnaW5jbWFwDQovQ0lEU3lzdGVtSW5m bw0KPDwgL1JlZ2lzdHJ5IChBZG9iZSkNCiAgIC9PcmRlcmluZyAoVUNTKQ0KICAgL1N1cHBsZW1l bnQgMA0KPj4gZGVmDQovQ01hcE5hbWUgL0Fkb2JlLUlkZW50aXR5LVVDUyBkZWYNCi9DTWFwVHlw ZSAyIGRlZg0KMSBiZWdpbmNvZGVzcGFjZXJhbmdlDQo8MDAwMD4gPGZmZmY+DQplbmRjb2Rlc3Bh Y2VyYW5nZQ0KMzQgYmVnaW5iZmNoYXINCjwwMDAxPiA8MDAyZD4NCjwwMDAyPiA8MDAzMT4NCjww MDAzPiA8MDAzMD4NCjwwMDA0PiA8MDAyMD4NCjwwMDA1PiA8MDAzMj4NCjwwMDA2PiA8MDAzMz4N CjwwMDA3PiA8MDAzND4NCjwwMDA4PiA8MDAzNT4NCjwwMDA5PiA8MDAyZT4NCjwwMDBhPiA8MDAz Nj4NCjwwMDBiPiA8MDAzOD4NCjwwMDBjPiA8MDA3ND4NCjwwMDBkPiA8MDA2MT4NCjwwMDBlPiA8 MDA3NT4NCjwwMDBmPiA8MDA0Mz4NCjwwMDEwPiA8MDA2Zj4NCjwwMDExPiA8MDA2NT4NCjwwMDEy PiA8MDA2Nj4NCjwwMDEzPiA8MDA2OT4NCjwwMDE0PiA8MDA2Mz4NCjwwMDE1PiA8MDA2ZT4NCjww MDE2PiA8MDA3Mz4NCjwwMDE3PiA8MDA1MT4NCjwwMDE4PiA8MDA2Yz4NCjwwMDE5PiA8MDA2ZD4N CjwwMDFhPiA8MDA3Nz4NCjwwMDFiPiA8MDA2OD4NCjwwMDFjPiA8MDAzOT4NCjwwMDFkPiA8MDAy NT4NCjwwMDFlPiA8MDA2Mj4NCjwwMDFmPiA8MDA2ND4NCjwwMDIwPiA8MDA0Zj4NCjwwMDIxPiA8 MDA0Yz4NCjwwMDIyPiA8MDA1Mz4NCmVuZGJmY2hhcg0KZW5kY21hcA0KQ01hcE5hbWUgY3VycmVu dGRpY3QgL0NNYXAgZGVmaW5lcmVzb3VyY2UgcG9wDQplbmQNCmVuZA0KZW5kc3RyZWFtDQplbmRv YmoNCjcgMCBvYmoNCiAgIDg2MA0KZW5kb2JqDQo4IDAgb2JqDQo8PCAvVHlwZSAvRm9udERlc2Ny aXB0b3INCiAgIC9Gb250TmFtZSAvVGFob21hDQogICAvRmxhZ3MgNA0KICAgL0ZvbnRCQm94IFsg LTU5OSAtMjA3IDEzMzggMTAzNCBdDQogICAvSXRhbGljQW5nbGUgMA0KICAgL0FzY2VudCAxMDAw DQogICAvRGVzY2VudCAtMjA2DQogICAvQ2FwSGVpZ2h0IDEwMzQNCiAgIC9TdGVtViA4MA0KICAg L1N0ZW1IIDgwDQogICAvRm9udEZpbGUyIDUgMCBSDQo+Pg0KZW5kb2JqDQo5IDAgb2JqDQo8PCAv VHlwZSAvRm9udA0KICAgL1N1YnR5cGUgL0NJREZvbnRUeXBlMg0KICAgL0Jhc2VGb250IC9UYWhv bWENCiAgIC9DSURTeXN0ZW1JbmZvDQogICA8PCAvUmVnaXN0cnkgKEFkb2JlKQ0KICAgICAgL09y ZGVyaW5nIChJZGVudGl0eSkNCiAgICAgIC9TdXBwbGVtZW50IDANCiAgID4+DQogICAvRm9udERl c2NyaXB0b3IgOCAwIFINCiAgIC9XIFswIFsgMTAwMCAzNjMgNTQ1IDU0NSAzMTIgNTQ1IDU0NSA1 NDUgNTQ1IDMwMiA1NDUgNTQ1IDMzNCA1MjQgNTU3IDYwMCA1NDIgNTI2IDMxOCAyMjggNDYxIDU1 NyA0NDYgNzA3IDIyOCA4MzkgNzQyIDU1NyA1NDUgOTc2IDU1MiA1NTIgNzA3IDQ5NyA1NTcgXV0N Cj4+DQplbmRvYmoNCjEwIDAgb2JqDQo8PCAvVHlwZSAvRm9udA0KICAgL1N1YnR5cGUgL1R5cGUw DQogICAvQmFzZUZvbnQgL1RhaG9tYQ0KICAgL0VuY29kaW5nIC9JZGVudGl0eS1IDQogICAvRGVz Y2VuZGFudEZvbnRzIFsgOSAwIFJdDQogICAvVG9Vbmljb2RlIDYgMCBSDQo+Pg0KZW5kb2JqDQox IDAgb2JqDQo8PCAvVHlwZSAvUGFnZXMNCiAgIC9LaWRzIFsgNCAwIFIgXQ0KICAgL0NvdW50IDEN CiAgIC9SZXNvdXJjZXMgPDwNCiAgICAgIC9FeHRHU3RhdGUgPDwNCiAgICAgICAgIC9hMCA8PCAv Q0EgMSAvY2EgMSA+Pg0KICAgICAgPj4NCiAgICAgIC9Gb250IDw8DQogICAgICAgICAvQ2Fpcm9G b250LTAtMCAxMCAwIFINCiAgICAgID4+DQogICA+Pg0KPj4NCmVuZG9iag0KMTEgMCBvYmoNCjw8 IC9DcmVhdG9yIChjYWlybyAxLjQuMTQgKGh0dHA6Ly9jYWlyb2dyYXBoaWNzLm9yZykpDQogICAv UHJvZHVjZXIgKGNhaXJvIDEuNC4xNCAoaHR0cDovL2NhaXJvZ3JhcGhpY3Mub3JnKSkNCj4+DQpl bmRvYmoNCjEyIDAgb2JqDQo8PCAvVHlwZSAvQ2F0YWxvZw0KICAgL1BhZ2VzIDEgMCBSDQo+Pg0K ZW5kb2JqDQp4cmVmDQowIDEzDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMTg3NTIgMDAwMDAg bg0KMDAwMDAwMDAxNyAwMDAwMCBuDQowMDAwMDA2MzE0IDAwMDAwIG4NCjAwMDAwMDYzNDAgMDAw MDAgbg0KMDAwMDAwNjUzNiAwMDAwMCBuDQowMDAwMDE3MDQxIDAwMDAwIG4NCjAwMDAwMTc5NTkg MDAwMDAgbg0KMDAwMDAxNzk4NCAwMDAwMCBuDQowMDAwMDE4MjI3IDAwMDAwIG4NCjAwMDAwMTg1 OTUgMDAwMDAgbg0KMDAwMDAxODk2OSAwMDAwMCBuDQowMDAwMDE5MTAyIDAwMDAwIG4NCnRyYWls ZXINCjw8IC9TaXplIDEzDQogICAvUm9vdCAxMiAwIFINCiAgIC9JbmZvIDExIDAgUg0KPj4NCnN0 YXJ0eHJlZg0KMTkxNjANCiUlRU9GDQo= --===============0598698127302432434==-- From cottrell@wfu.edu Thu May 15 10:16:46 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Bug in the new quantile regression function Date: Thu, 15 May 2008 10:16:34 -0400 Message-ID: In-Reply-To: OFF7621856.546E3E51-ONC125744A.0028B298-C125744A.0029A1C3@ltv.se MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4666651943539846276==" --===============4666651943539846276== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 15 May 2008, andreas.rosenblad(a)ltv.se wrote: > First, thanks for the new quantile regression function in gretl. > It looks great. Glad you like it! > However, I found a bug (using the Windows snapshot from 2008-05-14): > > 1. Using the GUI, open the Ramanathan data file "data 4-1". > 2. Choose Model > Robust estimation > Quantile regression... > 3. Set price as dependent and srft, bedrms, baths as independent > 4. Set 0.25 0.50 0.75 as desired quantiles > 5. Press OK: The program freezes Thanks for the report. The freeze is happening inside the Fortran routine rqbr. I'll try to figure out what's going on. Allin. --===============4666651943539846276==-- From cottrell@wfu.edu Thu May 15 10:39:11 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Bug in the new quantile regression function Date: Thu, 15 May 2008 10:39:04 -0400 Message-ID: In-Reply-To: OFF7621856.546E3E51-ONC125744A.0028B298-C125744A.0029A1C3@ltv.se MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5460173643533256441==" --===============5460173643533256441== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 15 May 2008, andreas.rosenblad(a)ltv.se wrote: > 1. Using the GUI, open the Ramanathan data file "data 4-1". > 2. Choose Model > Robust estimation > Quantile regression... > 3. Set price as dependent and srft, bedrms, baths as independent > 4. Set 0.25 0.50 0.75 as desired quantiles > 5. Press OK: The program freezes Well, we're replicating R OK -- it goes into an infinite loop on this problem too! Allin. --===============5460173643533256441==-- From cottrell@wfu.edu Thu May 15 12:01:12 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Another quantile regression bug Date: Thu, 15 May 2008 12:00:54 -0400 Message-ID: In-Reply-To: OFE2D55D31.0F8B28D9-ONC125744A.00309AC2-C125744A.00320133@ltv.se MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6982062710717879852==" --===============6982062710717879852== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 15 May 2008, andreas.rosenblad(a)ltv.se wrote: > I have found another bug for the quantile regression function > (again using the Windows snapshot from 2008-05-14): > > 1. Using the GUI, open the Ramanathan data file "data 4-1". > 2. Choose Model > Robust estimation > Quantile regression... > 3. Set price as dependent and srft, bedrms, baths as independent > 4. .1 .2 .3 .4 .5 .6 .7 .8 .9 as desired quantiles > > Output... > > VARIABLE TAU COEFFICIENT LOWER UPPER > > const 0.1 1.13915 -1.#IND0 -1.#IND0 > 0.2 -0.856990 -1.#IND0 296.952 Hmm, for tau = .10, R reports the confidence intervals as (-1.797693e+308, 1.797693e+308) for all coefficients. There is a certain lack of error checking in the underlying Fortran code. I think this is now fixed in CVS and a new snapshot. Thanks for testing! Allin. --===============6982062710717879852==-- From svetosch@gmx.net Tue May 20 10:56:53 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: [Gretl-devel] translation time? Date: Tue, 20 May 2008 16:56:50 +0200 Message-ID: <20080520145650.149270@gmx.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8829808345721762650==" --===============8829808345721762650== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I know I can update the (German) translation anytime, but I was still wondering whether any kind of deadline is approaching. I would like to catch up before the release of 1.7.5, but of course I would like to do it rather later than sooner (standard time discounting ;-) cheers, sven --===============8829808345721762650==-- From cottrell@wfu.edu Tue May 20 11:02:11 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] translation time? Date: Tue, 20 May 2008 11:02:02 -0400 Message-ID: In-Reply-To: 20080520145650.149270@gmx.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2243513158913628364==" --===============2243513158913628364== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 20 May 2008, Sven Schreiber wrote: > I know I can update the (German) translation anytime, but I was > still wondering whether any kind of deadline is approaching. I > would like to catch up before the release of 1.7.5, but of > course I would like to do it rather later than sooner (standard > time discounting ;-) Good point. I'm thinking that we've now accumulated enough bug fixes that we really should release soon. There are a couple of small things that need attention in relation to the translatable strings. I'll try to fix those today, and will commit a new gretl.pot before long. Allin. --===============2243513158913628364==-- From svetosch@gmx.net Thu May 22 04:55:20 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: [Gretl-devel] omit bug Date: Thu, 22 May 2008 10:55:16 +0200 Message-ID: <483534F4.2080600@gmx.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8429036882311736335==" --===============8429036882311736335== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi, there seems to be a new bug introduced after 1.7.4; as always, I can provide more details later and/or file a bug report, but maybe this is already enough, and before I forget about it, here goes: In a script of ours, we have an "omit" test statement after a standard (OLS) estimation, but in between there are some other calculations ("scalar" and "matrix", so effectively "genr" I guess). This worked fine up to 1.7.4, but current snapshots complain at the "omit" line, saying that no estimate has been performed so far. cheers, sven --===============8429036882311736335==-- From svetosch@gmx.net Thu May 22 05:01:09 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] kalman filter status? Date: Thu, 22 May 2008 11:01:06 +0200 Message-ID: <48353652.1060705@gmx.net> In-Reply-To: alpine.DEB.1.10.0805101120470.27173@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6379550867776550881==" --===============6379550867776550881== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Am 10.05.2008 11:25, Riccardo (Jack) Lucchetti schrieb: > On Fri, 9 May 2008, Allin Cottrell wrote: > >> >> Jack produced some useful working notes on this back in February. >> I'm taking the liberty of attaching his TeX source; comments are >> welcome. > > I'm attaching a revised version, which contains a quite cool idea (If I > may say so myself) I had some time ago, that is using the KF as a > simulation tool too. Comments very welcome. > With some delay I have now read it, and I have nothing much to add. I like the idea about the user-defined function to specify the time-varying parameters. It could be that there is some room for minor syntactical improvements, but I guess that is better discussed after the prototype implementations are done. With respect to simulation, if it's not difficult to implement, then it certainly would be nice. Whether it's terribly important or useful I can't say. cheers, sven --===============6379550867776550881==-- From cottrell@wfu.edu Thu May 22 09:07:04 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] omit bug Date: Thu, 22 May 2008 09:06:57 -0400 Message-ID: In-Reply-To: 483534F4.2080600@gmx.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0075113891165241170==" --===============0075113891165241170== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 22 May 2008, Sven Schreiber wrote: > there seems to be a new bug introduced after 1.7.4; as always, I > can provide more details later and/or file a bug report, but > maybe this is already enough, and before I forget about it, here > goes: > > In a script of ours, we have an "omit" test statement after a > standard (OLS) estimation, but in between there are some other > calculations ("scalar" and "matrix", so effectively "genr" I > guess). Please send a test case, I can't replicate this. For example, the following works fine: Allin. --===============0075113891165241170==-- From r.lucchetti@univpm.it Fri May 23 08:36:53 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: [Gretl-devel] R and odbc Date: Fri, 23 May 2008 14:36:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9143488602511845030==" --===============9143488602511845030== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Folks, Allin and I have been working recently on documenting a bit more properly a few things that have been in CVS for a few weeks without being too much publicised: ODBC and gretl <-> R interaction. If you compile the version of the manual you find in CVS, you'll find two new chapters on these topics. Comments are appreciated. If you could try the new features out, that would be even more appreciated (obviously, you'll need to build from CVS or use the win snapshot). I realise odbc is not everyone's cup of tea, but I expect that quite a few of us have R at least installed. Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti --===============9143488602511845030==-- From svetosch@gmx.net Fri May 23 08:39:12 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: [Gretl-devel] gtksourceview dev Date: Fri, 23 May 2008 14:39:08 +0200 Message-ID: <4836BAEC.3000306@gmx.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2975438714408918352==" --===============2975438714408918352== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I am just building gretl cvs for the first time on Ubuntu 8.04 and have noticed that the configure stage went fine although apparently libgtksourceview-dev or somesuch was missing (got make error later). After installing that package, everything is ok. -sven --===============2975438714408918352==-- From svetosch@gmx.net Fri May 23 08:57:49 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] omit bug Date: Fri, 23 May 2008 14:57:46 +0200 Message-ID: <4836BF4A.5050903@gmx.net> In-Reply-To: alpine.LRH.1.10.0805220903550.435@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4364043497293895667==" --===============4364043497293895667== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Am 22.05.2008 15:06, Allin Cottrell schrieb: > On Thu, 22 May 2008, Sven Schreiber wrote: > >> there seems to be a new bug introduced after 1.7.4; as always, I >> can provide more details later and/or file a bug report, but >> maybe this is already enough, and before I forget about it, here >> goes: >> >> In a script of ours, we have an "omit" test statement after a >> standard (OLS) estimation, but in between there are some other >> calculations ("scalar" and "matrix", so effectively "genr" I >> guess). > > Please send a test case, I can't replicate this. For example, the > following works fine: Ok, it seems to be related to calling a user-defined function after estimation and before the restriction test; here is a demo script: This gives the mentioned error on today's CVS. I can't guarantee right now that this demo script works with 1.7.4, but our real-world script (where we noticed the bug) did. In this case there is obviously an easy workaround (move the function call after the omit), but I can imagine cases where you want to use 'restrict' with some value that you need to calculate in a function beforehand. So I'm inclined to think it's a bug. thanks, sven --===============4364043497293895667==-- From ignacio.diaz-emparanza@ehu.es Fri May 23 10:20:53 2008 From: Ignacio Diaz-Emparanza To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] R and odbc Date: Fri, 23 May 2008 16:20:49 +0200 Message-ID: <200805231620.50109.ignacio.diaz-emparanza@ehu.es> In-Reply-To: alpine.DEB.1.10.0805231430350.15136@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2751514036873010240==" --===============2751514036873010240== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable El Friday 23 May 2008 14:36:50 Riccardo (Jack) Lucchetti escribi=C3=B3: > Folks, > > Allin and I have been working recently on documenting a bit more properly > a few things that have been in CVS for a few weeks without being too much > publicised: ODBC and gretl <-> R interaction. > > If you compile the version of the manual you find in CVS, you'll find two > new chapters on these topics. Comments are appreciated. If you could try > the new features out, that would be even more appreciated (obviously, > you'll need to build from CVS or use the win snapshot). I realise odbc is > not everyone's cup of tea, but I expect that quite a few of us have R at > least installed. The improvements about R are quite interesting. Do you plan to allow these at the command line as well? I mean, I think we need a command block=20 R_script ... (R commands) end R such that when gretl processes the R_script, the dataset is transfered in the= =20 same way as we do it through the GUI (tools/start GNU R or through the new R = script capabilities), and the commands inside the block are passed to R. --=20 Ignacio Diaz-Emparanza =20 DEPARTAMENTO DE ECONOM=C3=8DA APLICADA III (ECONOMETR=C3=8DA Y ESTAD=C3=8DSTI= CA) =20 UPV/EHU Avda. Lehendakari Aguirre, 83 | 48015 BILBAO T.: +34 946013732 | F.: +34 946013754 www.et.bs.ehu.es=20 -- Para leer y escribir documentos en formato "open document" (.ods, .odt, .odb, odp) utilice OpenOffice.org o tambi=C3=A9n=20 MS Office, instalando el "plugin": http://www.sun.com/software/star/odf_plugin --===============2751514036873010240==-- From cottrell@wfu.edu Fri May 23 12:45:26 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] gtksourceview dev Date: Fri, 23 May 2008 12:45:18 -0400 Message-ID: In-Reply-To: 4836BAEC.3000306@gmx.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9108221076471124149==" --===============9108221076471124149== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 23 May 2008, Sven Schreiber wrote: > I am just building gretl cvs for the first time on Ubuntu 8.04 > and have noticed that the configure stage went fine although > apparently libgtksourceview-dev or somesuch was missing (got > make error later). > > After installing that package, everything is ok. We're not using an installed copy of gtkourceview any more, but strictly the slimmed-down version that comes bundled with the gretl sources. However, there was one residual issue with the gtksourceview build, depending on the version of the glibc regex.h header; I think this is now fixed in CVS. Allin. --===============9108221076471124149==-- From cottrell@wfu.edu Fri May 23 14:50:10 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] omit bug Date: Fri, 23 May 2008 14:50:01 -0400 Message-ID: In-Reply-To: 4836BF4A.5050903@gmx.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5702107795933779660==" --===============5702107795933779660== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 23 May 2008, Sven Schreiber wrote: > Am 22.05.2008 15:06, Allin Cottrell schrieb: > > On Thu, 22 May 2008, Sven Schreiber wrote: > > > > > In a script of ours, we have an "omit" test statement after > > > a standard (OLS) estimation, but in between there are some > > > other calculations ("scalar" and "matrix", so effectively > > > "genr" I guess). > > Ok, it seems to be related to calling a user-defined function > after estimation and before the restriction test; here is a demo > script: > > Thanks, I now see (and remember!) what's happening. As you know, "omit" works on the "last model". Sometime after the 1.7.4 release I noticed that we had a problem with functions: if a function estimated a model, this would remain the "last model" on exit from the function, which is not what we want. I then "fixed" this by simply NULLing out the last model on exit from a function, with the results you found. I've now implemented the right fix, namely, when we enter a function we save a pointer to the current "last model" and on exit from a function we restore that pointer. Should be OK in CVS and Windows snapshot. Allin. --===============5702107795933779660==-- From svetosch@gmx.net Fri May 23 16:27:37 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] omit bug Date: Fri, 23 May 2008 22:27:33 +0200 Message-ID: <483728B5.9010201@gmx.net> In-Reply-To: alpine.LRH.1.10.0805231421450.2802@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1686508718255524980==" --===============1686508718255524980== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Am 23.05.2008 20:50, Allin Cottrell schrieb: > > I've now implemented the right fix, namely, when we enter a > function we save a pointer to the current "last model" and on exit > from a function we restore that pointer. > > Should be OK in CVS and Windows snapshot. > Yes it looks like it, thanks. However, another new problem just appeared, the context is as follows: First we do IV estimation: tsls rpivstand endorhs d_predrhs ; d_predrhs d1_wox --robust Then we do various stuff: >accessing $coeff, $vcv> and then we access the hausman test result and calculate a p-value by assuming one d.o.f. less than usual (don't ask why right now): matrix hausmanresult = $hausman pvalue X hausmanresult[1,2]-1 hausmanresult[1,1] -- and this now gives an "invalid argument" error (it didn't in 1.7.4). Note that the following reformulation of the last line provides a workaround, so it seems it has to do with "on-the-fly calculations" (if that's the right term): temp=hausmanresult[1,2]-1 pvalue X temp hausmanresult[1,1] BTW, on various occasions I noticed that arithmetic expressions cannot always be used in place of simple variables. But sometimes it does seem to work. Is there some rule when it should work, or is it sheer luck when it does? Thanks, Sven --===============1686508718255524980==-- From cottrell@wfu.edu Fri May 23 16:44:31 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] omit bug Date: Fri, 23 May 2008 16:44:17 -0400 Message-ID: In-Reply-To: 483728B5.9010201@gmx.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3181131404379649293==" --===============3181131404379649293== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 23 May 2008, Sven Schreiber wrote: > Am 23.05.2008 20:50, Allin Cottrell schrieb: > > Should be OK in CVS and Windows snapshot. > > > > Yes it looks like it, thanks. Good. > However, another new problem just appeared... > > matrix hausmanresult = $hausman > pvalue X hausmanresult[1,2]-1 hausmanresult[1,1] > > -- and this now gives an "invalid argument" error (it didn't in > 1.7.4)... Oof, this is to do with a change I introduced at Stefano's behest: not "casting" 1x1 matrix results to scalars automatically. I'll have to think about that some more. > BTW, on various occasions I noticed that arithmetic expressions > cannot always be used in place of simple variables. But > sometimes it does seem to work. Is there some rule when it > should work, or is it sheer luck when it does? In general, arbitrary arithmetic should work for arguments to built-in functions (or user-defined functions for that matter), while it's not very likely to work for arguments to straight "commands". However, in this particular case using the pvalue function won't help, right now, since it's a matrix/scalar thing. I'll try to fix this properly for 1.7.5. Allin. --===============3181131404379649293==-- From r.lucchetti@univpm.it Fri May 23 17:15:50 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] R and odbc Date: Fri, 23 May 2008 23:15:47 +0200 Message-ID: In-Reply-To: 200805231620.50109.ignacio.diaz-emparanza@ehu.es MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1078383265516549754==" --===============1078383265516549754== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Fri, 23 May 2008, Ignacio Diaz-Emparanza wrote: > The improvements about R are quite interesting. Do you plan to allow these > at the command line as well? I mean, I think we need a command block > > R_script > ... (R commands) > end R > > such that when gretl processes the R_script, the dataset is transfered in t= he > same way as we do it through the GUI (tools/start GNU R or through the new R > script capabilities), and the commands inside the block are passed to R. Very interesting idea. I'll think about it. Riccardo (Jack) Lucchetti Dipartimento di Economia Universit=C3=A0 Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti --===============1078383265516549754==-- From r.lucchetti@univpm.it Fri May 23 17:32:18 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] gtksourceview dev Date: Fri, 23 May 2008 23:32:16 +0200 Message-ID: In-Reply-To: alpine.LRH.1.10.0805231241190.2802@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4980141610460599729==" --===============4980141610460599729== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, 23 May 2008, Allin Cottrell wrote: > We're not using an installed copy of gtkourceview any more, but > strictly the slimmed-down version that comes bundled with the > gretl sources. > > However, there was one residual issue with the gtksourceview > build, depending on the version of the glibc regex.h header; I > think this is now fixed in CVS. Allin, due to my very limited familiarity with gtk I know little about that region of our source code (and even that little I'm not sure I understand). I'm sure there are very good reasons to use an in-house version of gtksourceview, but generally speaking, there are many advantages from linking to an external library; could you please explain what the disadvantages are in this case? Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti --===============4980141610460599729==-- From cottrell@wfu.edu Fri May 23 17:34:35 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] omit bug Date: Fri, 23 May 2008 17:34:25 -0400 Message-ID: In-Reply-To: alpine.LRH.1.10.0805231633170.2802@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4862777875704302182==" --===============4862777875704302182== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 23 May 2008, Allin Cottrell wrote: > On Fri, 23 May 2008, Sven Schreiber wrote: > > matrix hausmanresult = $hausman > > pvalue X hausmanresult[1,2]-1 hausmanresult[1,1] > > > > -- and this now gives an "invalid argument" error (it didn't in > > 1.7.4)... > > Oof, this is to do with a change I introduced at Stefano's > behest: not "casting" 1x1 matrix results to scalars > automatically. I'll have to think about that some more. In CVS and the snapshot there's a fix which takes care of all the probability-related functions (including pvalue). I'll search some more later for other functions that might be affected. Allin. --===============4862777875704302182==-- From cottrell@wfu.edu Fri May 23 17:47:59 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] gtksourceview dev Date: Fri, 23 May 2008 17:47:45 -0400 Message-ID: In-Reply-To: alpine.DEB.1.10.0805232325080.29575@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6323063126263412348==" --===============6323063126263412348== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 23 May 2008, Riccardo (Jack) Lucchetti wrote: > On Fri, 23 May 2008, Allin Cottrell wrote: > > > We're not using an installed copy of gtkourceview any more, but > > strictly the slimmed-down version that comes bundled with the > > gretl sources. > > I'm sure there are very good reasons to use an in-house version > of gtksourceview, but generally speaking, there are many > advantages from linking to an external library; could you please > explain what the disadvantages are in this case? Good question. One of the advantages of using an external library is that you get to benefit, for free, from bug fixes as new versions of the library become available, and from new features (if you want to make use of them). In the case of gtksourceview, however, the main line of development has now shifted to gtksourceview-2.0. This has more dependencies, an incompatible API, and (if I understand correctly) an incompatible format for the ".lang" language definition files. Now, gtksourceview-1.0 is fine for our purposes; and I don't want to have to support both major versions (remember, this has to work on Windows and OSX too). In addition, we're fine with a subset of gtksourceview's functionality. For example, sourceview will do automatic indentation and smart tabs, up to a point, but that's of little use to us because it can't know the gretl syntax as well as we do, and we're better with home-rolled versions of those functions. If there are are more bug-fix releases for gtksourceview 1.0 I'll incorporate the updates. And maybe some day we'll find a reason to shift to version 2.0 on all platforms. Allin. --===============6323063126263412348==-- From r.lucchetti@univpm.it Fri May 23 17:53:20 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] omit bug Date: Fri, 23 May 2008 23:53:18 +0200 Message-ID: In-Reply-To: alpine.LRH.1.10.0805231633170.2802@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6501469394723584393==" --===============6501469394723584393== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Fri, 23 May 2008, Allin Cottrell wrote: > Oof, this is to do with a change I introduced at Stefano's > behest: not "casting" 1x1 matrix results to scalars automatically. > I'll have to think about that some more. I can see Stefano's point, but there are also advantages in auto-casting a 1x1 matrix to a scalar. By the way (Stefano, are you there?) if you really need to ensure that the result of an operation is a matrix, you can always force it via the "matrix" alias, as in matrix x = foo(z) So, in my view, there are pros and cons to either choice. I think we ought to reach a collective decision here. So my proposal is: everyone interested, please have your say now. (Myself, I'd say "auto-cast".) Allin, just wait for a few days and then whatever you decide is the law. Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti --===============6501469394723584393==-- From futur.dorko@gmail.com Sat May 24 06:32:04 2008 From: Stefano Balietti To: gretl-devel@gretlml.univpm.it Subject: [Gretl-devel] null list as parameter Date: Sat, 24 May 2008 12:32:00 +0200 Message-ID: <1c7d4a100805240332m47191b03l1d11873e9f41b4b7@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2577563680288524566==" --===============2577563680288524566== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I had already mentioned this bug, but I can't find where. Anyway, it is still here. With a function declaration like this: function foo ( series a, scalar b[0::1], scalar c[0:2:1], const list d[null], scalar e[0:2:0]) I'm supposed to be able to invoke the function just with a simple: foo(a) where a is a a series obviously. Instead, gretl wants at least: foo(a,b,c,d) because does not accept the absence of the list, whereas it should be allowed by the [null] tag. Cheers. Stefano --===============2577563680288524566==-- From svetosch@gmx.net Sat May 24 11:00:45 2008 From: Sven Schreiber To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] omit bug Date: Sat, 24 May 2008 17:00:43 +0200 Message-ID: <48382D9B.6010307@gmx.net> In-Reply-To: alpine.LRH.1.10.0805231633170.2802@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0480683326762508205==" --===============0480683326762508205== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Am 23.05.2008 22:44, Allin Cottrell schrieb: > On Fri, 23 May 2008, Sven Schreiber wrote: > >> However, another new problem just appeared... >> >> matrix hausmanresult = $hausman >> pvalue X hausmanresult[1,2]-1 hausmanresult[1,1] >> >> -- and this now gives an "invalid argument" error (it didn't in >> 1.7.4)... > > Oof, this is to do with a change I introduced at Stefano's > behest: not "casting" 1x1 matrix results to scalars automatically. > I'll have to think about that some more. first, one thing I don't understand here: the second term (hausmanresult[1,1]) doesn't seem problematic (see the workaround I mentioned, where it is unchanged). But that would mean it is treated as a scalar, no? Then why does the first term (hausmanresult[1,2]) give something different? secondly, I think there are two different issues involved here: 1) The first one is what data type is returned by a function (built-in or user-defined). 2) The second issue is what happens if you pick elements from a matrix, as in the above example. From my experience with earlier discussions about those issues on the numpy (numerical python) mailing list, these issues can and should be decided separately. With respect to the first issue, I have some sympathy with Stefano's view that the returned datatype should not depend on the specific matrix dimension in particular cases. As for the second issue, I would say that explicitly indexing a single scalar element from a matrix --as in the above example-- should return a scalar. However, that would *not* mean that each indexing range which refers to a 1x1 submatrix should be returned as a scalar. For example, let's say somebody picks the first row of a matrix mymat by using mymat[1,] in an expression. In general the first row would not be just a single element, and as such mymat[1,] should always be a matrix, even if it turns out to be just a 1x1 matrix. [and now continuing a different topic:] > >> BTW, on various occasions I noticed that arithmetic expressions >> cannot always be used in place of simple variables. But >> sometimes it does seem to work. Is there some rule when it >> should work, or is it sheer luck when it does? > > In general, arbitrary arithmetic should work for arguments to > built-in functions (or user-defined functions for that matter), > while it's not very likely to work for arguments to straight > "commands". In principle I think I understand, but I'm not sure the demarcation between commands and functions is very clear in gretl. What would that 'pvalue' thing be for example? -sven --===============0480683326762508205==-- From cottrell@wfu.edu Sat May 24 13:33:13 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] gtksourceview dev Date: Sat, 24 May 2008 13:33:01 -0400 Message-ID: In-Reply-To: alpine.LRH.1.10.0805231735250.15153@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3016226298932272813==" --===============3016226298932272813== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Fri, 23 May 2008, Allin Cottrell wrote: > On Fri, 23 May 2008, Riccardo (Jack) Lucchetti wrote: > > > I'm sure there are very good reasons to use an in-house version > > of gtksourceview, but generally speaking, there are many > > advantages from linking to an external library; could you please > > explain what the disadvantages are in this case? > > Good question... On second thoughts, my arguments for always using the bundled version of gtksourceview (which we use on Windows and OSX) were a bit lame. The changes in API from 1.0 to 2.0 of this library were not all that substantial. So I've figured out the required changes and reinstated the possibility of using an installed libgtksourceview, with support for version 2.0. What should now happen on Linux at configure time is: * If the option --without-gtksourceview is given, we don't look for an installed version and use the bundled one. (Can be useful if you're trying to avoid dragging extra dependencies into a build of gretl -- since gtksourceview 1.0 requires libgnomeprint and v 2.0 requires GTK 2.12.) * Otherwise we look for version 2.0 and use it if found. * Failing that we look for version 1.0 and use it if found. * And failing that we fall back on the bundled version. Please let me know of any build problems. Allin. --===============3016226298932272813==-- From futur.dorko@gmail.com Sat May 24 13:34:23 2008 From: Stefano Balietti To: gretl-devel@gretlml.univpm.it Subject: [Gretl-devel] Gretl and R integration Date: Sat, 24 May 2008 19:34:20 +0200 Message-ID: <1c7d4a100805241034p26b2775dv77aa20c6862a4dc0@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3569658774397040642==" --===============3569658774397040642== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Some considerations about this new feature after a little using. - Sometimes, when executing (non-interactively) an R script which contains syntax errors Gretl crashes after informing the user about the error. Here an example is where I'm trying to estimate an APARCH with fGarch. library(fGarch) rr = gretldata[,"rr"] a = garchFit(~aparch(1,1),data=rr,cond.dist="dged",trace=FALSE) - Besides, Gretl does not keep trace of the opened R script, like it does for normal *.inp files in the recent opened files list. I think they are supposed to be listed there as well, maybe underlined with a different color or font. - Strangely, Gretl does not support the opening of an R script by simply dragging and dropping the file within the program window. I have to open it through the graphical menu. - Last, when I have an R script window opened and I open somehow a new dataset, the R script window is automatically closed. That is pretty unfair. That's all! Bye --===============3569658774397040642==-- From cottrell@wfu.edu Sat May 24 13:49:37 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] null list as parameter Date: Sat, 24 May 2008 13:49:17 -0400 Message-ID: In-Reply-To: 1c7d4a100805240332m47191b03l1d11873e9f41b4b7@mail.gmail.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5324679301860876177==" --===============5324679301860876177== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 24 May 2008, Stefano Balietti wrote: > I had already mentioned this bug, but I can't find where. Anyway, it > is still here. With a function declaration like this: > > function foo ( series a, scalar b[0::1], scalar c[0:2:1], const list > d[null], scalar e[0:2:0]) > > I'm supposed to be able to invoke the function just with a simple: > > foo(a) > > where a is a a series obviously. > > Instead, gretl wants at least: > > foo(a,b,c,d) Could you post a complete test case, please? I think there must be some special complication at work, because the following script works fine here: It prints: ? myfoo(sqft) Obs a 1 1065 2 1254 3 1300 4 1577 5 1600 6 1750 7 1800 8 1870 9 1935 10 1948 11 2254 12 2600 13 2800 14 3000 b = 1.00000 c = 1.00000 e = 0.00000 Allin. --===============5324679301860876177==-- From cottrell@wfu.edu Sat May 24 14:55:54 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Gretl and R integration Date: Sat, 24 May 2008 14:55:44 -0400 Message-ID: In-Reply-To: 1c7d4a100805241034p26b2775dv77aa20c6862a4dc0@mail.gmail.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3285403644297898480==" --===============3285403644297898480== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 24 May 2008, Stefano Balietti wrote: > Some considerations about this new feature after a little using. > > - Sometimes, when executing (non-interactively) an R script which > contains syntax errors Gretl crashes after informing the user about > the error... Oops, the verbose message from R was overflowing our error-message buffer. Fixed in CVS. > - Besides, Gretl does not keep trace of the opened R script, like it > does for normal *.inp files in the recent opened files list. I think > they are supposed to be listed there as well, maybe underlined with a > different color or font. That could perhaps be added. It would require a fair number of changes. > - Strangely, Gretl does not support the opening of an R script by > simply dragging and dropping the file within the program window. I > have to open it through the graphical menu. Well, there's nothing very "strange" about that, it doesn't happen by magic ;-) However, that's now coded in. > - Last, when I have an R script window opened and I open somehow a new > dataset, the R script window is automatically closed. That is pretty > unfair. OK, fixed in CVS. Allin. --===============3285403644297898480==-- From cottrell@wfu.edu Sat May 24 15:15:50 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] omit bug Date: Sat, 24 May 2008 15:15:39 -0400 Message-ID: In-Reply-To: 48382D9B.6010307@gmx.net MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3074446892293343110==" --===============3074446892293343110== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 24 May 2008, Sven Schreiber wrote: [ first, about cating 1x1 matrices to scalars, to which I'll reply later, then... ] > > > BTW, on various occasions I noticed that arithmetic > > > expressions cannot always be used in place of simple > > > variables. But sometimes it does seem to work. Is there some > > > rule when it should work, or is it sheer luck when it does? > > > > In general, arbitrary arithmetic should work for arguments to > > built-in functions (or user-defined functions for that > > matter), while it's not very likely to work for arguments to > > straight "commands". > > In principle I think I understand, but I'm not sure the > demarcation between commands and functions is very clear in > gretl. What would that 'pvalue' thing be for example? For the most part the distinction is pretty clear: a function is something where all the arguments are wrapped in parentheses and separated by commas, and a command is everything else. But there are a few hybrid cases, and "pvalue" is one such. Since we have a perfectly good pvalue function with the same semantics, we implement the "command" form by composing and executing a call to "genr"; this gives more flexibility on the form of the arguments. Allin. --===============3074446892293343110==-- From r.lucchetti@univpm.it Sat May 24 17:49:16 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Gretl and R integration Date: Sat, 24 May 2008 23:49:13 +0200 Message-ID: In-Reply-To: alpine.LRH.1.10.0805241412440.2831@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2141130878964932733==" --===============2141130878964932733== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit While we're on this: I just committed a few changes, mostly cosmetic, to the "export from R" machine: 1) the function gretl_export and the string gretl_dotdir were renamed to gretl.export and gretl.dotdir. I'm no R export, but it looks like more polite to use the dot rather than the underscore in R-land. 2) we had a naming problem when exporting a time-seried object with just one variable; now fixed (a bit clumsily, but as I said I'm no R expert). We have an open problem: if some sort of subsampling is in effect on the gretl side, mostl likely the append mechanism won't work. This is due to the fact that I haven't been able to figure out how to stuff into the csv file row labels in a format that that gretl can digest, so I removed row labels altogether. An alternative possibility would be to intervene on the gretl side: in fact, the script below (which has nothing to do with R interaction _per se_) won't work unless, of course, you get rid of the "smpl" command on line 3. I don't know if this is actually a problem. It certainly makes things more difficult when it comes to R interaction. Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti --===============2141130878964932733==-- From futur.dorko@gmail.com Sat May 24 18:11:18 2008 From: Stefano Balietti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] null list as parameter Date: Sun, 25 May 2008 00:11:15 +0200 Message-ID: <1c7d4a100805241511u16862897jfda0289a332665c9@mail.gmail.com> In-Reply-To: alpine.LRH.1.10.0805241343560.2831@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4150579208840394641==" --===============4150579208840394641== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Well, you are right that wasn't the problem. The problem was that the null list was passed to the ols command and it caused the error. Now the point is that the error message may mislead, and perhaps it should be changed. In fact, this way the ols produces the error msg: "Command has insufficient arguments" If that happens to a function (the case I thought) we have: "*function_name*: not enough arguments Command has insufficient arguments" The best would be having a similar msg for the ols as well: "*command_name*: not enough arguments Command has insufficient arguments" But that is far from being an urgent matter. Cheers. Stefano --===============4150579208840394641==-- From cottrell@wfu.edu Sat May 24 20:57:03 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] null list as parameter Date: Sat, 24 May 2008 20:56:52 -0400 Message-ID: In-Reply-To: 1c7d4a100805241511u16862897jfda0289a332665c9@mail.gmail.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6527030967062209701==" --===============6527030967062209701== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 25 May 2008, Stefano Balietti wrote: > Well, you are right that wasn't the problem. The problem was > that the null list was passed to the ols command and it caused > the error. Now the point is that the error message may mislead, > and perhaps it should be changed... Ah, there's a difference that should be resolved, between the gretlcli output and the GUI script output. Running the above with gretlcli produces: Command has insufficient arguments error on line 1 of function myfoo > ols a x gretlcli: error executing script: halting > myfoo(price) which seems to me fine. But it's true, in the GUI the error message is not so informative. Allin. --===============6527030967062209701==-- From cottrell@wfu.edu Sat May 24 21:17:23 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Gretl and R integration Date: Sat, 24 May 2008 21:17:13 -0400 Message-ID: In-Reply-To: alpine.DEB.1.10.0805242335320.18194@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1107064845328119532==" --===============1107064845328119532== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 24 May 2008, Riccardo (Jack) Lucchetti wrote: > While we're on this: I just committed a few changes, mostly > cosmetic, to the "export from R" machine: > > 1) the function gretl_export and the string gretl_dotdir were > renamed to gretl.export and gretl.dotdir. I'm no R export, but > it looks like more polite to use the dot rather than the > underscore in R-land. It seems to me a weird tic in the R language that '.' has no special syntactical charge in the middle of an identifier -- but let it not be said that we are lacking in politesse! BTW, please watch out for some changes in CVS: I'm moving the R-file writing apparatus from gui_utils.c to a new file, lib/src/foreign.c, so as to support command-line invocation of chunks of external script, as per Ignacio's suggestion. > 2) we had a naming problem when exporting a time-seried object > with just one variable; now fixed (a bit clumsily, but as I said > I'm no R expert). If it works, then hey! > We have an open problem: if some sort of subsampling is in > effect on the gretl side, mostl likely the append mechanism > won't work... Append has some "issues". That's been on my agenda for a while, but I'll see if I can do anything that might be useful in this context. Allin. --===============1107064845328119532==-- From cottrell@wfu.edu Sat May 24 21:40:17 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Gretl and R integration Date: Sat, 24 May 2008 21:40:01 -0400 Message-ID: In-Reply-To: alpine.LRH.1.10.0805242109580.9028@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4003433837059527313==" --===============4003433837059527313== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 24 May 2008, Allin Cottrell wrote: > BTW, please watch out for some changes in CVS: I'm moving the > R-file writing apparatus from gui_utils.c to a new file, > lib/src/foreign.c, so as to support command-line invocation of > chunks of external script, as per Ignacio's suggestion. E.g., based on the example in the manual: This works in CVS. I'll do some proper testing tomorrow. ("foreign language=ox" should be a possibility too, but it's not ready yet.) Allin. --===============4003433837059527313==-- From cottrell@wfu.edu Sat May 24 22:22:57 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Gretl and R integration Date: Sat, 24 May 2008 22:22:41 -0400 Message-ID: In-Reply-To: alpine.DEB.1.10.0805242335320.18194@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3620878565260773286==" --===============3620878565260773286== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 24 May 2008, Riccardo (Jack) Lucchetti wrote: > [T]he script below (which has nothing to do with R interaction > _per se_) won't work > > I think this problem is specific to unstructured data. If you stick in, for example, "setobs 1 1950" after the "nulldata" command, the script works OK. I'll take a further look at this. Allin. --===============3620878565260773286==-- From r.lucchetti@univpm.it Sun May 25 02:48:34 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Gretl and R integration Date: Sun, 25 May 2008 08:48:31 +0200 Message-ID: In-Reply-To: alpine.LRH.1.10.0805242133350.9028@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0913475780270860562==" --===============0913475780270860562== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, 24 May 2008, Allin Cottrell wrote: > This works in CVS. I'll do some proper testing tomorrow. > ("foreign language=ox" should be a possibility too, but it's not > ready yet.) Well, we do have a "special relationship" with R, so generalising this (which may include octave, gnuplot... whatever) requires a bit of planning. For example, the way we launch R is hardwired. In the case of, say, ox, the user should have a way to tell gretl where the executable is, and so on. I'd say, let's focus on R right now and postpone the generalisation for 1.7.5++. Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti --===============0913475780270860562==-- From r.lucchetti@univpm.it Sun May 25 02:53:18 2008 From: Riccardo (Jack) Lucchetti To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Gretl and R integration Date: Sun, 25 May 2008 08:53:10 +0200 Message-ID: In-Reply-To: alpine.LRH.1.10.0805242219160.9028@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4673314891339647982==" --===============4673314891339647982== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit On Sat, 24 May 2008, Allin Cottrell wrote: > I think this problem is specific to unstructured data. If you > stick in, for example, "setobs 1 1950" after the "nulldata" > command, the script works OK. I'll take a further look at this. Hmm, not quite. For example: My point is that we ought to find a way to do without the row labels if the number of observations in the current sample matches the number of rows in the csv file. Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti --===============4673314891339647982==-- From cottrell@wfu.edu Sun May 25 10:49:52 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Gretl and R integration Date: Sun, 25 May 2008 10:49:48 -0400 Message-ID: In-Reply-To: alpine.DEB.1.10.0805250844330.21109@ec-4.econ.univpm.it MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2492080796740252990==" --===============2492080796740252990== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sun, 25 May 2008, Riccardo (Jack) Lucchetti wrote: > On Sat, 24 May 2008, Allin Cottrell wrote: > > > This works in CVS. I'll do some proper testing tomorrow. > > ("foreign language=ox" should be a possibility too, but it's not > > ready yet.) > > Well, we do have a "special relationship" with R, so > generalising this (which may include octave, gnuplot... > whatever) requires a bit of planning. For example, the way we > launch R is hardwired. In the case of, say, ox, the user should > have a way to tell gretl where the executable is, and so on. I'd > say, let's focus on R right now and postpone the generalisation > for 1.7.5++. Yes, agreed. Allin. --===============2492080796740252990==-- From cottrell@wfu.edu Sun May 25 11:07:48 2008 From: Allin Cottrell To: gretl-devel@gretlml.univpm.it Subject: Re: [Gretl-devel] Gretl and R integration Date: Sun, 25 May 2008 11:07:40 -0400 Message-ID: In-Reply-To: alpine.LRH.1.10.0805242133350.9028@ricardo.ecn.wfu.edu MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2785892284853441575==" --===============2785892284853441575== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Sat, 24 May 2008, Allin Cottrell wrote: >