gretlcli.exe in the Windows console
by Allin Cottrell
A question for users of gretl on Windows: Do you ever use
gretlcli.exe in the Windows console (cmd.exe or "PowerShell"),
running in a language that requires non-ASCII characters to
represent gretl's output correctly?
Why I ask: Over the years we've evolved a complex and confusing
mechanism to try to get this right, by recoding output to the
(legacy) locale "code page" if necessary. (I'm not sure we always
get it right, or even that it's possible to get it right in
general.)
I'd like to get rid of the complications by, in effect, saying,
"gretl output will always be encoded in UTF-8, please deal with it."
Dealing with it, in the Windows console, means setting your "code
page" to 65001 (UTF-8).
So basically I want to know: Would this be OK? Or would it hurt a
lot of people?
(Please note: this has nothing to do with running the gretl GUI
program, it's only about running the command-line program on
Windows. It's also irrelevant for anyone running gretlcli.exe in
English.)
Thanks,
Allin
5 years
gretl crash after 'hausman'
by Sven Schreiber
...just after sending the last message gretl crashed on me, and it's
reproducible (in the console):
- open abdata and estimate something with OLS
- run hausman
- execute 'print $test' (which produces NA)
- run hausman again -> crash
Recent Windows snapshot.
thanks
sven
5 years
on the 'hausman' test command
by Sven Schreiber
Hi,
I stumbled over the fact that 'hausman' cannot be executed after
'panel'. It is documented that you must estimate a --pooled-- model with
OLS to be able to run hausman afterwards.
It took me a while to understand the logic: After 'panel ...
--random-effects' the Hausman test is already carried out automatically,
and you can retrieve the result via $hausman. I will add this hint to
the command ref for 'hausman'.
(While we're at it: The following output of 'hausman' is probably not
marked for translation in the sources:
Variance estimators:
between = 258,452
within = 5,55967
Panel is unbalanced: theta varies across units
)
thanks
sven
5 years
extension of the dummify function for anonymous series
by Sven Schreiber
Hello, I was reminded again of the fact that a construct like
dummify($unit) cannot be used, since dummify creates a list and needs
information about the name of the input series to name the list members.
So the idea is to give dummify another optional (string) argument that
provides this naming information.
Example of desired usage:
list groupdums = dummify($unit, NA, "du")
This particular line with the name "du" would be equivalent to "genr
unitdum", apart from the fact that the relevant list is directly created
in one go.
To be clear, dummify($unit) would continue _not_ to work since naming
information is missing. And dummify(x, , "better_use_z") would override
the "x" name of the input series for the dummy creation.
In principle it might perhaps also be interesting to substitute the two
optional arguments with a single option bundle, but I don't know if such
overloading would be desirable here.
thanks
sven
5 years
about the name "fft2"
by Sven Schreiber
Hi,
I was going to move the documentation of the Fast Fourier Transform to a
more fitting place in the guide (away from "special functions in genr",
because genr is not really relevant).
Then I noticed that the section is a bit outdated because it doesn't
mention the new complex-yielding function fft2. I can update that.
However, it occurred to me that "fft2" is a problematic name down the
road, just like "coint2" was problematic until it was renamed as
"johansen". Namely the "2" becomes meaningless after fft is gone and is
only understandable for gretl historians. (I also find it confusing
because there's the library name fftw3 with another digit in the name,
but maybe that part is just me.)
So, how about a new name? (Keeping the existing ones as aliases I'd
say.) Here's a spontaneous list of possibilities:
- fourier() (perhaps along with ifourier() as an alias for ffti()? -
actually quite elegant as a 8-char name...)
- fftC(), with the C standing for complex; but maybe not much of an
improvement over the "2"
- ...or biting the backwards-incompatibility bullet and change the
original fft() to do what fft2() does now. (My quick check doesn't show
any package that uses fft anymore, so no breakage expected there.)
thanks
sven
5 years
on 'unitdum' in non-panels
by Sven Schreiber
Hi again,
just noticed that 'genr unitdum' also works in a cross-section dataset,
by creating N observation dummies. The doc only refers to panel data, as
does the name, of course.
I suppose the underlying reason are the semantics of $obsmajor. But is
this intended? If yes, it might as well be documented.
thanks
sven
5 years
confusion with new generalized print
by Sven Schreiber
Hi,
now that the print command is generalized (in git), I tried the
following line inside a function:
print b.obsT b.p b.lagord b.T
where all those bundle members are scalars. Then print interprets them
as series IDs and spits out the following error:
Variablennummer 434 außerhalb der Grenzen # variable number out of bounds
*** error in function construct_bmats, line 1
> print b.obsT b.p b.lagord b.T
I'm not saying this is necessarily a bug, but I find the error message
confusing, although I understand gretl's internal logic (after thinking
about it). Just want to make sure this is the intended status quo.
thanks
sven
5 years