new string substitution failure
by Sven Schreiber
Hi,
I'm currently editing the function package HIP by Jack and Claudia
Pigini because I have run into various problems using it.
For example if I simply have it converted to a hansl script and then try
to run the automatically included sample function call I get the error
"unexpected @".
The cause is some string substitution after an 'mle' block, below is an
example of this error in a different context.
I guess this is fallout from the new parser? This is with 1.10.0cvs from
Oct 24th on Windows 8.
Thanks,
sven
<hansl>
string bar = "-v"
### below ripped from mle-advanced.inp
nulldata 10000
set optimizer bfgs
# generate artificial data
series x1 = normal()
series x2 = normal()
series x3 = normal()
list X = const x1 x2 x3
series ystar = x1 + x2 + x3 + normal()
series y = (ystar > 0)
matrix b = zeros(nelem(X),1) # initialize b at 0
mle logl = y*ln(P) + (1-y)*ln(1-P)
series ndx = lincomb(X, b)
series P = cnorm(ndx)
params b
end mle @bar
</hansl>
10 years
logit/probit and robust standard errors
by Sven Schreiber
hi,
first let me say that looking into the issue of heteroskedasticity in a
binary-choice (probit/logit) setup, I found two existing function
packages, namely HIP by Jack and Claudia, and LOGIT_HETERO by Artur.
This is showing the great evolution of gretl in connection with
user-contributed stuff. (Although Jack probably doesn't really qualify
as a "user" in this sense, but anyway.)
Ok, now I've also noticed that the 'logit' and 'probit' commands offer a
--robust option. However, I wonder whether this is really sensible,
because we all know that estimates are inconsistent under
heteroskedasticity here. Perhaps this has been discussed before, does it
serve a pedagogical purpose or am I missing something?
thanks,
sven
10 years
new "plot" command
by Allin Cottrell
This follows on from the discussion initiated by Jack in
http://lists.wfu.edu/pipermail/gretl-devel/2014-September/005285.html
("Request for Comments: gnuplot and foreign").
In CVS and snapshots we now have a block-type command named "plot", ready
for testing and further comment. It has the following characteristics:
* The block starts with "plot" followed by a required parameter: the name
of a list, a single series or a matrix. This parameter specifies the data
to be plotted. The starting line may be prefixed with the "savename <- "
apparatus to save a plot as an icon in the GUI program.
* The block ends with "end plot".
* Inside the block you have zero or more lines of these types, identified
by an initial keyword:
- "option": specify a single option (details below)
- "options": specify multiple options on a single line
- "literal": a command to be passed to gnuplot literally
- "printf": a printf statement whose result will be passed
to gnuplot literally
The options available are basically those of the current "gnuplot"
command, but with a few differences. For one thing you don't need the
leading double-dash in an "option" (or "options") line. Besides that,
* You can't use the option --matrix=whatever with "plot": that possibility
is handled by providing the name of a matrix on the initial "plot" line.
* The --input=filename option is not supported: use "gnuplot" for the
case where you're supplying the entire plot specification yourself.
* the several options linear-fit, quadratic-fit, suppress-fitted, etc.,
pertaining to the presence and type of a fitted line, are replaced in
"plot" by a single option "fit" which requires a parameter. Supported
values for the parameter are: none, linear, quadratic, cubic, inverse,
semilog and loess. Example:
option fit=quadratic
As with "gnuplot" the default is to show a linear fit in an X-Y scatter if
it's significant at the 10 percent level.
If more than one option is given on a line, the options should be
separated by spaces.
The "printf" facility allows the use of string variables without having to
resort to "@"-style string substitution.
Here's a simple example, the plot spec from the "bandplot" package, in
"before" and "after" forms:
<hansl mode="old">
gnuplot 1 2 3 4 --with-lines --matrix=plotmat \
--suppress-fitted --output=display \
{ set linetype 3 lc rgb "#0000ff"; set title "@title"; \
set nokey; set xlabel "@xname"; }
</hansl>
<hansl mode="new">
plot plotmat
options with-lines fit=none
literal set linetype 3 lc rgb "#0000ff"
literal set nokey
printf "set title \"%s\"", title
printf "set xlabel \"%s\"", xname
end plot --output=display
</hansl>
Note that --output=display is appended to "end plot": this option could be
"inlined" like the others but IMO it has a different status and I favour
the idiom of placing it outside the block.
Also note that if you give a matrix to "plot" it's assumed you want to
plot all the columns. In addition, if you give a single series and the
dataset is time series, it's assumed you want a time-series plot.
Nothing is "set in stone" at this point and comments are welcome. I can
think of various possible extensions of this approach myself, but I
thought the first task was to put something in place which basically
covers the functionality of the "gnuplot" command but in a cleaner and
less clotted fashion.
Allin
10 years
font size script editor and main window
by Artur T.
Dear gretl developers,
I just realized that it is not possible to change the font size of the
script editor as well as gretl main window.
We use gretl for teaching purposes and beam gretl at the wall. However, for
students sitting in the back of the classroom the font size is always too
small. At least using the Windows version (built 9. Sept. 2014) the font
change using the option "Fixed font" does only refer to the command line
but not the script editor.
Of ourse we could always use antoher editor for this but I thought it
should be possible to change the font size inside gretl as well.
Best,
Artur
10 years
returning a kind of 'model' object from a function package
by Sven Schreiber
Hi,
not sure if I'm tearing down open doors here, as we say in German, and
this has probably been mentioned before, but I think we should have a
way of returning a 'model' kind of thing from a function package.
What I mean is a collection of pre-defined results like the whole bunch
of accessor values after estimation ($xlist, $coeff, $vcv etc.) that can
be used by the caller of the function package. In a sense, it's like
gretl's model table mechanism applied to functions.
This could of course be done by stuffing everything into and returning a
hansl bundle, but then I would say we should have a written-down
convention on how to structure such a bundle. For example, it could be
mandatory to include a bundle member named 'is_model' with value 1 or
somesuch, so that a bundle can be recognized as holding model results.
I think this would make it easier to extend gretl via user-contributed
function packages. It doesn't mean that package authors would be
required to return a bundle, but it could be made mandatory for add-ons
etc. (perhaps it already is?).
Any reactions?
thanks,
sven
10 years
Request for Comments: gnuplot and foreign
by Riccardo (Jack) Lucchetti
Gretl has used gnuplot for all its graphical output since the dawn of
time. Some people find gnuplot's output ugly, but that's highly subjective
IMO; as far as I'm concerned, I simply love it; I certainly wouln't trade
the austere beauty of a line graph like gretl produces with a cheap
alternative sporting grossly fatter lines in a tacky light blue frame.
We also go to great lengths to make gnuplot's output customisable from our
GUI client, and it's a great credit to Allin's committment and ingenuity
that most GUI users don't even realise that their graphs are in fact
produced by a piece of software other than gretl.
Our relationship with gnuplot, when it comes to scripting, is a bit more
awkward. We have one command (the 'gnuplot' command) for doing most
things, and its syntax has been expanding over time in order to
accommodate more and more flexibility. In fact, now that we have the
--input option, a hansl script writer has at her disposal the potential
for producing masterpieces such as those found at
http://gnuplot.sourceforge.net/demo_4.6/ if necessary.
However, this implies writing functions in which, basically, we issue
strings into a file that is then re-used as input by gnuplot. The funny
thing is, we already have a "foreign" environment that does basically the
same job for statistical packages.
It could perhaps be advisable to extend the "foreign" command to drive
gnuplot in a more transparent way than we do now, and at the same time
take advantage of a change scheduled for gnuplot 5.0 (which should be in a
cinema near you real soon): "Command scripts may place in-line data in a
named data block for repeated plotting." This would make it possible to
pass data to gnuplot in a clean and efficient way.
The big difference with other "foreign" environments would be that it's
highly likely that a script writer might want to pass to gnuplot strings
as well as data. So, we could imagine a situation in which we pass bundles
and have something like
<pseudo-hansl>
bundle to_gp = null
to_gp["foo"] = X
to_gp["bar"] = "A string"
foreign language=gnuplot --data=to_gp
...
end foreign
</pseudo-hansl>
Being able to do something like this would reduce the need for supporting
the rather byzantine syntax we now have for the "gnuplot" command, which
could be much simplified with some options deprecated.
How do you like the idea?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
10 years, 1 month
pxsum() with missings
by Sven Schreiber
Hi,
apart from the fact that I would like to improve the help text of the
pxsum() function (but really have to run now...), I just noticed that
pxsum() propagates missing values.
so
pxsum(y)
will give a different result from:
pxsum(misszero(y))
This is of course not a problem per se, but is in contrast to the sum()
and psum() functions and thus not what I expected. Also, for the
non-panel simple case there is a differentiation between sum() and sumall().
So I think it's not an optimal situation, but I'm not sure what the best
solution would be without breaking backward-compatibility too much.
thanks,
sven
10 years, 1 month
'join' with gdt files
by Sven Schreiber
Hi,
I just used the 'join' command again after quite a while. Automatically
I tried to import from a native gretl (.gdt) file, and I got a strange
error, "not supported for this estimator" (in German).
Apart from this weird message (is it the same in English?), I remembered
that join only works with .csv files, as duly mentioned in the docs.
Then all worked nicely; however, from a little distance now I must say
that this feels a little "lame", gretl not being able to use its own files!?
cheers,
sven
10 years, 1 month
Re: [Gretl-devel] Strings not marked for translation
by Allin Cottrell
On Fri, 3 Oct 2014, henrique.andrade(a)bb.com.br wrote:
>
> I get the message "internal genr error: aux node type mix-up" inside a user
> defined function (that tries to estimate ARIMA models automatically), but
> unfortunately I can't replicate the error anymore :-(.
With Jack's help I have tracked down the probable source of that error and
fixed it. The error could arise when a compound Boolean expression
occurred in a loop, as in
loop ...
if conditionA && condition B
# do something
endif
endloop
If conditionA were true at first but then turned false on a later
iteration, the "type mix-up" could be triggered.
Allin
10 years, 1 month
