Feature list on the web page
by Sven Schreiber
Hello,
I would suggest various additions to the frontpage on gretl.sf.net in
the Features section:
* add a "panel estimators" entry after time series and limited dep. vars
* perhaps also mention "structural VARs" under the time series methods point
* add the "Hansl" name at the bullet point "integrated powerful
scripting language", and integrate the following bullet point about
command loop structures; also, add keywords such as "matrix and algebra
programming"
* The point "Links to... <other languages>" is quite vague I think and
even somehow sounds as if gretl necessarily is not enough to do "further
data analysis".
Also while the "foreign" feature is quite cool for insiders and
experienced users I'm not sure whether it is a selling point for people
that don't know gretl yet.
Just some thoughts,
sven
9 years, 11 months
Adding observations within a function
by Allin Cottrell
At the Berlin gretl conference Marcin asked me if it would be possible
to enable use of "dataset addobs" within functions.
I can see the point in this: if you're writing a package that's
intended to do forecasting, it would be very useful to be able to add
observations, even if just temporarily. This is now in not-CVS [
http://ricardo.ecn.wfu.edu/pub/gretl/gretl-updates.tgz ] and
snapshots (on ricardo.ecn.wfu.edu).
You can use "dataset addobs" in a function only if the end of the
sample range, on entry, is the end of the dataset (i.e. $t2 cannot be
restricted, though $t1 could be). And when the function exits the
extra observations disappear. So if you want to return an out of
sample forecast you'd have to do that in the form of a matrix.
This is experimental: I'd be interested to hear how it works, from
people who actually do forecasting!
Allin
9 years, 11 months
Proposal for function package cleanup
by Sven Schreiber
Hi,
[First of all, this goes especially to Henrique and Marcin, as we seem
to be a little bit responsible for package supervision. But I thought it
doesn't hurt if the gretl-devel list also reads it.]
Following up on my post from November "Possible redundancy of some
function packages?" and the ensuing discussion (see
http://lists.wfu.edu/pipermail/gretl-users/2014-November/010422.html), I
now propose to really do something about the following packages, and
sometimes that means to remove them. If you don't voice your opinion
now, my suggestions will become reality.
1) clustered_ols (Pigini) -- could serve as a nice example, but doesn't
have to be a package for that, should be moved as a script to the
exercise script collection. Read: should be removed from the package list!
2) cnumber (Monsueto) -- maybe I'm confusing things, but could this be
redundant when the stuff that Lee just presented at the conference is
packaged? (I guess it could stay until then.)
3) fgls (Yang) -- There was no feedback on what it actually does, should
be removed.
4) GHegy / HEGY_test (Diaz / Lucchetti) -- Guys, could you please get
your act together on this? It is ridiculous that two core gretl people
have competing or conflicting packages. It almost looks to me as if we
could remove HEGY_test by Jack because GHegy by Ignacio is a superset?
If no one intervenes, this should be the course of action.
5) fcModels / HoltWinters (Yang / Diaz) -- Again, cooperation would be
good. But both packages were updated relatively recently, which is also
a good sign. Don't know what else to do with this.
6) growth (Bala) -- I didn't mention this last time, but now it seems to
me this functionality is too small for a package (sorry, but this
regresses on a trend and just gets the coefficient, unless I'm missing
something). Should be removed.
7) JB (Yang) -- there was feedback and a small discussion last time,
which in my interpretation also boils down to: should be removed.
8) MWU / mwu / mwu_dummy (Yang): Yi-Nung, please consolidate these very
similar things into one package with different options. Please respond
to this message, otherwise I propose to remove two of these three packages.
This list is probably not exhaustive, there seem to be new packages, but
I don't have time right now to look at all of them.
thanks,
sven
9 years, 12 months
gretl data installers
by Allin Cottrell
I noticed recently that the self-extracting (exe) installers for our
textbook data packages weren't working properly on Windows 8, with
64-bit gretl installed.
What's supposed to happen is that the exe picks up the path to the
gretl installation from the Windows registry and offers it as the
default location, but I saw the default come up empty. I think this
must be due to the fact that on 64-bit Windows there are two versions
or modes of the registry (32- and 64-bit); apparently our (quite old)
installers were just looking at the 32-bit registry and hence not
finding the entry for gretl.
I've now rebuilt the installers using current Inno Setup and tested on
Windows 8. I think they should also do the right thing on earlier (and
32-bit) Windows, but it would be nice to have that confirmed. If
anyone is able to test, please see (since SF is down):
http://ricardo.ecn.wfu.edu/pub/gretl/
For example,
http://ricardo.ecn.wfu.edu/pub/gretl/wooldridge_data.exe
Allin
9 years, 12 months
Gretl & R interaction problem
by Henrique Andrade
Dear Gretl Team,
When we use the "foreign" function and the foreign script has errors, Gretl
freezes. Please take a look at the following example:
<hansl>
open australia.gdt
foreign language=R --send-data
gretldata
end foreign
</hansl>
It works just fine. Now let's generate an intentional error using
"gretldat" instead of "gretldata":
<hansl>
open australia.gdt
foreign language=R --send-data
gretldat
end foreign
</hansl>
On a Windows PC machine the only way to make things go back to normality is
using Task Manager (CTRL-ALT-DEL) to finish Rterm. When we do this Gretl
comes back to life [;-)] and shows us the following message:
"Error in eval(expr, envir, enclos) : object 'gretldat' not found
Error executing script: halting"
Best regards,
Henrique Andrade
9 years, 12 months
source news
by Allin Cottrell
A follow-up to
http://lists.wfu.edu/pipermail/gretl-devel/2015-July/005882.html
(which still applies as of this writing).
Some new things in the gretl source since sourceforge CVS went down:
* Fix the bug noted by Sven in
http://lists.wfu.edu/pipermail/gretl-devel/2015-July/005880.html
* Add a new square() function (documented) with an optional argument
to generate cross-products as well as squares. Retire the old xpx()
function but preserve the name as an alias for square() with the
cross-product option activated.
* Add a seasonals() function (documented) with two optional
arguments, the first to specify a period to omit and the second
to specify centering of the seasonal dummies.
* "vif" command: lose the not-very-useful info on X'X that we've
printed to date, and substitute the Belsley-Kuh-Welsch
variance decomposition table, as advocated by Lee Adkins at
the Berlin gretl conference.
* GUI function package editor: add check for unsaved changes under
"Extra properties". Do more checking and give more feedback when
saving a package in zip format.
* Function package browser: add a toolbar item ("index" icon, tooltip
"Package registry") to show which packages are registered to
appear on which menus, with the option of removing them.
* Numerous "internal" tweaks to GUI function package apparatus in
the interest of greater robustness.
* Overwrite check on saving to file: switch to the built-in GTK API,
maybe catch more cases where overwriting should be flagged?
* Updated Romanian translation (thanks, Mihaela!)
Allin
9 years, 12 months
X-12-ARIMA, X-13ARIMA-SEATS and Tramo/Seats suggestions
by Henrique Andrade
Dear Gretl Team,
I'd started to use more "heavily" seasonal adjustment software here in my
new job. Here we need to replicate adjustments made by official government
agencies, so we can't just "push the buttons".
Because of this I developed a very complex/ugly set of small functions and
scripts to replicate the results of our official statistics agency (IBGE).
My boss is trying to convince me to use R packages but I would like to
avoid this ;-)
Please keep in mind I am trying to think as a average user that doesn't
like to use command line and loves EViews. It is not a personal request - I
already have reached a satisfactory solution for my particular problem ;-)
So my suggestions to improve the Gretl seasonal adjustment are:
(1) I would like to choose between X12 and X13 methods with no need to
change the program paths (under Tools -> Preferences -> General ->
Programs). In the case of command line we could use Y_sa = (Y, X12), Y_sa =
(Y, X13) or Y_sa = (Y, T).
(2) When the user marks the option "Make X-12-ARIMA command file" it would
be very useful that Gretl stores the components just like she does when the
user opts for the option "Execute X-12-ARIMA directly".
(3) It would be great if Gretl generates plots when the option "Generate
graph" was chosen even if the option "Make X-12-ARIMA command file" was
marked.
(4) Insert the option to use a pre-defined spec in the command line.
Something like: series Y_sa = (Y, X,
"C:\Users\henrique\gretl\x12spec.spec"). In that case Gretl will pass the
target variable Y to X12 as the data: <x12command> (...) data = (Y) (...)
</x12command>.
(5) Combine X-12/X13 and Tramo/Seats into one entry in Gretl's menu
(Variable -> Seasonal adjustment -> X12, X13 or Tramo/Seats). Please take a
look at the attached PNG file.
(6) Modify the X12 menu to make it closer to TRAMO/SEATS menu, with options
inside tabs and the possibility to specify the SARIMA(p,d,q,P,D,Q) (the
ARIMA tab).
Best regards,
Henrique Andrade
10 years
argument type problem when 1x1 matrix is coerced to scalar
by Sven Schreiber
Hi,
while I was testing the SVAR addon I ran into a bug that has its roots
in gretl. The code below shows the problem, namely that even though the
function hey() officially returns a matrix, if it's a 1x1 matrix _and_
if the caller does not explicitly cast the output to a matrix type (with
the 'matrix' alias for genr), then gretl puts the return value into a
scalar type. And if the caller then wants to use this variable as a
matrix (because that's what it's supposed to be), it fails.
So I think gretl should honor the return type of a user-defined function
always. I know that sometimes gretl has to convert a 1x1 matrix to a
scalar, for example if vec(a)'vec(a) is treated by the programmer as a
number for further stuff. But somehow gretl does it prematurely here.
thanks,
sven
<hansl>
function void hu(matrix *m)
print "ouf"
end function
function matrix hey(bool in)
if in
return zeros(2,2)
else
return zeros(1,1)
endif
end function
out2 = hey(1)
hu(&out2) # works
matrix out3 = hey(0)
hu(&out3) # works
out = hey(0)
hu(&out) # fails, wrong argument type
</hansl>
10 years
replacing function package list by choosing directory is not persistent
by Sven Schreiber
Hi,
unsure whether this is intended:
In the function package list window (local machine, not "on server") I
click the choose-directory button to load additional packages from a
local directory. Upon being asked "add packages or replace?" I choose
replace and (somewhat to my surprise) all the packages in the window
listing are replaced with the few packages in the chosen directory. Ok.
But when I close the package list window and open it again, all the old
packages are back and the newly loaded are gone from the list.
Don't know which part of the behavior is wrong, but taken together it
seems inconsistent.
(Latest Win snapshot.)
thanks,
sven
10 years