copying "show data" fails
by Sven Schreiber
Hi,
(on Windows) I did "show data" with two series selected. In the output
window there's a copy button, followed by a window with option radio
buttons. Choosing "simple text" works fine, but after choosing any other
option (RTF/Tab/comma) I cannot paste anything to a text editor, as if
nothing was copied to the clipboard.
thanks,
sven
7 years, 4 months
arima, re-,re-.....revisited
by oleg_komashko＠ukr.net
Dear all,
An example to reproduce
function void arma11_via_kalman (series y)
/* listing 33.1 with '--hessiaan' dropped */
/* parameter initialization */
scalar phi = 0
scalar theta = 0
scalar sigma = 1
/* state-space model setup */
matrix H = {1; theta}
matrix F = {phi, 0; 1, 0}
matrix Q = {sigma^2, 0; 0, 0}
bundle kb = ksetup(y, H, F, Q)
/* maximum likelihood estimation */
mle logl = ERR ? NA : kb.llt
kb.obsymat[2] = theta
kb.statemat[1,1] = phi
kb.statevar[1,1] = sigma^2
ERR = kfilter(&kb)
params phi theta sigma
end mle
end function
set verbose on
arma11_via_kalman(pop)
arma 1 1; pop --nc --conditional
catch arma 1 1; pop --nc
catch arma 1 1; pop --nc --x-12-arima
Question: why the natives do not use
this trick?
Oleh
7 years, 4 months
building gretl on Windows, revisited
by Allin Cottrell
Thanks go to Sven for persevering in testing the Windows build
process; as a result we've fixed several little glitches lately. So
I'd encourage anyone else who's interested to have a go.
Documentation is at
http://ricardo.ecn.wfu.edu/pub/gretl/winbuild/
Besides fixing glitches, however, there's now a substantial
improvement in the process (in the last couple of days). The
dependencies of a gretl build are mostly met by standard mingw64
packages but there are some additional materials required, which to
date have been supplied by "static" archives: now those materials
take the form of pacman packages subject to auto-updating. I've set
up a package server at sourceforge which will be updated in sync
with our package-builds for Windows.
Here's the basic idea: when you're using pacman (in this case under
MSYS2) the command
pacman -Syu
will update your cache of the relevant repository data and offer you
any available package updates. This will now apply to the
gretl-specific "extras" as well as the regular mingw64 stuff.
If you run our latest setup.sh shell script from scratch you will
automatically be tuned into this update path. If you already used
the previous mechanism to initiate a gretl build you'll have to do a
couple of things to get onto the auto-update path:
1) Make pacman aware of the new gretl package repository. There's a
little shell script, add-repo.sh, in the "winbuild" directory
referenced above, that will do that for you.
2) Remove the older "static" gretl-specific stuff (which will
conflict with the new packages), then install the current packages.
For the extra dependency libraries and headers:
pacman -R mingw-gretl # remove
pacman -S gretl-x86_64-deps # or gretl-i686-deps for 32-bit
And for the gnuplot-for-gretl package:
rm /opt/gretl/bin/wgnuplot.*
pacman -S gretl-x86_64-gnuplot # or gretl-i686-gnuplot, 32-bit
But note that the second of these updates will work only if you
follow the recommendation to install gretl under /opt/gretl.
Otherwise you're on your own.
To be clear: the upside of making these changes is that, in future,
running
pacman -Syu
will get you any updates to the gretl-specific builds of openblas,
libcurl, libsvm and gnuplot, as they become available.
Allin
7 years, 4 months
python foreign gretl_export()
by Sven Schreiber
Hi,
I just checked that in March 2013 we discussed "python foreign
problems", in particular the gretl_export function (in gretl_io.py).
Back then we ditched Numpy's savetxt function for certain reasons. One
minor remark is that the user guide in ch. 43 still talks about savetxt,
but that's not important.
Instead I'd suggest to go back to numpy's savetxt, because it offers
gzip compression "for free", whenever a 'gz' extension is given.
Does that sound like a good idea? I could send a concrete proposal for
gretl_export -- but not for the imminent release.
cheers,
sven
7 years, 4 months
SF git status
by Allin Cottrell
I made a couple of mentions today of being unable to push changes in
my working copy of the gretl sources to sourceforge. I've now been
able to push, though I'm sure that everything is back to normal
there. The GUI git interface seems currently slow-to-unusable;
hopefully things will stabilize soon.
Allin
7 years, 4 months
plot bug
by Sven Schreiber
Hi,
this is with yesterday's snapshot, but it's probably a little older than
that. I think it's pretty severe, because it distorts data and is not
always obvious.
To start with, run this code (in the GUI):
<hansl>
open denmark
smpl 1979:1 1985:4 # subsample
series dm = 400 * ldiff(LRM)
smpl --full
series xsd = normal()
series x = 0
smpl 1975:1 1985:4
plot dm
options time-series
option band=x,xsd,1.96
option band-style=fill,dark-grey
printf "set xrange [1975:1985]"
end plot --output=display
</hansl>
Then, edit the plot (right-click, edit). Increase the font size, click
"OK", then "Apply".
What happens for me is that the data series (in this case the points on
the one hand and the filled bands OTOH) become mismatched, at least one
of them is shifted horizontally.
It seems --though I'm not sure-- that the missing values in one of the
series are crucial to get this wrong behavior.
thanks,
sven
7 years, 4 months
sluggish menu response when console window is open
by Sven Schreiber
Hi,
we have vaguely mentioned some slowness of (GUI) gretl, but we (or I)
haven't been able to pin things down. Maybe I now have something
reproducible (on Windows 7 here, latest snapshot):
1) start gretl
2) open a dataset (don't know whether that's necessary)
3) open the console window (via toolbar button)
4) click on a menu
-> It takes a noticeable time for the menu to open/unfold, and also when
changing to a different menu.
Can't say whether that was "always" there, as I don't use the console
that often.
Others seeing this?
cheers,
sven
7 years, 4 months
saving data from R in gdt formate
by oleg_komashko＠ukr.net
Dear All.
Sometimes one needs to save R data,
say 'data.frame', 'ts' or 'mts' object
in .gdt formate from inside R session
So, hopefully, the script below will be useful
for some participants
<R> #installation of the mentioned packages is required"
library(Rgretl)
library(fpp) #only as exemplary data set
air <- window(ausair, start=1990) # ts for not dealing with large data sets as example
gr.script <- "store \"/home/oleh/gretl/rair\""
run_grcli(gr.script,data =air)
<R>
# do not use $workdir or similar, use full pathes
# change for your favourite dir!!
Oleh
7 years, 4 months
some lists/series and matrix parallels for statistical functions
by oleg_komashko＠ukr.net
Dear all,
many statistical functions and elements extraction are
very different for data in the both forms
Several examples
sum()
denote
list lis = ...
sum(lis) is essentially the same as sumr({lis})
but sum({lis}) is different
In the opposite direction:
analogue of sumc({lis}) is aggregate(lis,const,"sum")[3:]
mean()
In the contrast to sum() it is not allowed for a matrix
Again, mean(lis) corresponds to meanc({lis})
Overall mean for a matrix of general shape is meanc(vec(a_matrix))
The behavior of min and max is similar to that of mean
Overall median for a matrix is quantile(vec(a_matrix),0.5)
In my opinion, it would be much transparent
if sum() mean(), etc were overall sums and means
and sumc(), sumr() etc were defined both for lists and matrices
these functions could have additional boolean/integer parameter
indicating how to treat missing values
Oleh
7 years, 4 months
strange sum() behavior
by Sven Schreiber
Hi, here's something that I find puzzling (snapshot Feb 7):
<hansl>
clear
catch eval sum(1) # error: "no dataset active"
catch scalar sc = sum(1) # ditto
open djclose.gdt
catch eval sum(djclose) # OK
catch eval sum(1) # weird printout of all values, almost like 'print 1'
catch scalar sc = sum(1) # error: "data types not matched"
catch scalar sc = sum(djclose) # OK
catch scalar sc = sum(1) # error: "sc is scalar, not acceptable"
</hansl>
I can understand the first two occurring "no dataset active" errors if
gretl interprets the '1' as a series ID which it cannot find.
But then: First the behavior yielding the weird printout looks like a bug.
Secondly, the final two different error messages is something I don't
get. Also bugs?
thanks,
sven
7 years, 4 months
